De VPN is verhuisd: waarom je OpenVPN-client nog steeds het oude IP kiest

De provider heeft je publieke adres gewijzigd, je hebt de dynamische DNS-record bijgewerkt, en de client kan nog steeds geen verbinding maken. Van buitenaf lijkt het of de record niet is doorgekomen. Meestal is de record in orde en kiest de client het adres dat hij vóór de verhuizing had opgelost, omdat een lopende tunnel en een opgeslagen profiel elk hun eigen idee hebben over waar de server woont. Drie lagen moeten overeenkomen, en ze worden volgens verschillende schema's bijgewerkt.

Kijk naar wat het profiel kiest, niet naar wat DNS zegt

Open de verbinding die je echt gebruikt en lees de remote-regel. Een numeriek adres daar volgt nooit een update van de hostnaam, hoe correct de record ook wordt.

Controleer daarna of het profiel dat je hebt bewerkt hetzelfde is als wat de client heeft geladen. Geïmporteerde profielen komen vaak voor: een beheerder heeft misschien maanden geleden een kopie genomen en zijn eigen versie gehouden, dus het bestand in je downloadmap en de vermelding in de app kunnen verschillen. Vergelijk het eindpunt in de verbindingsgegevens van de client zelf voordat je überhaupt DNS gaat debuggen.

Twee bestanden, één eindpunt — dat is hier de gebruikelijke vondst.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Lees de volgende verbindingspoging van de client

Herstart de verbinding met uitgebreide logging en lees de regel waarin het adres staat dat hij zal contacteren. Die waarde telt, niet wat je browser heeft opgelost.

Een resolvecache kan het vorige antwoord nog bevatten, en sommige netwerken bewaren het langer dan de TTL van de record vraagt. Vraag het aan de resolver die de client echt gebruikt, niet aan een publieke die je elders hebt getest.

Als de log het nieuwe adres toont en de verbinding nog steeds mislukt, is het probleem verschoven: het pakket gaat ergens heen en niemand antwoordt. Dat is een kwestie van luisteraar, firewall of portforwarding, en die ligt aan de serverkant in plaats van in het resolutiepad van de client. Houd die twee storingen apart, want een onbereikbare luisteraar als DNS-probleem behandelen stuurt je twee keer door dezelfde lus.

Weet welke herstart je doet

Niet alle herstarts behouden dezelfde toestand, daarom kan een adreswijziging zich anders gedragen afhankelijk van hoe het proces wordt gerecycled. Een zachte herstart door een signaal behoudt meer context van de vorige sessie, terwijl een volledige stop en start opnieuw bij de configuratie begint. Als je test of de client opnieuw oplost, wil je het pad dat bij de configuratie begint.

Persistentie-instellingen zijn ook belangrijk, omdat ze bedoeld zijn om te behouden wat is geauthenticeerd, niet om nieuwe adressen na te jagen.

De schoonste test is een verse start vanuit het bedoelde profiel, gevolgd door een blik op de logregel die het eindpunt noemt. Alles wat je leert van een gedeeltelijk bewaarde sessie is een uitspraak over die sessie.

De vier opties en hun aparte taken

remote met een hostnaam is de instelling die opnieuw oplossen überhaupt mogelijk maakt; een letterlijk adres op die regel sluit het uit. resolv-retry bepaalt wat er gebeurt als een opzoeking mislukt, en 2.6 zet die al standaard op oneindig. Toevoegen verandert dus niets, en het plant nooit een periodieke controle op een ander antwoord. Wie zegt dat het nieuwe adressen pollt, heeft herstel met frisheid verward.

persist-remote-ip gaat over continuïteit in plaats van frisheid: het hergebruikt het eindpunt dat als laatste authenticeerde, over de zachte herstarts die het ondersteunt. Terwijl je een verhuizing test, is dat het tegenovergestelde van wat je wilt. Schakel het uit voor de test als je build het inschakelt, en herstel het zodra het nieuwe eindpunt bewezen is. Blijft het aan, dan kan een geslaagde herverbinding je niets over DNS vertellen.

float accepteert een geauthenticeerde peer waarvan het adres midden in de sessie veranderde, en alleen in opstellingen die dat ondersteunen. Het ververst DNS niet en volgt een providerwijziging niet vanzelf. Behandel het als een weerbaarheidsfunctie voor peers die roamen, niet als een mechanisme voor dynamische adressen voor servers.

Bevestig het nieuwe eindpunt voordat je de client de schuld geeft

Controleer van buiten je netwerk of het nieuwe adres een luisteraar op de geconfigureerde poort heeft en of de forwarding van de provider daarheen wijst. Een correcte A-record voor een machine zonder open poort levert precies het symptoom op dat mensen aan caching toeschrijven.

Maak daarna opnieuw verbinding en verifieer twee dingen: de client heeft geauthenticeerd tegen het verwachte servercertificaat, en de sessie bereikt de resource die je bedoelde. Een adreswijziging verlaagt de identiteitseisen niet, en een verbinding die slaagt naar het verkeerde eindpunt is erger dan een die mislukt. De OpenVPN 2.6-handleiding vermeldt alle vier opties met hun eigen bereik, en dat is de checklist die naast het profiel hoort.

Houd een weg buiten het kanaal naar de server achter de hand voordat je de tunnel herstart die je beheerderstoegang draagt. Die ene voorzorg voorkomt de meeste incidenten die dit scenario oplevert.