ホームラボのスプリットトンネル：必要なものだけをルーティングする

ホームラボにフルトンネルが必要だという助言は、たいていそれを持っていたチュートリアルから来たもので、要件からではありません。スプリットトンネリングは正しい VPN の妥協版ではなく、ルートテーブルを説明できる版です。五つのサービスと管理画面を持つラボに、家を出るすべてのパケットがトンネルを通る必要はありません。必要なのは目録と、その目録の各項目へのルートです。

神話：スプリットトンネリングは妥協である

神話が残るのは、フルトンネルは一度設定するのは簡単で、後からデバッグするのが難しいからです。その取引は公衆 Wi-Fi のノート PC には妥当で、地下室のラックには間違いです。

また、ラボのアドレス体系が接続元のネットワークと何も共通していないという第二の前提も隠しています。

ルートより先にリソースを目録化する

ラボの各サブネット、そこに住むサービス、それを解決する名前、誰に到達が許されているかを書き出し、あなたの転送のメモがゲートウェイについて、計画の前提となる戻り経路を説明しています。コンテナの範囲と、リモートクライアントがすでに使っている可能性のある LAN の範囲も加えます。重複こそ、この目録が防ぐ障害であり、すべてのプライベートアドレスを覆うルートは遅かれ早かれ家庭内ネットワークと衝突します。目録はテスト計画でもあるので、設定の後ではなく前に作る価値があります。

各リソースに、トンネル経由・直接・拒否のいずれかの経路を割り当てます。経路が割り当てられていないリソースが、後で混乱したサポート質問を生みます。

五つの行と判断の一列は、誰も読めないルートテーブルに勝ります。

ゲートウェイには戻り経路が必要

ゲートウェイでの転送は半分にすぎません。ラボにはクライアントプールへの戻りルート、または戻りを可能にするサポートされた変換の仕組みが必要です。応答がクライアントを見つけられないと、トンネルは接続しているように見えて、すべての要求がタイムアウトします。これは VPN の障害ではなくルーティングの症状なので、戻り経路はトラブルシューティングの手順ではなく設計の一部として確認してください。

ラボ自身のアドレス体系と重複するクライアントプールは、この問題のもう半分であり、まったく同じように失敗します。

二つの範囲が衝突したら、症状ではなく計画を直します。

管理とインターネットの役割は別である

トンネルを使うのがラボの通信だけか、インターネットの出口にもなるかを決め、チュートリアルが使っていたからという理由だけでデフォルトルートを足してはいけません。その判断は、すべての DNS 問い合わせと更新確認の行き先を変えるからです。VPN エンドポイント自体への外側の経路を残さないと、トンネルが自分の外側の接続を運ぼうとします。管理アクセスは狭く保ち、承認された復旧方法で到達できるようにします。

すべての公開問い合わせが同じリゾルバーを必要とするとは仮定せず、ラボの名前にはプライベート DNS を選べます。それはリゾルバーの判断であり、ルートの判断ではありません。

両者を分けておくことが、後で障害の種類を見分けられるようにします。

LAN からではなく、外から試す

同じ LAN からのテストではなく、外部の許可された接続を使います。同じ LAN からのテストは、欠けた戻りルートを完全に隠せます。ラボのアドレス、そのプライベートホスト名、意図した直接の宛先、必要な失敗時の挙動を確認し、失敗の場合は成功の場合と同じくらい重要です。到達できないべきリソースは本当に到達できないでなければならないので、設計が終わったと言う前に四つの結果をすべて記録します。

次にルートと DNS の設定を目録の隣に保存し、所有者を明記します。ラボにさらにサブネットが増えたら、両方を更新して再テストします。

既存の家庭内ネットワークと重複する、説明のつかないルートは、その手順を飛ばしたときの既定の結果です。

完成した設計は小さく、文書化され、退屈で、それがラボが自分のネットワークに望むことそのものです。面白い版は、家を離れている間に壊れる版です。