VPN と自宅 LAN が同じサブネットを使うとき: まず経路をたどる
両方のアダプターが 192.168.1.0/24 を主張し、経路は 一 本しか勝てません。振り直しや DNS のせいにする前に、アダプター一覧、勝った経路、戻り道をたどってください。
会社の VPN に接続すると、トレイのアイコンが緑になり、イントラネットが開き、二 メートル先のプリンターが応答しなくなります。今朝まで使えていた共有は同じマシンでタイムアウトし、どのログにもプリンターの文字はありません。反射的に DNS を疑いますが、名前が引けないのは存在しない名前のように見えるだけで、問題はアドレスです。二 つのアダプターが 192.168.1.0/24 を主張し、そのプレフィックスを取れる経路は 一 本だけです、この順序でたどれば、何かを変える前にどちらのアダプターが取ったか分かります。
症状から始め、トンネルから始めない
手がかりは範囲です。イントラネットが動き、ローカルの全機器が失敗するなら、トンネルは正常でローカルの経路が異常です。ローカルの機器が動き、イントラネットが失敗するなら逆です。一 台のホスト以外すべて動くなら、両側に存在する 一 つのアドレスを見ています。
設定に触る前に、ローカルのアドレスと遠隔のアドレスを 一 つずつ書き出します。「プリンター」は検証できませんが、192.168.1.40 ならできます。この 一 歩が、この問題で最もよく失われる 一 時間、つまり経路の判断のために DNS 設定を書き直す作業を防ぎます。
ステップ 1: プレフィックスを主張する両方のアダプターを見る
ネットワーク接続 (ncpa.cpl) を開き、二 つのアダプターを並べて読みます。Ethernet アダプターは 192.168.1.50/24 とゲートウェイ 192.168.1.1 を示します。VPN アダプターはサーバーから押し出された 192.168.1.201/24 を示します。どちらも正当で、どちらもプレフィックスが on-link だと考えており、スタックはそのための経路を 一 本だけ保持します。
Get-NetIPAddress -AddressFamily IPv4 はアドレスを一覧し、Get-NetIPInterface | Sort-Object InterfaceMetric はスタックが使う順序を示します。そのメトリック列こそ、これから読む判断そのものなので、覚えようとせず数字を書き留めてください。
DNS 説を安く否定します、Resolve-DnsName printer.office.lan は昨日と同じアドレスを返します。名前は解決しており、その後パケットが誤ったアダプターから出ています。ここでの 二 分がリゾルバー設定の半日を節約します。
ステップ 2: 実際に勝った経路を読む
Find-NetRoute -RemoteIPAddress 192.168.1.40 は、そのアドレスに対してスタックが使うインターフェース、次のホップ、送信元を表示します。この出力はヒントではなく答えとして扱ってください。どの項目がどれだけ負けたかを見たいときは route print -4 が表全体を出します。
具体性が意図に勝つ。押し出された 192.168.0.0/25 はローカルの 192.168.0.0/24 に勝ちます。プレフィックスが長いからで、192.168.0.0 から 192.168.0.127 はトンネルを通り、上半分はローカルに残ります、半分の LAN がエラーも出さずに消えるのは、その表として正しい挙動です。
tracert -d 192.168.1.40 は表の外から確認します。最初のホップが自分のルーターではなくトンネルのアドレスなら、経路がすべてです。Linux では同じ問いが ip route get 192.168.1.40 で、送信元アドレスとデバイスを 一 行で表示します、tun0 と答えたら、ブラウザーを見るのはやめてください。
ステップ 3: クライアントを責める前に戻り道を確認する
正しい行きの経路でも、遠い側が答えられなければ失敗します、クライアントの LAN にトンネル経由で届く場合、その LAN のゲートウェイがトンネルのプールの場所を知っている必要があります。そのルーターで ip route add 10.8.0.0/24 via 192.168.1.12 を実行し、サーバーから push “route 192.168.1.0 255.255.255.0” を出して、クライアントが戻り道を知るようにします。
最初の項目がなければ、応答は宛先を離れて既定のゲートウェイへ向かい、そこがプライベートアドレスを ISP に転送して捨てます、症状は片方向で、読み違えやすいものです。要求は tun0 に現れ、応答は決して現れません。
VPN ホストの masquerade ルールは、その静的経路の必要をなくします。iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE です、ただし実際の送信元アドレスも隠すので、後のログ調査は難しくなります。既定のゲートウェイが誤った宛先ホストも同じ沈黙を生み、最良なら ICMP リダイレクト、通常はブラックホールになります、だからこそ取得は両端で行います。
ステップ 4: 受け入れられる修復を選ぶ
これには 五 つの修復が使われ、互いに置き換えはできません。どのコマンドが短いかではなく、同時に何が到達可能であり続けるべきかで選びます。
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
メトリックは安い選択肢で、人が最初に手を伸ばすものです。変更はインターフェースに効くのでトンネルが上がっている間は機能し、置き場所はクライアントの隣のスクリプトであり、忘れるシェルではありません。同じアドレスへの同時アクセスを 二 つのネットワークで提供することはできず、この制限が他のすべてを表の下へ送ります。
自宅 LAN を振り直すなら 10.10.0.0/24 がきれいな解です。DHCP リースの更新 一 回に加えて、古い範囲を指す予約、印刷キュー、固定アドレスを直します、オフィス側の振り直しは通常あなたの判断ではありません、IPv6 なら両方のネットワークが対応していれば衝突は完全に消えます。覚えやすい何かではなく fd00::/8 からの一意なローカルプレフィックスを使い、アプリは ping ではなく TCP で試してください、ICMP が通ってもサービスが動かないことがあります。
OpenVPN 自身の変換オプションが最後の手段で、サーバーからクライアント固有のディレクトリ項目へ押し出します。オプション名の後に 四 つのパラメーター、方向、ネットワーク、ネットマスク、別名を取ります、別名は任意ではありません。push "route 192.168.2.0 255.255.255.0" と push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0" です。ネットワークとマスクはクライアントが見る範囲 (192.168.2.0/24)、別名はサーバー側の実際のオフィス範囲 (192.168.1.0/24) で、押し出された経路がその見える範囲を到達可能にします。するとオフィスはそのクライアントに 192.168.2.x として見えます、対応表はプロファイルに記録してください、さもないと次の人が経路障害として調べることになります。
一 つのサービスを公開するのは変換の狭い版で、OpenVPN のオプションはまったく不要です。VPN ホストの DNAT ルールが 一 つのポートを再公開するので、LAN はアドレスを保ったまま、既に知っているホストアドレスでサービスに届きます。代償はいつものとおりで、サービスから見た送信元は VPN ホストになり、クライアント別のログや逆引きは意味を失います。これは印刷キュー 一 つか管理ページ 一 つを覆うもので、両側のホストが互いに届くことではありません。
それでも動かないもの、記録すべきもの
ブロードキャストはルーティングされたトンネルを越えません、DLNA、UPnP、NetBIOS のブラウズ、Wake-on-LAN は、tun デバイスが運ばないブロードキャストやマルチキャストに依存するので、経路では発見を直せません。dev tap でのブリッジはセグメントを広げ、DHCP ブロードキャスト、ARP、その他の発見パケットも通します。遠いルーターの LAN 側アドレスには route 192.168.2.1 255.255.255.255 のようなユニキャストのホスト経路を選んでください。
同じ経路上で両方が 192.168.1.1 を使う 二 台のルーターは同じ問題の一族です。ローカルのアドレスが常に勝つので、片方の LAN が移るまで遠いルーターのページは届きません、二 つ目のアダプターを足してもどちらの場合も変わりません。
何かを編集する前に証拠を記録します、ip route get か Find-NetRoute、問題のアドレスへの ping -c 3、traceroute、クライアントでの tcpdump -ni tun0 icmp、そしてサーバーの経路表と NAT カウンターです。片方向だけ通って逆で死ぬ ping は、トンネルではなく戻り道を指します、その 一 つの区別が、上のどの修復が本当に必要かを決めます。