自宅VPNサーバーとクラウドサーバー、NASに届くのはどちらか
トンネルは張れるのに自宅NASには届かない。触れたい資源でエンドポイントの場所を選び、そのあと経路を確認する。
トンネルは張れ、クライアントは緑の点を表示するのに、ssh 192.168.1.20 はタイムアウトまでぶら下がったままだ。小さなクラウドインスタンスを借りてWireGuardを載せた直後、私はまさにこれに遭遇した。ハンドシェイクは正常、DNSも正常、机の上のNASは月にでもあるかのように届かない。トンネルに問題はなかった。エンドポイントが、私の家への経路を持たないネットワークに置かれていたのだ。エンドポイントの場所が隣接するネットワークを決める。だから先に触れたい資源で選び、ホスティングは二番目に比べる。
トンネルが届くのは、エンドポイントが経路を持てるネットワークだけだ
VPNはクライアントにエンドポイント自身の経路ドメイン内のアドレスを与える。クライアントが192.168.1.20へパケットを送るとき、エンドポイントはその行き先を知っていなければならない。クラウドVMの表が知っているのはプロバイダーのVPCサブネットだけで、あなたのLANのことは聞いたこともない。接続と到達は別の事実であり、自宅とクラウドの混乱の多くは前者を後者の証明とみなすことから生じる。
コマンド一つで決まる。エンドポイントでip route get 192.168.1.20 はLANインターフェースを示すか、デフォルト経路を指す。自宅の箱なら答えはLAN側だ。クラウドインスタンスならパケットはインターネットへ出て死ぬ。net.ipv4.ip_forward=1 を有効にしてMASQUERADE規則を足しても変わらない。自宅側の何かがクラウドへのリンクを終端するまで、転送する先がないからだ。
自宅側には後半がある。戻り経路だ。トンネルの箱を通ってLANを出るパケットはNATされるか、LANがトンネルのサブネットへの静的経路を必要とする。片方向だけ動くときはsysctl net.ipv4.conf.all.rp_filter を確認する。厳格な逆経路フィルタリングは、経路が予測するのと違うインターフェースに届いた応答を落とし、症状はファイアウォール規則とまったく同じに見える。
設定に触れる前に症状を読む
トンネルが張れないなら鍵、エンドポイントのアドレス、あるいはUDPポートの遮断だ。トンネルは上がるがLANのホストが死んでいるなら配置と経路だ。トンネルは上がるが閲覧が死んでいるなら転送、NAT、DNSだ。これは三つの層と三つの異なる確認であり、すでに正しい設定を書き直すのは一晩の無駄だ。
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
自宅への内向きの到達性は独自の確認に値する。自宅ホスティングがそもそも可能かを決めるからだ。ルーターが報告するWANアドレスと、外部ホストが見るアドレスを比べる。それが100.64.0.0/10に入るか、両者が食い違うなら、あなたはキャリアグレードNATの背後にいて、ポート転送は決して動かない。現実的な選択肢はリレー、自宅から外へ発信するクラウドリンク、あるいはエンドポイントの移動だ。
自宅ホスティングが与えるものと、その代償
自宅は既定でLANの内側にある唯一の配置であり、そこにサーバーを置く理由はそれに尽きる。プリンターや非ローカルのサブネットを拒むNASの管理画面のように、ローカルセグメントにしか応答しない機器も、追加の経路なしで動く。マシン、ルーター、上流回線も自分で運用する。
代償は物理的だ。自宅のアップロードは全クライアント同時の上限であり、ビデオ通話とバックアップが同じ管を奪い合う。電力、ディスクの消耗、パッチ、DDNS が要る動的アドレス、内側へUDPを転送するルーター、そして二重NATの可能性まで、すべてあなたに降りかかる。見落とされがちなのは復旧だ。留守中に箱が死ねば、家へ入る唯一の道も一緒に死ぬ。同じ鍵を持つ二台目を置くか、少なくとも物理アクセスの計画を持っておく。
自宅に箱を置かずLANへアクセスしたいなら、装うのではなくリンクを組む。クラウドのエンドポイントがルーターになる。自宅側からAllowedIPs = 192.168.1.0/24 を付けたトンネルをクラウドのピアに張り、クラウドの箱で転送とNATを行う。strongSwanの転送ガイドがこの構成の戻り側を説明しており、多くの試みはそこで失敗する。自宅のピアが動いていないと何も動かないので、依存を一つ別のものに替えたことを書き留めるべきだ。
クラウドのエンドポイントは何のためか
クラウドのエンドポイントは公開の出口を変える。通信はプロバイダーのアドレス範囲から出て、サイトは自宅のアドレスではなくそれを見る。価値はそこにあり、クラウドVPNがNASを渡さないのも同じ理由だ。動かしたのは出口であってLANではない。
ゲストシステム、VPNサービスとその資格情報はあなたが運用し、ハイパーバイザーと物理ネットワークはプロバイダーが運用する。午前2時に何かが壊れたとき、この分担が効いてくる。公開エンドポイントは常時スキャンされるので、管理ポートは閉じ、VPNポートだけを許可し、計画的にパッチを当てる。セキュリティグループとプロバイダーのファイアウォールがそのポートを許可する必要があり、インスタンスの送信元・宛先チェックを調整しないと転送通信を捨てるクラウドもある。
小さなインスタンスは一握りのクライアントを賄えるが、暗号化はCPUの仕事であり、クレジットを使い切ったバースト可能インスタンスは持続負荷でむらが出る。仕様表ではなく、実際に使う経路を見る。
書き留められる判断
配置を決めるのは箱のラベルではなく作業だ。自宅LANの機器に届く必要があるなら、最も安い正解は自宅のエンドポイントであり、クラウドの箱は戻りリンクを組んだあとにしか動かない。別の公開出口が要るなら答えはクラウドで、LANの話は出てこない。両方を望むのは正当だが、二つのエンドポイント、二組の鍵、二つの文書化された経路を意味する。
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
クライアントから順に確認する。ハンドシェイク、ピアのアドレス、LANのホスト、そして出口IPだ。curl -s https://ifconfig.me はインターネットに見えるものを示し、ip route get 192.168.1.20 はエンドポイントが信じているものを示す。出口の確認が通りNASの確認がぶら下がるなら、配置の答えはすでにある。クライアントのAllowedIPsを調整しても経路は現れない。10.8.0.0/24, 192.168.1.0/24 のような分割行は、その経路が本当に存在してはじめてLAN通信をトンネル内に保つ。