Waarom een VPN verbonden kan lijken terwijl niets werkt

Je client meldt verbonden terwijl de interface omhoog staat en de browser een time-out krijgt, en geen van die drie uitspraken is onwaar. Verbonden beschrijft een laag die niets te maken heeft met de pagina die je hebt opgevraagd. Bepalen welke laag meldt, vereist één nieuw verzoek en één blik op de teller die zou bewijzen dat verkeer is verplaatst. Een herstart gooit dat bewijs weg en bouwt de omstandigheden opnieuw op die je probeerde te observeren.

Drie verschillende dingen die verbonden heten

Onderaan kan verbonden betekenen dat een clientproces draait en een socket naar een peer vasthoudt. Daarboven kan het betekenen dat er een interface met een adres bestaat, die een permanent apparaat of een herstelroutine kan aanmaken zonder levende sessie erachter. Op besturingsniveau kan het betekenen dat er een associatie is onderhandeld, wat niets zegt over of er één pakket onderdoor is gegaan. Elk daarvan overleeft fouten die de andere niet overleven, en een client toont meestal de sterkste die hij kan claimen.

Een groen pictogram en een dode tunnel zijn dus verenigbaar en niet tegenstrijdig; ze rapporteren over verschillende objecten. Dat is de hele reden waarom deze storing steeds verkeerd wordt gediagnosticeerd als een clientbug.

Stuur één onschadelijk verzoek naar een bestemming die je echt nodig hebt voordat je de daemon aanraakt, en houd het vereiste blok voor direct verkeer op zijn plaats terwijl je werkt. Een herstart wist de volgorde van gebeurtenissen en maakt ze daarna dicht genoeg opnieuw aan om de oorzaak te verbergen, waardoor hetzelfde ticket een week later terugkomt zonder iets nieuws erin. Eén verzoek, één telleruitlezing en de trigger die de storing veroorzaakte zijn het minimum aan bewijs.

Welke teller bewijst dat de pakketten zijn verplaatst

In IPsec zijn de IKE-associatie en de CHILD-associatie aparte objecten, en alleen de child draagt de tellers die deze vraag beantwoorden. Toon de child, kijk of pakketten in beide richtingen toenemen, en vergelijk dat met wat de toepassing probeert te doen. Een geïnstalleerde associatie op nul is een andere bevinding dan een die toeneemt terwijl de toepassing nog steeds faalt; het eerste betekent dat verkeer niet wordt geselecteerd, het tweede dat het beweegt en de fout verderop zit. Lees de tellers twee keer, een paar seconden uit elkaar, omdat één meting geen trend kan tonen.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Nultellers wijzen op de selectie: routing, beleid, een naamruimte waar het pakket uit kwam, of een interface waaraan de client zich nooit heeft gebonden. Groeiende tellers wijzen weg van de tunnel, dus ga verder met doorsturen aan de verre kant, naamresolutie, de retourroute en de doeldienst, in die volgorde. Een protocol zonder apart child-object legt hetzelfde bewijs in zijn eigen termen bloot, dus gebruik wat het meldt over peertoestand en pakketaantallen in plaats van het IPsec-vocabulaire te lenen. De vorm van de uitlezing is belangrijker dan het gereedschap dat hem produceerde.

Waar de fout zit nadat de tellers bewegen

Een gateway die op zijn eigen beheeradres antwoordt, bewijst dat de gateway draait, niet dat iets erachter je verzoek bedient, dus test de verre kant en niet de doos in het midden. Naamresolutie verbergt fouten het best, omdat een resolver die niet via de tunnel bereikbaar is, precies zo'n time-out geeft als een dode verbinding. Twee opzoekingen scheiden die gevallen, en beide zijn goedkoop. Vraag eerst de resolver die de tunnel opdringt, en vraag daarna een publieke resolver naar dezelfde naam.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Een naam die via de publieke resolver wordt opgelost maar niet via de tunnelresolver, betekent dat het DNS-pad gebroken is, terwijl een naam die via beide wordt opgelost en in de browser nog steeds een time-out geeft, op de retourroute of op de dienst wijst. Als de ping op adres slaagt en de toepassing weigert nog steeds, heeft het netwerk het verzoek afgeleverd en heeft de dienst het geweigerd, wat een veel later stadium is.

Noteer de trigger en verander dan één ding

Noteer wat aan de storing voorafging: een periode van inactiviteit, een netwerkwijziging, een sleutelvernieuwing, een hervatte laptop of een hersteld systeem. Die geven verschillende mechanismen, en meestal herstelt alleen het herstelde systeem zichzelf, wat precies het geval is dat je niets leert. Een herstart verwijdert de volgorde van gebeurtenissen en maakt daarna omstandigheden aan die dicht genoeg liggen om de oorzaak te verbergen. Schrijf de trigger op terwijl die nog reproduceerbaar is.

Doe dan één onderbouwde correctie en herhaal het oorspronkelijke verzoek samen met de trigger die de storing veroorzaakte. Inactiviteit is de gemakkelijkst te reproduceren trigger, dus is het de snelste bevestiging dat de correctie het mechanisme en niet het symptoom aanpakte.

Wat je wilt melden is bewijs dat het verkeer dat je wilde sturen de dienst heeft bereikt die je wilde bereiken. Een pictogram dat groen wordt, een gecachte pagina die laadt en een teller die beweegt bewijzen allemaal minder dan één voltooid verzoek naar de bedoelde bestemming. Houd het verzoek, de telleruitlezing en de trigger bij elkaar, zodat de volgende persoon een correctie van een toeval kan onderscheiden.