VPN og heimenett på same subnett: gå ruta først
Begge adapterane krev 192.168.1.0/24, og berre éi rute vinn. Gå gjennom adapterlista, den vinnande ruta og returvegen før du omnummererer eller klandrar DNS.
Du koplar til kontoret sitt VPN, ikonet i systemkurven blir grønt, intranettet lastar, og skrivaren to meter unna sluttar å svare. Den delte mappa som verka i morgon, går ut på tid på same maskin, og ingen logg nemner ein skrivar. Refleksen er DNS, fordi eit namn som ikkje blir løyst opp ser ut som eit namn som ikkje finst, men problemet er adressa: to adapterar krev no 192.168.1.0/24, og berre éi rute kan vinne det prefikset. Gå gjennom det i denne rekkjefølgja, og du vil sjå kva adapter som tok det, før du endrar noko.
Start ved symptomet, ikkje ved tunnelen
Teiknet er omfanget. Viss intranettet verkar og kvar lokal eining feilar, er tunnelen sunn og den lokale vegen ikkje. Viss lokale einingar verkar og intranettet feilar, er det omvendt. Viss alt verkar bortsett frå éin vert, ser du på éi adresse som finst på begge sider.
Skriv ned éi lokal og éi ekstern adresse før du rører ei innstilling. «Skrivaren» kan ikkje testast; 192.168.1.40 kan. Det eine trinnet hindrar den vanlegaste bortkasta timen på dette problemet, nemleg å skrive om DNS-innstillingar for ei rutingsavgjerd.
Trinn 1: sjå begge adapterane krev prefikset
Opne Nettverkskoblingar (ncpa.cpl) og les dei to adapterane side ved side. Ethernet-adapteren viser 192.168.1.50/24 med gateway 192.168.1.1. VPN-adapteren viser 192.168.1.201/24, send av serveren. Begge er legitime, begge trur prefikset er on-link, og stakken held éi rute for det.
Get-NetIPAddress -AddressFamily IPv4 listar adressene, og Get-NetIPInterface | Sort-Object InterfaceMetric viser rekkjefølgja stakken brukar dei i. Den metrikk-kolonnen er avgjerda du er i ferd med å lese, så noter tala i staden for å prøve å hugse dei.
Motbevis DNS-teorien billeg: Resolve-DnsName printer.office.lan returnerer same adresse som i går. Namnet vart løyst opp; deretter forlét pakken den gale adapteren. To minutt her sparer ein ettermiddag i oppløysarinnstillingar.
Trinn 2: les ruta som faktisk vann
Find-NetRoute -RemoteIPAddress 192.168.1.40 skriv ut grensesnittet, neste hopp og kjelda stakken ville brukt for den adressa. Handsame utdataa som svaret, ikkje som eit hint. route print -4 gir heile tabellen når du vil sjå kva oppføring som tapte og kor mykje.
Spesifisitet slår hensikt. Ein dytta 192.168.0.0/25 slår ein lokal 192.168.0.0/24 fordi prefikset er lengre, så 192.168.0.0 til 192.168.0.127 går ut gjennom tunnelen medan den øvre halvdelen blir lokal. At eit halvt nettverk forsvinn utan feilmelding, er rett åtferd for den tabellen.
tracert -d 192.168.1.40 stadfester det utanfor tabellen: viss fyrste hopp er ei tunneladresse i staden for din eigen ruter, er ruta heile historia. På Linux er det same spørsmålet ip route get 192.168.1.40, som skriv kjeldeadresse og eining på éi linje. Når svaret nemner tun0, slutt å sjå på nettlesaren.
Trinn 3: sjekk returvegen før du klandrar klienten
Ei korrekt rute framover feilar likevel viss den fjerne sida ikkje kan svare. Når eit klientnett blir nådd gjennom tunnelen, må gatewayen i det nettet vite kvar tunnelpoolen bur: ip route add 10.8.0.0/24 via 192.168.1.12 på den ruteren, og push «route 192.168.1.0 255.255.255.0» frå serveren slik at klientane kjenner returvegen.
Utan den fyrste oppføringa forlèt svaret målet mot sin standardgateway, som videresender ei privat adresse til leverandøren og slepp henne. Symptomet er einvegskøyrt og lett å lese feil: førespurnader dukkar opp på tun0, svar aldri.
Ein masquerade-regel på VPN-verten fjernar behovet for den statiske ruta: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Han gøymer òg dei verkelege kjeldeadressene, noko som gjer kvart seinare loggspørsmål vanskelegare. Ein målvert med feil standardgateway gir same stille, med ei ICMP-omdirigering i beste fall og eit svart hol i det normale tilfellet, og difor høyrer opptaket heime i begge endar.
Trinn 4: vel ein reparasjon du kan leve med
Det blir brukt fem reparasjonar til dette, og dei kan ikkje bytast om. Vel etter kva som må vere tilgjengeleg samstundes, ikkje etter kva kommando som er kortast.
| 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 |
Metrikkar er det billege alternativet og det folk grip etter fyrst. Endringa gjeld grensesnittet, så ho verkar medan tunnelen er oppe, og ho høyrer heime i eit skript ved sida av klienten framfor i eit skal du kjem til å gløyme. Ho kan ikkje gi samstundes tilgang til same adresse på to nettverk, og det er grensa som sender alle andre nedover tabellen.
Omnummerering av heimenettet til 10.10.0.0/24 er den reine løysinga: éi DHCP-leasefornying pluss reserveringane, skrivarkøane og dei hardkoda adressene som nemner det gamle området. Omnummerering av kontorsida er vanlegvis ikkje di avgjerd. IPv6 fjernar kollisjonen heilt når begge nettverka ber det, med eit unikt lokalt prefiks frå fd00::/8 i staden for noko minneverdig, men test applikasjonen over TCP, ikkje med ping, fordi ICMP kan verke medan tenesta ikkje gjer det.
OpenVPN sin eigen omsetjingsopsjon er den siste utvegen, dytta frå serveren inn i ei klientspesifikk katalogoppføring. Han tar fire parameterar etter opsjonsnamnet — retning, nettverk, nettmaske og alias — og aliaset er ikkje valfritt: push "route 192.168.2.0 255.255.255.0" og push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Nettverket og nettmaska er området klienten ser (192.168.2.0/24), aliaset er det verkelege kontorområdet på serversida (192.168.1.0/24), og den dytta ruta er det som gjer det synlege området tilgjengeleg. Kontoret framstår då for den klienten under 192.168.2.x. Dokumenter mappinga i profilen, elles vil neste person feilsøkje det som ein rutingsfeil.
Å publisere éi enkel teneste er den smale versjonen av omsetjing, og ho treng ikkje OpenVPN sin opsjon i det heile. Ein DNAT-regel på VPN-verten publiserer éin port på nytt, så nettverket held på adressene sine og når tenesta på vertsadressa det alt kjenner. Kostnaden er den vanlege: tenesta ser VPN-verten som kjelde, så loggar per klient og omvende oppslag sluttar å bety noko. Det dekkjer éi skrivarkø eller éi administrasjonsside, ikkje vertar på begge sider som når kvarandre.
Kva som framleis ikkje vil verke, og kva som skal noterast
Kringkasting kryssar ikkje ein ruta tunnel. DLNA, UPnP, NetBIOS-blaing og Wake-on-LAN er avhengige av kringkasting eller multicast som ei tun-eining ikkje ber, så inga rute reparerer oppdaginga. Bruing med dev tap utvidar segmentet, og med det DHCP-kringkasting, ARP og kvar annan oppdagingspakke; føretrekk ei unicast vertsrute som route 192.168.2.1 255.255.255.255 for LAN-sideadressa til ein ekstern ruter.
To rutarar som begge brukar 192.168.1.1 på same veg, høyrer til same familie av problem: den lokale adressa vinn alltid, så sida til den fjerne rutaren blir utilgjengeleg til eitt nettverk flyttar. Å leggje til ein annan adapter endrar ingenting i noko av tilfella.
Noter bevisa før du redigerer noko: ip route get eller Find-NetRoute, ping -c 3 til den aktuelle adressa, ein traceroute, og tcpdump -ni tun0 icmp på klienten, deretter rutetabellen og NAT-teljarane på serveren. Ein ping som verkar den eine vegen og døyr den andre, peikar på returvegen, ikkje på tunnelen, og nettopp den skilnaden avgjer kva av reparasjonane ovanfor du faktisk treng.