VPN en thuisnetwerk op hetzelfde subnet: loop eerst de route na
Beide adapters claimen 192.168.1.0/24 en één route wint. Loop de adapterlijst, de winnende route en de terugweg na voordat u hernummert of DNS de schuld geeft.
Je maakt verbinding met de VPN van kantoor, het pictogram in de systeemvak wordt groen, het intranet laadt, en de printer twee meter verderop antwoordt niet meer. De share die vanochtend werkte, loopt op dezelfde machine in een time-out, en geen enkel logboek noemt een printer. De reflex is DNS, want een naam die niet oplost lijkt op een naam die niet bestaat, maar het adres is het probleem: twee adapters claimen nu 192.168.1.0/24 en slechts één route kan dat prefix winnen. Loop het in deze volgorde na en je ziet welke adapter het heeft gepakt voordat je iets verandert.
Begin bij het symptoom, niet bij de tunnel
De aanwijzing is bereik. Als het intranet werkt en elk lokaal apparaat faalt, is de tunnel gezond en de lokale route niet. Als lokale apparaten werken en het intranet faalt, andersom. Als alles werkt behalve één host, kijk je naar één adres dat aan beide kanten bestaat.
Schrijf één lokaal en één extern adres op voordat je een instelling aanraakt. “De printer” is niet testbaar; 192.168.1.40 wel. Die ene stap voorkomt het meest verspilde uur bij dit probleem, namelijk DNS-instellingen herschrijven voor een routingbeslissing.
Stap 1: zie beide adapters het prefix claimen
Open Netwerkverbindingen (ncpa.cpl) en lees de twee adapters naast elkaar. De Ethernet-adapter toont 192.168.1.50/24 met gateway 192.168.1.1. De VPN-adapter toont 192.168.1.201/24, door de server gepusht. Beide zijn legitiem, beide denken dat het prefix on-link is, en de stack houdt er één route voor aan.
Get-NetIPAddress -AddressFamily IPv4 somt de adressen op, en Get-NetIPInterface | Sort-Object InterfaceMetric toont de volgorde waarin de stack ze gebruikt. Die metriekkolom is de beslissing die je op het punt staat te lezen, dus noteer de getallen in plaats van ze te onthouden.
Weerleg de DNS-theorie goedkoop: Resolve-DnsName printer.office.lan geeft hetzelfde adres als gisteren. De naam is opgelost; daarna verliet het pakket de verkeerde adapter. Twee minuten hier besparen een middag in resolverinstellingen.
Stap 2: lees de route die echt won
Find-NetRoute -RemoteIPAddress 192.168.1.40 toont de interface, de volgende hop en de bron die de stack voor dat adres zou gebruiken. Behandel die uitvoer als het antwoord, niet als een hint. route print -4 geeft de hele tabel wanneer je wilt zien welk item verloor en met hoeveel.
Specificiteit wint van bedoeling. Een gepushte 192.168.0.0/25 verslaat een lokale 192.168.0.0/24 omdat het prefix langer is, dus 192.168.0.0 tot 192.168.0.127 gaat door de tunnel naar buiten terwijl de bovenste helft lokaal blijft. Dat een half netwerk zonder foutmelding verdwijnt, is correct gedrag voor die tabel.
tracert -d 192.168.1.40 bevestigt het van buiten de tabel: als de eerste hop een tunneladres is in plaats van je eigen router, is de route het hele verhaal. Op Linux is dezelfde vraag ip route get 192.168.1.40, dat bronadres en apparaat op één regel toont. Als het antwoord tun0 noemt, stop dan met naar de browser kijken.
Stap 3: controleer de terugweg voordat je de client de schuld geeft
Een correcte route vooruit faalt alsnog als de andere kant niet kan antwoorden. Wanneer een clientnetwerk via de tunnel wordt bereikt, moet de gateway van dat netwerk weten waar de tunnelpool woont: ip route add 10.8.0.0/24 via 192.168.1.12 op die router, en push “route 192.168.1.0 255.255.255.0” vanaf de server zodat clients de terugweg kennen.
Zonder de eerste vermelding verlaat het antwoord het doel richting zijn standaardgateway, die een privéadres naar de provider doorstuurt en laat vallen. Het symptoom is eenrichtingsverkeer en makkelijk verkeerd te lezen: verzoeken verschijnen op tun0, antwoorden nooit.
Een masquerade-regel op de VPN-host haalt de noodzaak van die statische route weg: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Hij verbergt ook de echte bronadressen, wat elke latere logvraag moeilijker maakt. Een doelhoofd met de verkeerde standaardgateway levert dezelfde stilte, met een ICMP-omleiding in het beste geval en een zwart gat in het normale geval, en daarom hoort de capture aan beide uiteinden.
Stap 4: kies een reparatie waar je mee kunt leven
Hiervoor worden vijf reparaties gebruikt, en ze zijn niet uitwisselbaar. Kies op basis van wat tegelijk bereikbaar moet blijven, niet op basis van welke opdracht het kortst is.
| 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 |
Metrieken zijn de goedkope optie en degene waar mensen als eerste naar grijpen. De wijziging geldt voor de interface, dus werkt zolang de tunnel omhoog is, en hoort in een script naast de client in plaats van in een shell die je vergeet. Het kan geen gelijktijdige toegang tot hetzelfde adres op twee netwerken geven, en dat is de grens die alle anderen de tabel afstuurt.
Het thuisnetwerk hernummeren naar 10.10.0.0/24 is de schone oplossing: één DHCP-leasevernieuwing plus de reserveringen, printerwachtrijen en hardgecodeerde adressen die het oude bereik noemen. De kantoorzijde hernummeren is meestal niet jouw beslissing. IPv6 haalt de botsing volledig weg als beide netwerken het dragen, met een uniek lokaal prefix uit fd00::/8 in plaats van iets dat je onthoudt, maar test de toepassing via TCP, niet met een ping, want ICMP kan werken terwijl de dienst dat niet doet.
De eigen vertaaloptie van OpenVPN is het laatste redmiddel, vanaf de server in een client-specifieke mapvermelding gepusht. Hij neemt vier parameters na de optienaam — richting, netwerk, netmasker en alias — en de alias is niet optioneel: push "route 192.168.2.0 255.255.255.0" en push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Het netwerk en het masker zijn het bereik dat de client ziet (192.168.2.0/24), de alias is het echte kantoorbereik aan de serverkant (192.168.1.0/24), en de gepushte route maakt dat zichtbare bereik bereikbaar. Kantoor verschijnt dan voor die client onder 192.168.2.x. Documenteer de mapping in het profiel, anders debugt de volgende persoon het als een routingfout.
Eén dienst publiceren is de smalle versie van vertalen, en heeft de optie van OpenVPN helemaal niet nodig. Een DNAT-regel op de VPN-host publiceert één poort opnieuw, zodat het netwerk zijn adressen houdt en de dienst bereikt op het hostadres dat het al kent. De prijs is de gebruikelijke: de dienst ziet de VPN-host als bron, dus logs per client en reverse-lookups betekenen niets meer. Dat dekt één printerwachtrij of één beheerpagina, niet hosts aan beide kanten die elkaar bereiken.
Wat toch niet gaat werken, en wat je moet vastleggen
Broadcast gaat niet over een gerouteerde tunnel. DLNA, UPnP, NetBIOS-browsen en Wake-on-LAN zijn afhankelijk van broadcast of multicast die een tun-apparaat niet draagt, dus geen route repareert de ontdekking. Bridgen met dev tap verlengt het segment, en daarmee DHCP-broadcasts, ARP en elk ander ontdekkingspakket; geef de voorkeur aan een unicast hostroute zoals route 192.168.2.1 255.255.255.255 voor het LAN-zijadres van een externe router.
Twee routers die beide 192.168.1.1 op hetzelfde pad gebruiken, horen bij dezelfde familie van problemen: het lokale adres wint altijd, dus de pagina van de verre router blijft onbereikbaar tot een netwerk verhuist. Een tweede adapter toevoegen verandert in geen van beide gevallen iets.
Leg het bewijs vast voordat je iets aanpast: ip route get of Find-NetRoute, ping -c 3 naar het betreffende adres, een traceroute, en tcpdump -ni tun0 icmp op de client, daarna de routetabel en NAT-tellers op de server. Een ping die één kant op werkt en de andere kant sterft, wijst op de terugweg, niet op de tunnel, en precies dat onderscheid bepaalt welke van de reparaties hierboven je echt nodig hebt.