VPN a domácí LAN ve stejné podsíti: nejdřív projděte trasu
Oba adaptéry si nárokují 192.168.1.0/24 a vyhraje jen jedna trasa. Projděte seznam adaptérů, vítěznou trasu a zpáteční cestu, než začnete přečíslovat nebo obviňovat DNS.
Připojíte se k firemní VPN, ikona v oznamovací oblasti zezelená, intranet se načte a tiskárna dva metry daleko přestane odpovídat. Sdílená složka, která ráno fungovala, na stejném počítači vyprší, a žádný log se o tiskárně nezmiňuje. Reflex je DNS, protože jméno, které se nepřeloží, vypadá jako jméno, které neexistuje, ale problém je v adrese: dva adaptéry si teď nárokují 192.168.1.0/24 a ten prefix může vyhrát jen jedna trasa. Projděte to v tomto pořadí a uvidíte, který adaptér si to vzal, než cokoli změníte.
Začněte u symptomu, ne u tunelu
Nápovědou je rozsah. Když intranet funguje a všechna lokální zařízení selhávají, tunel je zdravý a lokální cesta ne. Když lokální zařízení fungují a intranet selhává, je to opačně. Když funguje všechno kromě jednoho hostitele, díváte se na jedinou adresu, která existuje na obou stranách.
Než se dotknete nastavení, zapište si jednu lokální a jednu vzdálenou adresu. „Tiskárna“ se testovat nedá; 192.168.1.40 ano. Ten jeden krok zabrání nejčastější ztracené hodině u tohoto problému, kterou je přepisování nastavení DNS kvůli rozhodnutí o směrování.
Krok 1: podívejte se na oba adaptéry, které si nárokují prefix
Otevřete Připojení k síti (ncpa.cpl) a čtěte oba adaptéry vedle sebe. Ethernet adaptér ukazuje 192.168.1.50/24 s bránou 192.168.1.1. VPN adaptér ukazuje 192.168.1.201/24, které poslal server. Oba jsou legitimní, oba věří, že prefix je on-link, a stack si pro něj ponechá jedinou trasu.
Get-NetIPAddress -AddressFamily IPv4 vypisuje adresy a Get-NetIPInterface | Sort-Object InterfaceMetric ukazuje pořadí, v jakém je stack použije. Ten sloupec metriky je rozhodnutí, které se chystáte přečíst, takže si čísla zapište, místo abyste si je pamatovali.
Levně dokažte, že teorie o DNS je chybná: Resolve-DnsName printer.office.lan vrací stejnou adresu jako včera. Jméno se přeložilo; paket pak odešel špatným adaptérem. Dvě minuty tady ušetří odpoledne v nastavení resolveru.
Krok 2: přečtěte si trasu, která skutečně vyhrála
Find-NetRoute -RemoteIPAddress 192.168.1.40 vypíše rozhraní, další skok a zdroj, které by stack pro tuto adresu použil. Berte tento výstup jako odpověď, ne jako nápovědu. route print -4 dá celou tabulku, když chcete vidět, která položka prohrála a o kolik.
Konkrétnost vítězí nad úmyslem. Posílaný 192.168.0.0/25 poráží lokální 192.168.0.0/24, protože prefix je delší, takže 192.168.0.0 až 192.168.0.127 odchází tunelem, zatímco horní polovina zůstává lokální. Zmizení poloviny LAN bez chybové zprávy je pro takovou tabulku správné chování.
tracert -d 192.168.1.40 to potvrdí zvenčí tabulky: pokud je první skok adresa tunelu místo vašeho routeru, trasa je celý příběh. Na Linuxu je stejná otázka ip route get 192.168.1.40, který vypíše zdrojovou adresu a zařízení na jednom řádku. Když odpověď jmenuje tun0, přestaňte se dívat na prohlížeč.
Krok 3: zkontrolujte zpáteční cestu, než obviníte klienta
Správná trasa tam stejně selže, když druhá strana nemůže odpovědět. Když se klientská LAN dosahuje tunelem, brána té LAN musí vědět, kde žije pool tunelu: ip route add 10.8.0.0/24 via 192.168.1.12 na tom routeru, a push „route 192.168.1.0 255.255.255.0“ ze serveru, aby klienti znali zpáteční cestu.
Bez prvního záznamu odpověď opouští cíl směrem ke své výchozí bráně, která předá privátní adresu poskytovateli a zahodí ji. Symptom je jednosměrný a snadno se špatně čte: požadavky se objevují na tun0, odpovědi nikdy.
Pravidlo masquerade na hostiteli VPN odstraní potřebu této statické trasy: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Také skrývá skutečné zdrojové adresy, což každou další otázku nad logy ztěžuje. Cílový hostitel se špatnou výchozí bránou vytváří stejné ticho, v nejlepším případě s přesměrováním ICMP, v normálním případě s černou dírou, a proto snímek patří na oba konce.
Krok 4: vyberte opravu, se kterou dokážete žít
Používá se na to pět oprav a nejsou zaměnitelné. Vybírejte podle toho, co musí zůstat dostupné současně, ne podle toho, který příkaz je nejkratší.
| 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 |
Metriky jsou levná varianta a ta, po které lidé sáhnou první. Změna platí pro rozhraní, takže funguje, dokud je tunel nahoru, a patří do skriptu vedle klienta, ne do shellu, který zapomenete. Nemůže dát současný přístup ke stejné adrese ve dvou sítích, a to je limit, který posílá všechny ostatní dolů po tabulce.
Přečíslování domácí LAN na 10.10.0.0/24 je čisté řešení: jedno obnovení DHCP lease plus rezervace, tiskové fronty a pevně zadané adresy, které zmiňují starý rozsah. Přečíslování na straně kanceláře obvykle není vaše rozhodnutí. IPv6 kolizi úplně odstraní, když ho nesou obě sítě, s unikátním lokálním prefixem z fd00::/8 místo něčeho zapamatovatelného, ale testujte aplikaci přes TCP, ne pingem, protože ICMP může fungovat, zatímco služba ne.
Vlastní možnost překladu OpenVPN je poslední záchrana, posílaná ze serveru do položky adresáře specifické pro klienta. Za názvem možnosti bere čtyři parametry — směr, síť, masku a alias — a alias není volitelný: push "route 192.168.2.0 255.255.255.0" a push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Síť a maska jsou rozsah, který klient vidí (192.168.2.0/24), alias je skutečný kancelářský rozsah na straně serveru (192.168.1.0/24) a posílaná trasa dělá tento viditelný rozsah dostupným. Kancelář se pak tomu klientovi jeví pod 192.168.2.x. Zdokumentujte mapování v profilu, jinak ho příští člověk bude ladit jako chybu směrování.
Publikování jediné služby je úzká verze překladu a možnost OpenVPN vůbec nepotřebuje. Pravidlo DNAT na hostiteli VPN znovu publikuje jeden port, takže LAN si ponechá adresy a dosáhne služby na adrese hostitele, kterou už zná. Cena je obvyklá: služba vidí hostitele VPN jako zdroj, takže logy po klientech a reverzní dotazy přestávají něco znamenat. To pokryje jednu tiskovou frontu nebo jednu administrátorskou stránku, ne hostitele na obou stranách, kteří se navzájem dosáhnou.
Co stále nebude fungovat a co zaznamenat
Broadcast nepřechází přes směrovaný tunel. DLNA, UPnP, procházení NetBIOS a Wake-on-LAN závisí na broadcastu nebo multicastu, který zařízení tun nenese, takže žádná trasa objevování nespraví. Bridging s dev tap rozšiřuje segment a s ním DHCP broadcast, ARP a každý další objevovací paket; dejte přednost unicast trase k hostiteli, například route 192.168.2.1 255.255.255.255, pro adresu na straně LAN vzdáleného routeru.
Dva routery, které oba používají 192.168.1.1 na stejné cestě, patří do stejné rodiny problémů: lokální adresa vždy vyhraje, takže stránka vzdáleného routeru zůstane nedostupná, dokud se jedna LAN nepřesune. Přidání druhého adaptéru na žádném z obou případů nic nemění.
Zaznamenejte důkazy, než cokoli upravíte: ip route get nebo Find-NetRoute, ping -c 3 na dotyčnou adresu, traceroute a tcpdump -ni tun0 icmp na klientu, poté směrovací tabulku a NAT počítadla na serveru. Ping, který funguje jedním směrem a umírá druhým, ukazuje na zpáteční cestu, ne na tunel, a právě tento rozdíl rozhoduje, kterou z oprav výše skutečně potřebujete.