ARPを無効にするとVPNは壊れる？外側のホップでは壊れ得る

{同じ接続の中を二つのパケットが通り、それぞれ別の規則に従う。一つはトンネルが運ぶプライベートなパケットで、仮想インターフェースはイーサネットヘッダーを一切持たずにこれを扱う。もう一つはアクセス回線からマシンを出ていく暗号化パケットで、こちらは今もローカルの次ホップをハードウェアアドレスへ解決する必要がある。この二つを混同すると、人は間違ったインターフェースでアドレス解決を切り、なぜトンネルが起動しないのかと首をかしげることになる。}

{パケットの中にパケット、二つの配送モデル}

{ルーテッドモードの仮想インターフェースはIPパケットを受け取る。イーサネットヘッダーもブロードキャストドメインもなく、内部に解決すべきアドレスもないため、内側のパケットはトンネル自身が配送する。アクセスネットワーク側で起きることは、別の配送層の話だ。}

inner packet: private address -> tunnel device -> the VPN process
outer packet: endpoint address -> access route -> next-hop hardware address

{その外側のパケットは、イーサネットインターフェースを出るときには普通のユニキャストフレームであり、次ホップの宛先ハードウェアアドレスを必要とする。アドレス解決がそれを与え、次ホップは通常リモートサーバーではなくローカルのゲートウェイだ。検索の対象がエンドポイントではなくゲートウェイであると理解することが、診断の大部分を占める。何かを変える前に両方のアドレスを書き留めておこう。}

{本当に重要な隣人を見つける}

{ルーティングテーブルにエンドポイントが使う次ホップを尋ね、そのホップについて隣人テーブルを調べる。エンドポイント自体はローカルリンク上にないため、そこに現れることはめったにない。}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{エントリが存在し到達可能なら、外側の経路は正常で障害は別の場所にある。欠けているか失敗状態なら、リンク、ゲートウェイのアドレス、あるいは解決を妨げるポリシーを見るべきだ。トンネルの暗号設定を変えても、どちらの場合にも役には立たない。隣人テーブルが報告する状態文字列に注目しよう。進行中の試みと恒久的な失敗を区別できるからだ。}

{学習されたエントリは依存を隠すことがある}

{キャッシュされたエントリは、それを作ったものが消えた後もしばらく動き続ける。だから変更の数分後に試したテストは、間違った理由で通ってしまうことがある。解決が不要だと結論づける前に、エントリが期限切れになるのを待つか、意図的に削除しよう。}

{逆の間違いも同じくらい多い。解決されないエントリを、トンネルが壊れた証拠とみなしてしまうのだ。実際にはそれはローカルセグメント、重複アドレス、あるいは応答を運ぶフレームを落とすポートセキュリティ規則を指している。VPNの設定に触れる前にスイッチのポートを確認しよう。}

{タイミングを証拠として読む。解決されては繰り返し期限切れになるエントリは、揺れるリンクか、一つのアドレスに二台の機器が応答していることを示唆する。一方、一度も解決されないエントリは、ゲートウェイのアドレスかアクセスポートでのフィルタリングを指す。}

{動的な解決と固定エントリのどちらかを選ぶ}

{動的な解決が既定なのには理由がある。ゲートウェイが交換されればハードウェアに追随し、誰とも調整する必要がない。静的なエントリが正当化されるのは、ネットワークが意図的に管理され、アドレスとハードウェアアドレスの対応が文書化された設計の一部である場合だ。}

{いずれにせよ、その選択は外側のパケットを運ぶアクセスインターフェースに適用する。そのインターフェースで解決を切ってもトンネルは堅牢にならない。トンネルを運ぶゲートウェイへ到達する力をクライアントから奪うだけで、障害はローカルのアドレス問題ではなく死んだVPNのように見える。}

{もう一方のスタックも忘れない}

{IPv6は同じ形のアドレス解決を使わず、近隣探索を使う。層をなす問いは変わらない。実際の外側パケットはどうやってローカルの次ホップに届くのか、そして答えが最新であることを何が示すのか。}

{設計が完成したと宣言する前に、もう一方のスタックでも同じ二つの事実を確認しよう。両方のファミリーを運ぶトンネルには、検討すべき外側の経路が二本あるからだ。どちらを検証し、どちらを仮定したかを記録しておく。}