VPN og hjemmenettverk på samme subnett: gå ruten først
Begge adapterne krever 192.168.1.0/24, og bare én rute vinner. Gå gjennom adapterlisten, den vinnende ruten og returveien før du omnummererer eller klandrer DNS.
Du kobler til kontorets VPN, ikonet i systemkurven blir grønt, intranettet lastes, og skriveren to meter unna slutter å svare. Den delte mappen som virket i morges, går ut på tid på samme maskin, og ingen logg nevner en skriver. Refleksen er DNS, fordi et navn som ikke løses opp ser ut som et navn som ikke finnes, men problemet er adressen: to adaptere krever nå 192.168.1.0/24, og bare én rute kan vinne det prefikset. Gå gjennom det i denne rekkefølgen, og du vil se hvilken adapter som tok det, før du endrer noe.
Start ved symptomet, ikke ved tunnelen
Tegnet er omfanget. Hvis intranettet virker og hver lokal enhet feiler, er tunnelen sunn og den lokale veien ikke. Hvis lokale enheter virker og intranettet feiler, er det omvendt. Hvis alt virker bortsett fra én vert, ser du på én adresse som finnes på begge sider.
Skriv ned én lokal og én ekstern adresse før du rører en innstilling. «Skriveren» kan ikke testes; 192.168.1.40 kan. Det ene trinnet hindrer den vanligste bortkastede timen på dette problemet, nemlig å skrive om DNS-innstillinger for en rutingbeslutning.
Trinn 1: se begge adapterne kreve prefikset
Åpne Nettverkskoblinger (ncpa.cpl) og les de to adapterne 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, sendt av serveren. Begge er legitime, begge tror prefikset er on-link, og stakken holder én rute for det.
Get-NetIPAddress -AddressFamily IPv4 lister adressene, og Get-NetIPInterface | Sort-Object InterfaceMetric viser rekkefølgen stakken bruker dem i. Den metrikk-kolonnen er beslutningen du er i ferd med å lese, så noter tallene i stedet for å prøve å huske dem.
Motbevis DNS-teorien billig: Resolve-DnsName printer.office.lan returnerer samme adresse som i går. Navnet ble løst opp; deretter forlot pakken den gale adapteren. To minutter her sparer en ettermiddag i oppløserinnstillinger.
Trinn 2: les ruten som faktisk vant
Find-NetRoute -RemoteIPAddress 192.168.1.40 skriver ut grensesnittet, neste hopp og kilden stakken ville brukt for den adressen. Behandle utdataene som svaret, ikke som et hint. route print -4 gir hele tabellen når du vil se hvilken oppføring som tapte og hvor mye.
Spesifisitet slår hensikt. En dyttet 192.168.0.0/25 slår en 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 mens den øvre halvdelen blir lokal. At et halvt nettverk forsvinner uten feilmelding, er riktig oppførsel for den tabellen.
tracert -d 192.168.1.40 bekrefter det utenfor tabellen: hvis første hopp er en tunneladresse i stedet for din egen ruter, er ruten hele historien. På Linux er det samme spørsmålet ip route get 192.168.1.40, som skriver kildeadresse og enhet på én linje. Når svaret nevner tun0, slutt å se på nettleseren.
Trinn 3: sjekk returveien før du klandrer klienten
En korrekt rute fremover feiler likevel hvis den fjerne siden ikke kan svare. Når et klientnettverk nås gjennom tunnelen, må gatewayen i det nettverket vite hvor tunnelpoolen bor: 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» fra serveren slik at klientene kjenner returveien.
Uten den første oppføringen forlater svaret målet mot sin standardgateway, som videresender en privat adresse til leverandøren og slipper den. Symptomet er enveiskjørt og lett å lese feil: forespørsler dukker opp på tun0, svar aldri.
En masquerade-regel på VPN-verten fjerner behovet for den statiske ruten: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Den skjuler også de virkelige kildeadressene, noe som gjør hvert senere loggspørsmål vanskeligere. En målvert med feil standardgateway gir samme stillhet, med en ICMP-omdirigering i beste fall og et svart hull i det normale tilfellet, og derfor hører opptaket hjemme i begge ender.
Trinn 4: velg en reparasjon du kan leve med
Det brukes fem reparasjoner til dette, og de kan ikke byttes om. Velg etter hva som må forbli tilgjengelig samtidig, ikke etter hvilken kommando som er kortest.
| 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 |
Metrikker er det billige alternativet og det folk griper etter først. Endringen gjelder grensesnittet, så den virker mens tunnelen er oppe, og den hører hjemme i et skript ved siden av klienten fremfor i et skall du kommer til å glemme. Den kan ikke gi samtidig tilgang til samme adresse på to nettverk, og det er grensen som sender alle andre nedover tabellen.
Omnummerering av hjemmenettverket til 10.10.0.0/24 er den rene løsningen: én DHCP-leasefornyelse pluss reservasjonene, skriverkøene og de hardkodede adressene som nevner det gamle området. Omnummerering av kontorsiden er vanligvis ikke din beslutning. IPv6 fjerner kollisjonen helt når begge nettverkene bærer det, med et unikt lokalt prefiks fra fd00::/8 i stedet for noe minneverdig, men test applikasjonen over TCP, ikke med ping, fordi ICMP kan virke mens tjenesten ikke gjør det.
OpenVPNs egen oversettelsesopsjon er den siste utveien, dyttet fra serveren inn i en klientspesifikk katalogoppføring. Den tar fire parametere etter opsjonsnavnet — retning, nettverk, nettmaske og alias — og aliaset er ikke valgfritt: 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 nettmasken er området klienten ser (192.168.2.0/24), aliaset er det virkelige kontorområdet på serversiden (192.168.1.0/24), og den dyttede ruten er det som gjør det synlige området tilgjengelig. Kontoret fremstår da for den klienten under 192.168.2.x. Dokumenter mappingen i profilen, ellers vil neste person feilsøke det som en rutingfeil.
Å publisere én enkelt tjeneste er den smale versjonen av oversettelse, og den trenger ikke OpenVPNs opsjon i det hele tatt. En DNAT-regel på VPN-verten publiserer én port på nytt, så nettverket beholder adressene sine og når tjenesten på vertsadressen det allerede kjenner. Kostnaden er den vanlige: tjenesten ser VPN-verten som kilde, så logger per klient og omvendte oppslag slutter å bety noe. Det dekker én skriverkø eller én administrasjonsside, ikke verter på begge sider som når hverandre.
Hva som fortsatt ikke vil virke, og hva som skal noteres
Kringkasting krysser ikke en rutet tunnel. DLNA, UPnP, NetBIOS-blaing og Wake-on-LAN er avhengige av kringkasting eller multicast som en tun-enhet ikke bærer, så ingen rute reparerer oppdagelsen. Broing med dev tap utvider segmentet, og med det DHCP-kringkasting, ARP og hver annen oppdagelsespakke; foretrekk en unicast vertsrute som route 192.168.2.1 255.255.255.255 for LAN-sideadressen til en ekstern ruter.
To rutere som begge bruker 192.168.1.1 på samme vei, tilhører samme familie av problemer: den lokale adressen vinner alltid, så siden til den fjerne ruteren forblir utilgjengelig til ett nettverk flytter. Å legge til en annen adapter endrer ingenting i noen av tilfellene.
Noter bevisene før du redigerer noe: ip route get eller Find-NetRoute, ping -c 3 til den aktuelle adressen, en traceroute, og tcpdump -ni tun0 icmp på klienten, deretter rutingtabellen og NAT-tellerne på serveren. En ping som virker den ene veien og dør den andre, peker på returveien, ikke på tunnelen, og nettopp den forskjellen avgjør hvilken av reparasjonene ovenfor du faktisk trenger.