VPN és otthoni LAN ugyanabban az alhálózatban: először kövesse az útvonalat
Mindkét adapter a 192.168.1.0/24-et igényli, és csak egy útvonal nyer. Kövesse az adapterlistát, a nyertes útvonalat és a visszautat, mielőtt átszámoz vagy a DNS-t hibáztatja.
Csatlakozik az irodai VPN-hez, a tálcán lévő ikon zöldre vált, betölt az intranet, és a két méterre lévő nyomtató abbahagyja a válaszadást. A megosztás, amely reggel működött, ugyanazon a gépen fut időtúllépésre, és egyetlen napló sem említ nyomtatót. A reflex a DNS, mert a fel nem oldódó név úgy néz ki, mint a nem létező név, de a probléma a cím: két adapter igényli most a 192.168.1.0/24-et, és csak egy útvonal nyerheti el ezt az előtagot. Járja végig ebben a sorrendben, és látni fogja, melyik adapter vette át, mielőtt bármit változtat.
Kezdje a tünettel, ne az alagúttal
A jel a hatókör. Ha az intranet működik és minden helyi eszköz elakad, az alagút egészséges, a helyi útvonal nem. Ha a helyi eszközök működnek és az intranet akad el, fordítva. Ha egy gazdagép kivételével minden működik, egyetlen címmel áll szemben, amely mindkét oldalon létezik.
Jegyezzen fel egy helyi és egy távoli címet, mielőtt bármelyik beállításhoz nyúl. A „nyomtató” nem tesztelhető; a 192.168.1.40 igen. Ez az egy lépés megelőzi a probléma leggyakoribb elvesztegetett óráját, ami a DNS-beállítások újraírása egy útválasztási döntés miatt.
1. lépés: lássa mindkét adaptert, amely az előtagot igényli
Nyissa meg a Hálózati kapcsolatokat (ncpa.cpl), és olvassa egymás mellett a két adaptert. Az Ethernet-adapter 192.168.1.50/24-et mutat, 192.168.1.1 átjáróval. A VPN-adapter 192.168.1.201/24-et mutat, amelyet a kiszolgáló küldött. Mindkettő jogos, mindkettő úgy gondolja, hogy az előtag on-link, és a verem egyetlen útvonalat tart fenn hozzá.
A Get-NetIPAddress -AddressFamily IPv4 felsorolja a címeket, a Get-NetIPInterface | Sort-Object InterfaceMetric pedig megmutatja a sorrendet, amelyben a verem használni fogja őket. Az a metrikaoszlop az a döntés, amelyet most el fog olvasni, ezért jegyezze fel a számokat, ne próbálja megjegyezni őket.
Cáfolja meg olcsón a DNS-elméletet: a Resolve-DnsName printer.office.lan ugyanazt a címet adja vissza, mint tegnap. A név feloldódott; a csomag aztán a rossz adapteren keresztül távozott. Két perc itt egy délutánt takarít meg a feloldó beállításaiban.
2. lépés: olvassa el az útvonalat, amely valóban nyert
A Find-NetRoute -RemoteIPAddress 192.168.1.40 kiírja azt az interfészt, következő ugrást és forrást, amelyet a verem ehhez a címhez használna. Tekintse ezt a kimenetet válasznak, nem tippnek. A route print -4 a teljes táblát adja, amikor látni akarja, melyik bejegyzés vesztett és mennyivel.
A specificitás legyőzi a szándékot. Egy küldött 192.168.0.0/25 legyőzi a helyi 192.168.0.0/24-et, mert az előtag hosszabb, így a 192.168.0.0–192.168.0.127 az alagúton távozik, míg a felső fele helyi marad. Hogy egy fél LAN hibaüzenet nélkül eltűnik, az a tábla helyes viselkedése.
A tracert -d 192.168.1.40 a táblán kívülről igazolja: ha az első ugrás alagútcím a saját routere helyett, akkor az útvonal a teljes történet. Linuxon ugyanez a kérdés az ip route get 192.168.1.40, amely egy sorban kiírja a forráscímet és az eszközt. Amikor a válasz a tun0-t említi, hagyja abba a böngésző nézegetését.
3. lépés: ellenőrizze a visszautat, mielőtt a klienst hibáztatja
A helyes előre irányuló útvonal is elbukik, ha a túloldal nem tud válaszolni. Amikor egy kliens LAN-ját az alagúton keresztül érik el, annak a LAN-nak az átjárójának tudnia kell, hol él az alagútpool: ip route add 10.8.0.0/24 via 192.168.1.12 azon a routeren, és push „route 192.168.1.0 255.255.255.0” a kiszolgálóról, hogy a kliensek ismerjék a visszautat.
Az első bejegyzés nélkül a válasz elhagyja a célt az alapértelmezett átjárója felé, amely továbbít egy privát címet a szolgáltatónak, és eldobja. A tünet egyirányú és könnyen félreolvasható: a kérések megjelennek a tun0-n, a válaszok soha.
A VPN-gazdagépen egy masquerade-szabály megszünteti a statikus útvonal szükségességét: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Elrejti a valódi forráscímeket is, ami minden későbbi naplókérdést nehezebbé tesz. A rossz alapértelmezett átjárójú célgazdagép ugyanazt a csendet produkálja, legjobb esetben ICMP-átirányítással, normál esetben fekete lyukkal, ezért a rögzítés mindkét végére tartozik.
4. lépés: válasszon olyan javítást, amellyel együtt tud élni
Erre öt javítás szolgál, és nem helyettesíthetők egymással. Aszerint válasszon, minek kell egyszerre elérhetőnek maradnia, nem aszerint, melyik parancs a legrövidebb.
| 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 |
A metrikák az olcsó lehetőség, és az, amihez az emberek először nyúlnak. A változás az interfészre vonatkozik, tehát addig működik, amíg az alagút fent van, és a kliens melletti szkriptbe való, nem egy olyan shellbe, amelyet el fog felejteni. Nem adhat egyidejű hozzáférést ugyanahhoz a címhez két hálózaton, és ez a korlát küldi a többieket a tábla aljára.
Az otthoni LAN átszámozása 10.10.0.0/24-re a tiszta megoldás: egy DHCP-bérlet megújítása, valamint a régi tartományt említő foglalások, nyomtatási sorok és keményen kódolt címek. Az irodai oldal átszámozása általában nem az Ön döntése. Az IPv6 teljesen megszünteti az ütközést, ha mindkét hálózat hordozza, egyedi helyi előtaggal a fd00::/8-ból valami könnyen megjegyezhető helyett, de az alkalmazást TCP-n tesztelje, ne pinggel, mert az ICMP működhet, miközben a szolgáltatás nem.
Az OpenVPN saját fordítási opciója az utolsó lehetőség, amelyet a kiszolgáló küld egy kliensspecifikus könyvtárbejegyzésbe. Az opció neve után négy paramétert vesz át — irány, hálózat, maszk és alias —, és az alias nem opcionális: push "route 192.168.2.0 255.255.255.0" és push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". A hálózat és a maszk az a tartomány, amelyet a kliens lát (192.168.2.0/24), az alias a valódi irodai tartomány a kiszolgáló oldalán (192.168.1.0/24), és a küldött útvonal teszi elérhetővé ezt a látható tartományt. Az iroda ekkor 192.168.2.x alatt jelenik meg annak a kliensnek. Dokumentálja a leképezést a profilban, különben a következő ember útválasztási hibaként fogja hibakeresni.
Egyetlen szolgáltatás közzététele a fordítás szűk változata, és egyáltalán nem igényli az OpenVPN opcióját. A VPN-gazdagépen egy DNAT-szabály újra közzétesz egy portot, így a LAN megtartja címeit, és a szolgáltatást azon a gazdagépcímen éri el, amelyet már ismer. A költség a szokásos: a szolgáltatás a VPN-gazdagépet látja forrásként, így a kliensenkénti naplók és a fordított keresések értelmüket vesztik. Ez egy nyomtatási sort vagy egy adminoldalt fed le, nem pedig a két oldal gazdagépeit, amelyek elérik egymást.
Mi nem fog továbbra sem működni, és mit rögzítsen
A broadcast nem halad át irányított alagúton. A DLNA, az UPnP, a NetBIOS-böngészés és a Wake-on-LAN olyan broadcast vagy multicast függvénye, amelyet a tun-eszköz nem hordoz, ezért egyetlen útvonal sem javítja a felderítést. A dev tap-pel való áthidalás kiterjeszti a szegmenst, és vele a DHCP-broadcastokat, az ARP-t és minden más felderítő csomagot; részesítse előnyben az unicast gazdagép-útvonalat, például route 192.168.2.1 255.255.255.255, egy távoli router LAN oldali címéhez.
Két router, amely mindkettő a 192.168.1.1-et használja ugyanazon az úton, ugyanahhoz a problémaosztályhoz tartozik: a helyi cím mindig nyer, így a távoli router oldala elérhetetlen marad, amíg egy LAN el nem költözik. Egy második adapter hozzáadása egyik esetben sem változtat semmit.
Rögzítse a bizonyítékokat, mielőtt bármit szerkeszt: ip route get vagy Find-NetRoute, ping -c 3 a kérdéses címre, traceroute, és tcpdump -ni tun0 icmp a kliensen, majd az útválasztási tábla és a NAT-számlálók a kiszolgálón. Az a ping, amely egy irányban működik és a másikban meghal, a visszaútra mutat, nem az alagútra, és ez az egyetlen különbség dönti el, melyik fenti javításra van valóban szüksége.