VPN i kućna LAN mreža dijele istu podmrežu: prvo prođite rutu
Oba adaptera tvrde 192.168.1.0/24 i jedna ruta pobjeđuje. Prođite listu adaptera, pobjedničku rutu i povratni put prije nego što prenumerišete ili okrivite DNS.
Povezujete se na uredski VPN, ikona u traci postane zelena, intranet se učita, a pisač dva metra dalje prestane odgovarati. Dijeljeni resurs koji je radio jutros istekne na istom računalu, a nijedan zapis ne spominje pisač. Prvi refleks je DNS, jer ime koje se ne razrješava izgleda kao ime koje ne postoji, ali problem je u adresi: dva adaptera sada tvrde 192.168.1.0/24 i samo jedna ruta može pobijediti taj prefiks. Prođite to ovim redom i vidjet ćete koji je adapter preuzeo prije nego što išta promijenite.
Počnite od simptoma, ne od tunela
Znak je opseg. Ako intranet radi, a svaki lokalni uređaj ne radi, tunel je zdrav, a lokalni put nije. Ako lokalni uređaji rade, a intranet ne, obrnuto je. Ako sve radi osim jednog hosta, gledate jednu adresu koja postoji na obje strane.
Zapišite jednu lokalnu i jednu udaljenu adresu prije nego što dotaknete postavku. “Pisač” se ne može testirati; 192.168.1.40 može. Taj jedan korak sprječava najčešće izgubljen sat na ovom problemu, a to je prepisivanje DNS postavki zbog odluke o rutiranju.
Korak 1: vidite oba adaptera koja traže prefiks
Otvorite Mrežne veze (ncpa.cpl) i čitajte dva adaptera jedan uz drugi. Ethernet adapter pokazuje 192.168.1.50/24 s pristupnikom 192.168.1.1. VPN adapter pokazuje 192.168.1.201/24, koji je poslao poslužitelj. Oba su legitimna, oba vjeruju da je prefiks on-link, a stog će zadržati jednu rutu za njega.
Get-NetIPAddress -AddressFamily IPv4 navodi adrese, a Get-NetIPInterface | Sort-Object InterfaceMetric pokazuje redoslijed kojim će ih stog koristiti. Taj stupac metrike je odluka koju ćete upravo pročitati, pa zapišite brojeve umjesto da ih pokušavate zapamtiti.
Jeftino dokažite da je DNS teorija pogrešna: Resolve-DnsName printer.office.lan vraća istu adresu kao jučer. Ime se razriješilo; paket je zatim otišao kroz pogrešan adapter. Dvije minute ovdje štede poslijepodne u postavkama razrješivača.
Korak 2: pročitajte rutu koja je stvarno pobijedila
Find-NetRoute -RemoteIPAddress 192.168.1.40 ispisuje sučelje, sljedeći skok i izvor koje bi stog upotrijebio za tu adresu. Tretirajte taj izlaz kao odgovor, a ne kao nagovještaj. route print -4 daje cijelu tablicu kada želite vidjeti koji je zapis izgubio i za koliko.
Specifičnost pobjeđuje namjeru. Poslani 192.168.0.0/25 pobjeđuje lokalni 192.168.0.0/24 jer je prefiks duži, pa 192.168.0.0 do 192.168.0.127 izlaze kroz tunel, dok gornja polovica ostaje lokalna. Nestanak pola LAN mreže bez poruke o pogrešci ispravno je ponašanje te tablice.
tracert -d 192.168.1.40 to potvrđuje izvan tablice: ako je prvi skok adresa tunela umjesto vašeg usmjerivača, ruta je cijela priča. Na Linuxu je isto pitanje ip route get 192.168.1.40, koji ispisuje izvornu adresu i uređaj u jednom retku. Kada odgovor navede tun0, prestanite gledati u preglednik.
Korak 3: provjerite povratni put prije nego okrivite klijenta
Ispravna ruta prema naprijed ipak ne uspijeva ako druga strana ne može odgovoriti. Kada se LAN klijenta dosegne kroz tunel, pristupnik te LAN mreže mora znati gdje živi bazen tunela: ip route add 10.8.0.0/24 via 192.168.1.12 na tom usmjerivaču, i push “route 192.168.1.0 255.255.255.0” s poslužitelja da klijenti znaju povratni put.
Bez prvog zapisa odgovor napušta cilj prema svom zadanom pristupniku, koji prosljeđuje privatnu adresu davatelju usluga i odbacuje je. Simptom je jednosmjeran i lako se pogrešno pročita: zahtjevi se pojavljuju na tun0, odgovori nikada.
Pravilo masquerade na VPN hostu uklanja potrebu za tom statičkom rutom: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Ono također skriva prave izvorne adrese, što svako kasnije pitanje o zapisima čini težim. Ciljni host s pogrešnim zadanim pristupnikom daje istu tišinu, s ICMP preusmjeravanjem u najboljem slučaju i crnom rupom u uobičajenom, zato snimka pripada na oba kraja.
Korak 4: odaberite popravak s kojim možete živjeti
Za to se koristi pet popravaka i oni nisu zamjenjivi. Birajte prema tome što mora ostati dostupno istovremeno, a ne prema tome koja je naredba najkraća.
| 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 |
Metrike su jeftina opcija i ona po koju ljudi prvo posegnu. Promjena se odnosi na sučelje, pa radi dok je tunel podignut, i pripada u skriptu uz klijenta, a ne u ljusku koju ćete zaboraviti. Ne može dati istovremeni pristup istoj adresi na dvije mreže, i to je ograničenje koje sve ostale šalje niz tablicu.
Prenumeracija kućne LAN mreže na 10.10.0.0/24 čisto je rješenje: jedno obnavljanje DHCP najma plus rezervacije, redovi ispisa i čvrsto upisane adrese koje spominju stari raspon. Prenumeracija uredske strane obično nije vaša odluka. IPv6 potpuno uklanja sukob kada ga nose obje mreže, koristeći jedinstveni lokalni prefiks iz fd00::/8 umjesto nečega pamtljivog, ali testirajte aplikaciju preko TCP-a, ne pingom, jer ICMP može raditi dok usluga ne radi.
OpenVPN-ova vlastita opcija prevođenja zadnje je sredstvo, šalje se s poslužitelja u zapis direktorija specifičan za klijenta. Prima četiri parametra nakon naziva opcije — smjer, mrežu, masku i alias — a alias nije opcionalan: push "route 192.168.2.0 255.255.255.0" i push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Mreža i maska su raspon koji klijent vidi (192.168.2.0/24), alias je stvarni uredski raspon na strani poslužitelja (192.168.1.0/24), a poslana ruta čini taj vidljivi raspon dostupnim. Ured se tada tom klijentu pojavljuje pod 192.168.2.x. Dokumentirajte mapiranje u profilu, inače će ga sljedeća osoba otklanjati kao rutnu grešku.
Objavljivanje jedne usluge uska je verzija prevođenja i uopće ne treba OpenVPN-ovu opciju. DNAT pravilo na VPN hostu ponovno objavljuje jedan port, pa LAN zadržava svoje adrese i doseže uslugu na adresi hosta koju već zna. Cijena je uobičajena: usluga vidi VPN host kao izvor, pa zapisi po klijentu i obrnute pretrage gube smisao. To pokriva jedan red ispisa ili jednu administratorsku stranicu, ne hostove s obje strane koji dosežu jedan drugoga.
Što još neće raditi i što zabilježiti
Broadcast ne prelazi rutirani tunel. DLNA, UPnP, NetBIOS pregledavanje i Wake-on-LAN ovise o broadcastu ili multicastu koji tun uređaj ne nosi, pa nijedna ruta ne popravlja otkrivanje. Premošćivanje s dev tap proširuje segment, a s njim DHCP broadcast, ARP i svaki drugi paket otkrivanja; radije upotrijebite unicast rutu do hosta, poput route 192.168.2.1 255.255.255.255, za adresu LAN strane udaljenog usmjerivača.
Dva usmjerivača koji oba koriste 192.168.1.1 na istom putu pripadaju istoj obitelji problema: lokalna adresa uvijek pobjeđuje, pa stranica udaljenog usmjerivača ostaje nedostupna dok se jedna LAN mreža ne premjesti. Dodavanje drugog adaptera ne mijenja ništa ni u jednom slučaju.
Zabilježite dokaze prije nego što išta uredite: ip route get ili Find-NetRoute, ping -c 3 na dotičnu adresu, traceroute, i tcpdump -ni tun0 icmp na klijentu, zatim tablicu rutiranja i NAT brojače na poslužitelju. Ping koji radi u jednom smjeru i umire u drugom pokazuje na povratni put, ne na tunel, i ta jedna razlika odlučuje koji od gornjih popravaka stvarno trebate.