送信元/送信先チェックは一つの門であり、VPN 経路全体ではない

VPN は EC2 インスタンスで終端し、そのインスタンスのトンネルアドレスには到達できるのに、そこを経由して別のプライベートホストへ向かうはずの通信は消えてしまう。これは二つの別のテストであり、混同すると何時間も浪費する。一つ目はインスタンスに到達できるかを問い、二つ目は自分自身ではない宛先のために通信を転送することを求め、後者には Linux の転送、ファイアウォールポリシー、反対側のルート、そしてゲスト OS とは何の関係もない AWS レベルの許可が必要だ。コンソールのどこもその違いには注意を向けない。症状はルーティング障害に見えるが、たいていそうではない。

何かを変える前に二つのテストを分ける

ゲートウェイに到達できることは、トンネル、そのアドレスへのルート、やり取りを許可するセキュリティグループを証明する。別のホストへの転送は、違う送信元アドレス、違う宛先、そして必ずしもその役割のために作られていないインスタンスを使うので、そのどれも証明しない。二つのテストを別々に書き、どちらが失敗するかを記録する。それぞれの修正は別のコンソールにあり、トンネルを終端するためだけに作られたゲートウェイインスタンスには他の何かを転送する理由がないので、既定値もそれを反映している。だから二つ目のテストには、一つ目への小さな調整ではなく、独自の設定が必要になる。

ゲートウェイ宛ての ping が通り、その先のホスト宛ての ping が失敗するのは、断続的な問題ではない。転送してよいと伝えられていないインスタンスの、想定された振る舞いだ。

設定に触れる前に経路を書き出す

クライアントのプレフィックス、転送するインスタンスまたはネットワークインターフェース、対象サブネット、戻りのルートを記録する。インスタンスを指す VPC ルートテーブルのエントリは、そのインスタンスの OS を転送するよう構成しないし、転送を有効にしたゲストカーネルは VPC ルートを作らない。その関係の両端が存在する必要があり、それらは別の場所で、別の権限を持つ人によって編集される。

次に、送信元/送信先チェックの設定を、VPC 内のすべてのインスタンスではなく、実際の転送コンポーネントで確認する。AWS は、他のために通信を転送するインスタンスがこのチェックを無効にする必要がある理由と、この設定が VPC 全体の既定値ではなくインスタンスごとの判断である理由を文書化している。

四つの境界があり、チェックはそのうちの一つにすぎない

経路を四つの問いとして扱い、順に答える。最初に失敗する答えが作業の場所であり、他のどれもそれを補わない。

順序が重要になるのは確認が安いからであり、ルートは一ページで見え、チェックは一つの属性で、宛先の意見はたいてい最後に尋ねられる。

翻訳は宛先が見る送信元を変える

ルーティングする設計はクライアントの送信元アドレスを保つので、宛先はクライアントのプレフィックスへの戻りルートを必要とする。翻訳する設計は代わりにゲートウェイのアドレスを見せるので、その要件がなくなり、ゲートウェイ上の状態テーブルに置き換わる。無関係な例が使っていて動いたからといって翻訳を足すのではなく、意図するアーキテクチャに従って決める。

翻訳するなら、ルールをクライアントのプレフィックスと意図した宛先に限定する。保持するなら、反対側が本当にルートを知っているかを確認し、学習するだろうと仮定しない。

元のクライアントからテストし、それから変更を残す

ゲートウェイ上で生成した要求は、送信元が違い転送のケースも違うため、成功しても転送された要求は失敗することがある。狙った修正のあとは、失敗したそのとおりのクライアントからリソースへのテストを同じクライアントから繰り返し、要求が届いただけでなく応答が戻ることを確認する。

最後に、その設定をゲートウェイの管理された構成に入れ、置き換えのインスタンスが受け取るようにする。手作業の例外に依存した成功したテストは、次の再構築で期限切れになるテストであり、それを見つけた人は理由を覚えるためにそこにはいない。