VPN og hjemmenetværk bruger samme subnet: gå ruten igennem først
Begge adaptere kræver 192.168.1.0/24, og én rute vinder. Gå adapterlisten, den vindende rute og returvejen igennem, før du omnummererer eller bebrejder DNS.
Du opretter forbindelse til kontorets VPN, ikonet i proceslinjen bliver grønt, intranettet indlæses, og printeren to meter væk holder op med at svare. Den delte mappe, der virkede i morges, får timeout på samme maskine, og ingen log nævner en printer. Refleksen er DNS, fordi et navn, der ikke opløses, ligner et navn, der ikke findes, men problemet er adressen: to adaptere kræver nu 192.168.1.0/24, og kun én rute kan vinde det præfiks. Gå det igennem i denne rækkefølge, og du vil se, hvilken adapter der tog det, før du ændrer noget.
Start ved symptomet, ikke ved tunnelen
Tegnet er omfanget. Hvis intranettet virker, og hver lokal enhed fejler, er tunnelen sund, og den lokale vej er det ikke. Hvis lokale enheder virker, og intranettet fejler, er det omvendt. Hvis alt virker undtagen én vært, ser du på én adresse, der findes på begge sider.
Skriv én lokal og én fjern adresse ned, før du rører en indstilling. “Printeren” kan ikke testes; 192.168.1.40 kan. Det ene skridt forhindrer den mest almindelige spildte time på dette problem, nemlig at omskrive DNS-indstillinger for en routingbeslutning.
Trin 1: se begge adaptere kræve præfikset
Åbn Netværksforbindelser (ncpa.cpl), og læs de to adaptere side om side. Ethernet-adapteren viser 192.168.1.50/24 med gateway 192.168.1.1. VPN-adapteren viser 192.168.1.201/24, sendt af serveren. Begge er legitime, begge tror, at præfikset er on-link, og stakken holder én rute til det.
Get-NetIPAddress -AddressFamily IPv4 viser adresserne, og Get-NetIPInterface | Sort-Object InterfaceMetric viser den rækkefølge, stakken vil bruge dem i. Den metrikkolonne er den beslutning, du er ved at læse, så notér tallene i stedet for at huske dem.
Bevis DNS-teorien billigt forkert: Resolve-DnsName printer.office.lan returnerer samme adresse som i går. Navnet blev opløst; pakken forlod derefter den forkerte adapter. To minutter her sparer en eftermiddag i resolverindstillinger.
Trin 2: læs den rute, der faktisk vandt
Find-NetRoute -RemoteIPAddress 192.168.1.40 viser den grænseflade, det næste hop og den kilde, stakken ville bruge til den adresse. Behandl det output som svaret, ikke som et hint. route print -4 giver hele tabellen, når du vil se, hvilken post der tabte og med hvor meget.
Specificitet slår hensigt. Et sendt 192.168.0.0/25 slår et lokalt 192.168.0.0/24, fordi præfikset er længere, så 192.168.0.0 til 192.168.0.127 forlader gennem tunnelen, mens den øvre halvdel forbliver lokal. At en halv LAN forsvinder uden fejlmeddelelse er korrekt adfærd for den tabel.
tracert -d 192.168.1.40 bekræfter det udefra tabellen: hvis det første hop er en tunneladresse i stedet for din egen router, er ruten hele historien. På Linux er det samme spørgsmål ip route get 192.168.1.40, som viser kildeadresse og enhed på én linje. Når svaret nævner tun0, så hold op med at kigge på browseren.
Trin 3: tjek returvejen, før du bebrejder klienten
En korrekt videresendt rute fejler stadig, hvis den fjerne side ikke kan svare. Når et klient-LAN nås gennem tunnelen, skal LAN'ets gateway vide, hvor tunnelpuljen bor: ip route add 10.8.0.0/24 via 192.168.1.12 på den router, og push “route 192.168.1.0 255.255.255.0” fra serveren, så klienterne kender returvejen.
Uden den første post forlader svaret målet mod sin standardgateway, som videresender en privat adresse til udbyderen og dropper den. Symptomet er ensrettet og let at læse forkert: anmodninger vises på tun0, svar aldrig.
En masquerade-regel på VPN-værten fjerner behovet for den statiske rute: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Den skjuler også de rigtige kildeadresser, hvilket gør hvert senere logspørgsmål sværere. En målvært med den forkerte standardgateway giver samme tavshed, med en ICMP-omdirigering som det bedste tilfælde og et sort hul som det normale, og derfor hører optagelsen til i begge ender.
Trin 4: vælg en reparation, du kan leve med
Der bruges fem reparationer til dette, og de kan ikke udskiftes. Vælg efter, hvad der skal forblive tilgængeligt samtidig, ikke efter hvilken kommando der 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 den billige mulighed og den, folk griber efter først. Ændringen gælder grænsefladen, så den virker, mens tunnelen er oppe, og den hører i et script ved siden af klienten frem for i en shell, du vil glemme. Den kan ikke give samtidig adgang til samme adresse på to netværk, og det er grænsen, der sender alle andre ned ad tabellen.
Omnummerering af hjemme-LAN'et til 10.10.0.0/24 er den rene løsning: én DHCP-leasefornyelse plus reservationerne, printerkøerne og de hardkodede adresser, der nævner det gamle område. Omnummerering af kontorsiden er normalt ikke din beslutning. IPv6 fjerner kollisionen helt, når begge netværk bærer det, med et unikt lokalt præfiks fra fd00::/8 i stedet for noget mindeværdigt, men test applikationen over TCP, ikke med en ping, fordi ICMP kan virke, mens tjenesten ikke gør.
OpenVPNs egen oversættelsesindstilling er den sidste udvej, sendt fra serveren ind i en klientspecifik mappeindgang. Den tager fire parametre efter indstillingens navn — retning, netværk, netmaske og alias — og alias er ikke valgfrit: 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". Netværket og netmasken er det område, klienten ser (192.168.2.0/24), alias er det rigtige kontorområde på serversiden (192.168.1.0/24), og den sendte rute er det, der gør det synlige område tilgængeligt. Kontoret fremstår derefter for den klient under 192.168.2.x. Dokumentér mappingen i profilen, ellers vil den næste person fejlfinde den som en routingfejl.
At udgive en enkelt tjeneste er den snævre version af oversættelse og har slet ikke brug for OpenVPNs indstilling. En DNAT-regel på VPN-værten genudgiver én port, så LAN'et beholder sine adresser og når tjenesten på den værtadresse, den allerede kender. Prisen er den sædvanlige: tjenesten ser VPN-værten som kilde, så logfiler per klient og omvendte opslag holder op med at betyde noget. Det dækker én printerkø eller én admin-side, ikke værter på begge sider, der når hinanden.
Hvad stadig ikke vil virke, og hvad du skal notere
Broadcast krydser ikke en routet tunnel. DLNA, UPnP, NetBIOS-gennemsyn og Wake-on-LAN afhænger af broadcast eller multicast, som en tun-enhed ikke bærer, så ingen rute reparerer opdagelsen. Brokobling med dev tap udvider segmentet og dermed DHCP-broadcast, ARP og enhver anden opdagelsespakke; foretræk en unicast-vært-rute som route 192.168.2.1 255.255.255.255 til LAN-siden af en fjern router.
To routere, der begge bruger 192.168.1.1 på samme vej, hører til samme familie af problemer: den lokale adresse vinder altid, så den fjerne routers side forbliver utilgængelig, indtil et LAN flytter sig. At tilføje en ekstra adapter ændrer intet i nogen af de to tilfælde.
Notér bevismaterialet, før du redigerer noget: ip route get eller Find-NetRoute, ping -c 3 til den pågældende adresse, en traceroute, og tcpdump -ni tun0 icmp på klienten, derefter routingtabellen og NAT-tællerne på serveren. En ping, der virker den ene vej og dør den anden, peger på returvejen, ikke på tunnelen, og netop den forskel afgør, hvilken af reparationerne ovenfor du faktisk har brug for.