Geen route repareert een VPN-pool die jouw LAN overlapt

De app beweert dat de tunnel gezond is, en toch antwoordt de helft van de bestemmingen die je nodig hebt nooit. De reflex is een route toevoegen of een metriek verlagen, en precies die reflex is de mythe die je het eerst moet doden. Wanneer het eigen LAN van de client en de pool van de tunnel hetzelfde prefix claimen, houdt de routingtabel twee onverenigbare feiten vast, en noch een standaardroute noch een metriek lost ze op. De reparatie is een adresseringsbeslissing, en geen routebewerking vervangt die.

Waarom een extra route één prefix niet kan splitsen

Een route kan twee claims op één prefix niet scheiden, daarom is de verstandige zet stoppen met zoeken naar de juiste routelijn. De stack plaatst geen identiek prefix vóór de verbonden route, en een specifiekere vermelding vangt het adres wel, maar maakt de lokale host die het bezit onbereikbaar. Wat op een routeringsprobleem lijkt, is een adresseringsconflict, en beide reparaties veranderen adressen in plaats van routes. Test de bewering op je eigen machine voordat je haar accepteert.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Vraag het systeem naar één adres en let op welke interface het noemt. Linux, macOS en Windows antwoorden elk met een alleen-lezen opzoeking die de gekozen interface en de volgende hop meldt zonder iets te verzenden. Wijst het antwoord op de fysieke adapter terwijl de tunnel actief is, dan behandelt de kernel het adres als on-link en niet als iets dat de tunnel zou kunnen dragen.

Zet het prefix dat de provider heeft toegekend naast dat wat de thuisrouter bedient en vergelijk ze als strings. Een exacte overeenkomst is het duidelijke geval, en een bredere providerpool die het thuissubnet bevat faalt op dezelfde manier, maar is makkelijker te missen. Twee prefixen die alleen op elkaar lijken zijn geen conflict, dus schrijf ze beide op voordat je iets verandert.

Lees de pool die de client werkelijk kreeg

Lees wat de client ontving, niet de marketingpagina van de provider. Zet de detaillering van het log van een OpenVPN-client hoger en de door de server geduwde routes verschijnen erin, wat de tunnelprefixen onthult; elders duikt de pool op in de verbindingsdetails of op de adapter zelf. Vraag de provider om de volledige lijst van privébereiken die hij gebruikt, want een enkele /24 vandaag kan morgen twee zijn. De gebruikelijke RFC 1918-blokken vermijden is niet hetzelfde als de toewijzing vermijden die je werkelijk hebt gekregen.

Een pool kan ook krimpen of tussen regio's verschuiven, dus de lijst heeft een datum en een eigenaar nodig. Behandel elk providerantwoord dat ouder is dan je laatste planwijziging als een gok, niet als een feit. Vraag opnieuw voordat je je aan een bereik bindt, en bewaar het antwoord bij de netwerknotities zodat de volgende persoon het bewijs erft.

Hernummeren is de reparatie die je kunt doen

Als de VPN-server niet van jou is om te wijzigen, is het thuis-LAN verplaatsen de enige beschikbare reparatie, en dat is de gebruikelijke situatie bij een commerciële provider. Kies een bereik buiten de pool van de provider en buiten de bereiken die je later nodig kunt hebben, en controleer het tegen elke andere locatie die je via een tunnel bereikt. Verwacht een korte onderbreking en een langere staart van vergeten apparaten: een apparaat dat het oude adres nog heeft, lijkt te werken tot het de gateway nodig heeft.

1. Eerst inventaris: het eigen adres van de router, de DHCP-scope, reserveringen, port forwardings en elk apparaat waarvan het adres met de hand is getypt.
2. Wijzig daarna het LAN-prefix van de router en de DHCP-scope samen binnen een onderhoudsvenster, en vernieuw bekabelde leases vóór draadloze.
3. Corrigeer vervolgens de statische adressen: printers, netwerkopslag, alles met een hardgecodeerde gateway.
4. Verbind ten slotte de VPN-client opnieuw en bevestig dat het tunneladres niet langer botst met het LAN.

Werk de adressen in die volgorde af in plaats van allemaal tegelijk, en houd het oude bereik een tijdje gedocumenteerd zodat een verouderd apparaat herkenbaar is in plaats van mysterieus. Een apparaat dat nooit vernieuwt, kondigt zich aan door de gateway niet te bereiken, wat een veel betere aanwijzing is dan een belletje naar support. Als de router leases uitgeeft die langer dan een dag duren, verkort ze dan voor de duur van het venster.

Wat een alias kan en niet kan

Waar de server van jou is, kan het vertalen van adressen op de client het externe prefix binnen een vrij lokaal bereik zichtbaar maken, zodat dezelfde host op een tweede adres antwoordt. Community-OpenVPN doet dat met client-nat, en die richtlijn is specifiek voor die client, afwezig in de commerciële en mobiele clients waarmee men die gewoonlijk vergelijkt. De opzet vereist een route die bij de vertaling past, een vrij bereik voor de alias en een server die bereid is het onvertaalde adres van de client te beantwoorden. Niets daarvan helpt als de client bij een beheerde provider hoort die je niet kunt configureren.

Zodra de wijziging ingaat, bereik je een lokale en een externe host eerst op adres en dan op naam, en noteer je de route die het systeem elke keer kiest. Een naam kan nog steeds in het oude bereik oplossen, dus adressen en namen verdienen onafhankelijke controles. Herstart één client en één apparaat aan de serverkant als een van beide de wijziging heeft doorstaan, want gecachte buuringangen leven langer dan de bewerking.

Schrijf de prefixen waar je op uitkwam daar op waar mensen echt kijken: de netwerknotities, het commentaarveld van de router, de introductiepagina. Iemand kiest weer 192.168.1.0/24, en het conflict komt met hem terug.