*** この記事は、検証中の結果に対するものです。
*** 必ずしも、この記事の通りに設定しても解決しないかもしれません
【NW環境】
・ NTTフレッツ 光ネクスト 回線
・ ONU/ホームゲートウェイ -> 家庭向けBBルーター -> プロキシサーバー(debian10)
・ 家庭向けBBルーターは、HGWよりIPv6が割当され、DS-Lite接続されている。
【クライアント／サーバー環境】
・ debian10 + squid インストール
・ プロキシサーバー(debian10)にて、BBルーターLAN側のIPv4とIPv6がeth0に割り当てられている。
enx0123456789ab: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 01:23:45:67:89:ab brd ff:ff:ff:ff:ff:ff
inet 192.168.0.100/24 brd 192.168.0.255 scope global enx0123456789ab
valid_lft forever preferred_lft forever
inet6 2409:10:****:0:0323:45ff:fe67:89ab/64 scope global dynamic mngtmpaddr
valid_lft 86399sec preferred_lft 14399sec
inet6 fe80::0323:45ff:fe67:89ab/64 scope link
valid_lft forever preferred_lft forever
IPv4 GW: default via 192.168.0.1 dev enx0123456789ab onlink
ipv6 GW: default via fe80::cfef:01ff:fe23:4567 dev enx0123456789ab proto ra metric 1024 expires 104sec hoplimit 64 pref medium
・ resolv.confは、
nameserver 8.8.8.8
nameserver 8.8.4.4
【最初におかしいと気づいたこと】
別クライアントPCから当該プロキシサーバー経由で、amazon.co.jp ページを閲覧。ページ表示完了まで、30秒以上かかっている。
あまりにも表示完了するまで時間がかかりすぎ。
【調査開始】
(現象1)
プロキシサーバーへSSH。
$ wget "https://www.google.co.jp"
www.google.co.jp (www.google.co.jp) をDNSに問いあわせています...
で、5秒程度DNS解決に時間がかかっている。
速攻で再度実行しても5秒程度待たされる。
(現象2)
Nagiosで監視項目に入れる予定だったので、以下の監視サーバー(別の端末)コマンドを実行。
$ cd /usr/lib/nagios/plugins
$ ./check_http -I 192.168.0.100 -t 20 -p 3128 -u https://www.google.co.jp/ -H www.google.co.jp -S -j CONNECT
HTTP OK: HTTP/1.1 200 OK - 15102 bytes in 10.255 second response time |time=10.254999s;;;0.000000 size=15102B;;;0
と、チェックに10秒かかっている。
速攻で再度実行すると、
$ ./check_http -I 192.168.0.100 -t 20 -p 3128 -u https://www.google.co.jp/ -H www.google.co.jp -S -j CONNECT
HTTP OK: HTTP/1.1 200 OK - 15129 bytes in 0.223 second response time |time=0.222529s;;;0.000000 size=15129B;;;0
0.2秒でレスポンスがある。
10数秒後に再実行すると、またもや10秒ほど時間がかかる。
(現象3)
プロキシサーバーへSSH。
$ dig a /www.google.co.jp
や
$ dig a /www.google.co.jp @8.8.8.8
としても、即解決する。
Windowsでも一昔前から起きているIPv6絡みのDNSレスポンス問題のようだ。
IPv6のNWは無いのに、WindowsのIPv6がデフォ有効になっていて、DNS IPv6解決(タイムアウト)→IPv4解決の動きになるので、
タイムアウト時間待たされるというもの。
でも、今回はIPv6/IPv4のDual-Stack状態なので、DNS IPv6でも即解決するはずだから、問題無いはず・・・と思っていたのだが。
→ この時の /etc/resolv/confは、
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844
nameserver 8.8.8.8
【よくある解決方法】
Windowsでこの問題が起きた時には、IPv6を無効化する方法が広まった。
また、LinuxでもOS上からIPv6を無効化する動きが多かった。
現在は、 /etc/sysctl.confに
net.ipv6.conf.all.disable_ipv6 = 1
を追加して再起動が有名。
当時IPv6の環境そのもの整っていないので、(IPv6が)使えないから、IPv6=OFF にするという判断だった。
今回の事象も試しに、IPv6を無効化すると、wgetテストは即反応を示した。(実際のプロキシ経由のhttpGetはしていない)
【IPv6有効状態で解決する方法は？】
結論からすると、まだ解決に至っていない。
他の方はこのような問題に直面していないのだろうか・・・。
まだ、「これだ！」という情報源にたどり着いていない状況である。
とある記事では、
squid.confで、
「dns_v4_first on」
を使って解決に至った記事もあるが、当該環境では解決に至っていない。
【現在エージング中】
この方法が解決方法なのか分からないし、環境に依存しそうなので「テスト中」というステータスである事に留意してほしい。
著者の環境で行っている設定は
squid.confで、
「dns_nameservers 2001:4860:4860::8888 8.8.8.8」
googleの代替DNSは、現段階では入れていない。
googleのPublicDNSは、かなり有名なのでDownしないだろう(クラスタ組んでるのでは？)と・・・勝手に思っている。
この設定を入れてから1時間経過したが、監視サーバー(Nagios)、タイムアウト10秒設定でも異常検知していない。