マルチルーターPi VPN：判断する機器に各ルートを置く
下流のルーターが2つ目のクライアントサブネットを追加し、4台の機器がそれぞれ1つの判断を担います。ルートを配置し、送信元を確認し、実際のクライアントから試します。
Piの後ろにWi-Fiボックスを置くと、一つのルーティング判断が四つに増え、四つすべてを一台で決めると計画は破綻します。最初の問いは、どのルートを追加するかではありません。新しいボックスがブリッジするのかルーティングするのかであり、その答えがサブネットの数と、どの機器がそれを学ぶべきかを決めます。まず接続モデルを選んでください、すべてのルートはそこから導かれます。
ブリッジかルーティングか：数を決める選択
ブリッジは新しいクライアントを、Piがすでに提供している同じサブネットに置きます。一つのサブネット、一つのDHCP権限、そしてルーティングへの引き継ぎはありません。これはより単純な構成であり、別個のクライアントネットワークが要件でなかった場合に正しい選択です。ルーティング接続は別の設計であり、ボックスは独自のサブネットを保ち、そのプレフィックスはトラフィックが行く先々へ運ばれなければなりません。
この計画の残りは下流ルーターを維持し、クライアントの送信元アドレスを保持します。目標は一つのプライベートVPNネットワークであり、完全なインターネット出口ではありません。アドレスの前にモデルを書き留めてください、下の一覧はルーティング接続の一例にすぎないからです。
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24誰が何を決めるか
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
各機器は一つの判断を行い、どれも他の機器の判断を代わりに行えません。Piには一つのエントリではなく二つが必要で、戻り経路こそが人々が忘れるものです。転送されたトラフィックはプライベートネットワークに正しく届いた後、Piが10.41.0.0/24の居場所を知らないために戻り道で死にます。それはファイアウォールの問題に見えて、実は欠けたルートです。
遠い側にも独自のルートが必要です。遠端のサービスが、あなたのトンネル経由で10.41.0.0/24に到達できることを知らなければ、応答は答えを持たない最初のホップで止まります。パケットフィルタを読む前に両方向を追加してください。
次のホップは接続から決まる
次のホップは、その機器が実際に到達できるネットワーク上のアドレスでなければなりません。VPNピアの公開アドレスはプライベートサブネットの次のホップではなく、遠隔のサービスネットワークは次のホップですらありません。到達不能なゲートウェイへのルートは一覧では正しく見え、すべてのパケットを落とす。宛先を責める前に、ゲートウェイが応答するか確認してください。
Piの外部VPNピアを、それ自身のアンダーレイルート経由で到達可能に保つ。そのエントリはペイロードのルートとは別であり、混ぜると経路変更後に再確立できないトンネルになります。
スタティックルートのドキュメントは、各プラットフォームがメニューの名前を変えていても、宛先とゲートウェイの区別を明確にします。他のベンダーの画面をコピーするのではなく、目の前の機器のドキュメントを読んでください。下のコマンドはLinuxでのエントリの形を示しています。
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1変換が送信元に何をするか
下流ルーターがすでにクライアントを通過アドレスに変換している場合、Piは各クライアント自身のアドレスではなく、一つの変換された送信元を見ます。これは上記の送信元を保持する設計とは異なります。送信元ベースのポリシー、ログ、どちら側が接続を開始できるかが変わります。どちらの設計も機能します、異なる問いに答えているからです。
上流のVPNサービスがクライアントプレフィックスを戻すルーティングを拒否する場合、Piのトンネル出口での狭い変換は正当な回避策になり得ます。それは欠けたルートが不要だった証拠ではありません。遠隔ネットワークが実際にどのアドレスを見るのか、どの戻り経路になるのかを記録してください。
ルート選択、転送許可、送信元変換は三つの別の仕事のままです。一台の有線クライアントが動くからといって共有NATチェーンを流したり全インターフェースを許可したりするのは、動くテストを開いたフォワーダーに変える方法です。
クライアントマシンから証明する
下流LANのマシンから要求を送り、その送信元を外へそして戻るまで追ってください。Piが出すpingは下流の戻りルートを決して通らないので、成功したpingは見た目より少ないことしか証明しません。Pi自身のLAN上の有線クライアントから二つ目のテストを追加し、二つの経路を比較できるようにします。どちらかの機器を再起動した後、両方を繰り返してください。
手で追加したルートと保存されなかった変換は一緒に消えます。そのとき、その組み合わせは未完成の仕事ではなく新しい障害に見えます。
接続モデルを、ルート、許可されたプライベートサービス、あらゆる変換とともに一つのメモに保存してください。そのメモが、次の人が無線の配置をルーティングポリシーの問題として扱うのを止めます。