Connect :
Uptime :
Primary
6 Days
5 Hour
35 Min.
今年に入ってからNGN網にIPSecVPNを張りデータ転送させるテストをしていたのだが、
チューニングが完了し実際にパケットを流せるレベルになった。
今回用いている機材はYAMAHA RTX830。
NGN網でVPNを張っているのは1本で、VPNが切れた時の為にISP経由も張っている。
IPSecVPN越しにiNoniusでスピードテストをした結果がこちら。
 |
インターネット接続はフレッツ光・IPoEだが、
流石に直接IPoEで抜けるのよりは遅くなった。
だが、比較的混雑しやすい休日の21時30分頃でこの速度が出るなら満足。
キャプチャは無いがチューニングしないと同時間帯で40Mbps程度だったので、
やはりIPSecVPNはチューニングしないとダメだと実感。
これでNW接続拠点を増やす作業の第一段階が完了したので構成図も更新したい所。
だが、日々やる事が次々と増えているのでなんとも難しいのが悩みの種。
筆者がL2SWを買うとしたら、
サーバやルータを大量に接続する為に24ポート以上のスイッチを買う事が多かった。
直近でL2SWが必要になったので、同様に24ポートスイッチを買おうと思っていたのだが、
以前から弄ってみたかった2960-CXを通常よりも安く入手する事が出来た。
新しいNW機器を購入したら分解して中身を確認したくなる人種なので、
今回購入したCisco Catalyst 2960-CXも分解してみた。
傷やポート変形があるので少し安い値段でゲット。
12ポートスイッチはあまり買わないのだが値段に惹かれたので購入。
利用用途も当面は少ポート数で足りる可能性が高かったので上手く合致した。
自宅のキャッシュDNSサーバではDNSSECのレコード署名を検証していたが、
一部ドメインや特殊構成のgTLDで名前解決が失敗する事に気づいた。
DNSSECについてはJPNICが解説しているのでそちらを参照。
権威DNSとレコード応答の正当性を検証する仕組みなので、
クエリや応答を暗号化する物では無い点に注意。
このレコード署名検証が失敗すると、不正な権威DNSからの応答と判断してSERVFAILする。
自宅のDNSサーバは、サーバ自身で名前解決を行うインターネットに接続したキャッシュDNS(親)と、
PCやスマホからのDNSクエリを一次受けして、
上位の親DNSに再転送するキャッシュDNS(子)で多段にしている。
今回は親・子の両キャッシュDNSサーバにBINDを使った上、dnssec-validationを有効化したら、
DNSSEC検証が失敗するドメインが出てきた。
………
確認出来たのはOpenSUSEのリポジトリとシャープのWebサイト。
良くある事なのでEDNS0やTCPフォールバックあたりを怪しんでログ調査していたが、
切り分けたら4KB近いDNSクエリでも正常に受信出来ていたのと、
一部ドメインのみで問題が出ており大多数はDNSSECも名前解決出来ていたので調査が難航した。
1週間程度格闘し、digコマンドにバッファ拡張オプションをつけたり、
cdflagでDNSSEC検証を無効化してわかったのは、次の5個を満たしている時に起こる場合がある点。
5番目は実際に権威DNSを運用している人ならわかる内容だが、
本番運用ではサブドメイン委任をせず親ドメインのゾーンにサブドメインのレコードを書く場合がある。
今回はキャッシュDNSが少し特殊な構成なのと権威DNSのサブドメイン委任も特殊だったので、
DNSSECのレコード署名検証で不整合と判断されたのかもしれない。
………
流石に権威DNSに手を出す事は出来ないのと名前解決が出来ないのは少し困るので、
キャッシュDNSでdnssec-validationを無効化する事にした。
本来はNTAsを設定して逃げるのが筋だと思うが、
BINDでNTAsを設定しても最長1週間しか維持できないので常用は難しいと判断。
ちなみに、UnboundならNTAsで常時除外も出来るが、検証はBIND環境の話なのでそもそも出来なかった。
発展途上であるDNSSECは今回の様な問題が出る事がある上、
問題が出た時のデバッグに時間がかかるのが辛い所。
常用しているからこそ分かった事例なので、似たような事が起きたら今後も都度メモしようと思う。
