VPN maakt thuis verbinding maar loopt in een time-out op hotel-Wi-Fi

De laptop maakt verbinding met de thuis-Wi-Fi, de client verbindt binnen drie seconden, en hetzelfde profiel faalt een uur later in het hotel. Daartussen is niets bijgewerkt. Dit met een klant voor je doornemen gaat vooral over weten welke fout bij welke fase hoort, want de nuttige informatie zit in de code die de client afdrukt, niet in het feit dat het mislukte. Werk de vier stappen hieronder in volgorde af en je weet of een naam, een pakket, een poort of een beleid je heeft geweigerd.

Lees de foutcode als een fase, niet als een vonnis

De client bereikt drie afzonderlijke mijlpalen voordat er een tunnel is. Hij lost de servernaam op, hij krijgt een antwoord van iets op het netwerk, en hij onderhandelt een beveiligingsassociatie. Elke mijlpaal heeft zijn eigen foutmelding, en vooral Windows is royaal met verschillende codes zodra je weet bij welke fase ze horen.

Twee van die codes betekenen dat het netwerk onschuldig is. Een 789 betekent dat pakketten stroomden en dat beide uiteinden het oneens waren over crypto, wat een configuratieprobleem is dat je thuis kunt oplossen. Een 868 betekent dat er nooit een pakket naar buiten hoefde, dus het tunnelontwerp is irrelevant tot de naam is opgelost. De code bij de juiste fase indelen bespaart meer tijd dan welke opname dan ook, want het vertelt je welke van de volgende drie stappen je kunt overslaan.

Wees gepast voorzichtig als de client geen Windows is. Clients van derden plakken het meeste hiervan aan elkaar tot "verbinding mislukt", en daarom vertrouwen de volgende twee stappen helemaal niet op de melding.

Controleer de naam voordat je de tunnel de schuld geeft

Hotel- en luchthavennetwerken onderscheppen constant DNS, en een resolver die antwoordt met een portaaladres levert een fout op die er precies uitziet als een dode server. Vergelijk wat de lokale resolver zegt met wat een publieke resolver zegt:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Als de twee antwoorden verschillen, word je gestuurd en is de rest van de diagnose verloren tot dat is opgelost. Vooral een portaaladres neemt de TCP-verbinding graag aan en blijft daarna hangen, en daarom kan het op een firewallblokkade lijken als je met een browser test.

Bevestig nu dat het adres dat je wilt bereiken het adres is dat wordt gebruikt. Sommige clients cachen de vorige resolutie voor de hele levensduur van het profiel, dus een herverbinding na de DNS-wijziging gaat nog naar het oude adres. Sluit de client volledig voordat je opnieuw test, in plaats van in hetzelfde venster op verbreken en verbinden te drukken.

Zoek uit welk buitenste pakket verdwijnt

De tunnel heeft een buitenste stroom die volledig bij het pad tussen jou en de server hoort, en het is die stroom die tussenliggende dozen classificeren en laten vallen. Leg hem vast op de client en vergelijk dan een werkend netwerk met het falende. Op Windows is de ingebouwde opname genoeg voor een eerste blik:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Wat je wilt zien is of je pakketten überhaupt naar buiten gaan, en of er iets terugkomt. Pakketten naar buiten zonder iets terug betekent dat het pad of het verre uiteinde ze laat vallen; als er helemaal niets uitgaat, is de client nooit aan verzenden toegekomen, wat terugwijst naar naamresolutie of naar een lokaal firewallbeleid.

Herhaal dezelfde test op een hotspot van een telefoon. Dit is de enige meest informatieve vergelijking die je hebt, omdat hij elke doos in het hotel uit het pad haalt terwijl de laptop, de client en de inloggegevens identiek blijven. Als de tunnel op de hotspot opkomt, stop dan met naar de server te kijken. Als hij daar ook faalt, heb je een client- of accountprobleem dat het netwerk nooit veroorzaakte.

Wijzig één transport en test opnieuw

Zodra je weet dat de buitenste stroom wordt weggegooid, is de praktische vraag welke stroom het netwerk wel toestaat. De meeste beperkte netwerken staan uitgaand TCP 443 toe omdat ze anders niet kunnen functioneren, dus de luisteraar daarheen verplaatsen is het gebruikelijke antwoord. Op OpenVPN is dat een schakelaar aan de clientkant tot de server wordt gewijzigd:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec-clients hebben een gelijkwaardige knop in hun eigen instellingenpanelen, meestal beschreven als IPsec over TCP of NAT-traversal. Hem wijzigen is ook een diagnose: als de tunnel over TCP opkomt en over UDP sterft, heb je bewezen dat het netwerk UDP filtert, en je hebt ook de instelling gevonden die je bij elk bezoek aan die locatie nodig hebt.

Weerst de verleiding om routerfuncties bij de eerste poging uit te schakelen. Stateful inspection of floodbeveiliging uitzetten op een hotelnetwerk is toch niet beschikbaar voor je, en op je eigen apparatuur ruilt het een echte bescherming voor één laptop. Noteer welke instelling het resultaat veranderde, zet hem dan terug en zoek een transport dat het netwerk al toestaat.

Controleer hetzelfde profiel op het tweede netwerk

Voordat je het ticket sluit, bewijs je dat de wijziging het verlaten van het gebouw heeft overleefd. Verbind opnieuw op het oorspronkelijke netwerk met de oorspronkelijke instellingen, leg de eerste dertig seconden vast, en bevestig dat de client dezelfde toestand bereikt als op de hotspot:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Het onderscheid dat de laatste opdracht blootlegt, is de moeite waard om te bewaren: het profiel kan een verbonden tunnel melden terwijl de routering erin verkeerd is, en dat levert "de VPN staat aan maar niets werkt", wat een ander artikel is. Als het tunneltype na je bewerking is veranderd, is het profiel niet het profiel dat je hebt getest.

Schrijf de bevinding dan op waar de volgende persoon kijkt. "Het bedrijfsprofiel heeft op deze locatie TCP 443 nodig; UDP 500 wordt door het hotel gefilterd" is een zin waar een collega op kan handelen. "VPN is wispelturig in hotels" is dat niet, en het garandeert dat hetzelfde uur volgende maand opnieuw wordt besteed.