Welke NAT-hop laat de inactieve VPN-mapping vallen, en hoe je dat ziet
Een inactieve VPN-stroom kan bij elke stateful hop sterven. Herhaal één test, vergelijk wat elke grens zag, en rapporteer het begrensde resultaat in plaats van een geraden schuldige.
Na een rustige periode verbindt de tunnel opnieuw, geen enkel logboek noemt een schuldige, en de voor de hand liggende stap is het apparaat kiezen met de indrukwekkendste time-outdocumentatie. Dat is een gok in het gewaad van een diagnose. Toestand kan een tijdje overleven in een thuisrouter, in een vertaler van de provider en aan een cloudrand, en elk daarvan kan een stroom laten vallen die stil wordt. Wat je in plaats daarvan kunt doen, is het pad in kaart brengen, markeren welke apparaten je echt kunt observeren, en één inactieve test uitvoeren die je kunt herhalen.
Een herhaalbare test verandert een anekdote in een meting. Alles hieronder veronderstelt één client, één server en één protocol, en het veronderstelt dat je weerstand biedt aan het tegelijk wijzigen van twee variabelen. Het doel is de volgende gebeurtenis goedkoper te maken dan deze.
Voer elke keer dezelfde inactieve test uit
Schrijf op wanneer de stroom voor het laatst in orde was, hoe lang die daarna inactief bleef, en of één vers pakket hem terugbracht. Die drie feiten zijn de meting; zonder hen heb je een verhaal over een laptop die uitviel. Gebruik bij elke herhaling dezelfde client, dezelfde server en hetzelfde protocol, en noteer het moment waarop het eerste pakket na de stilte werd verzonden.
Vergelijk daarna wat elke grens die je bezit werkelijk zag. Het onderscheid dat het onderzoek beslist, is of de server na de pauze helemaal niets zag, of het verzoek zag en antwoordde in een pad dat de antwoorden niet meer droeg.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
Paden vergelijken zonder vijf dingen te wijzigen
Een tweede goedgekeurd toegangsnetwerk is een legitieme vergelijking, omdat de NAT-keten verschilt. Het verschilt ook in provider, radio-omstandigheden en mogelijk adresfamilie, dus het resultaat is een grens en geen toeschrijving. Noteer de beperkingen samen met het resultaat in plaats van ze stilzwijgend weg te laten bij het rapporteren. Schrijf het pad er meteen bij: apparaat, rol, en of de toestand ervan helemaal leesbaar is.
Wat een vergelijking van paden je oplevert, is een beperkte vraag: de stroom overleeft op de ene en sterft op de andere na een vergelijkbare stilte, dus de variabele zit ergens in de delen die verschillen. Dat is een echt resultaat, zelfs als er geen apparaat wordt genoemd, en het vertelt de volgende engineer waar een middag aan besteed moet worden en waar niet.
Lokale toestand is het lezen waard voordat je over providers speculeert. Op een Linux-gateway somt conntrack -L de gevolgde stromen op met hun resterende levensduur, wat een gok over een timer verandert in een getal dat je kunt zien verlopen. Lees het voor en na de inactieve periode, niet alleen erna.
Wat een keepalive wel en niet vasthoudt
Een ondersteunde keepalive houdt een mapping open, en een open mapping bewijst niets over de dienst erachter. De tunnel kan gemapt blijven terwijl de applicatie die hij draagt is gestopt met antwoorden, en vanaf een statuslampje zien die twee situaties er hetzelfde uit. Behandel een keepalive als verzekering tegen inactieve afloop, niet als gezondheidscontrole.
Stel het interval in op de kortste time-out die je werkelijk hebt gemeten, niet op een getal dat van een forum is gekopieerd. Een keepalive die onder elke denkbare timer is afgesteld, is verkeer dat niemand nodig had, en het haalt ook het symptoom weg dat je zou hebben verteld welke grens het eerst afloopt. Kies het interval uit het gemeten getal en laat al het andere met rust.
Eén wijziging, meet daarna opnieuw
Weersta de neiging om tijdens een live test elke time-out te verhogen en elke gateway te flushen. Dat wist het bewijs waarvoor je kwam en onderbreekt stromen van anderen, wat een slechte ruil is voor een hypothese die je niet hebt getest. Wijzig één ondersteunde instelling op één apparaat, en herhaal dan de inactieve periode en het herstel van de applicatie.
Noteer welke grensobservatie verschoof, en noteer het ook als niets verbeterde. Een instelling die niets oploste is informatie, en het is goedkoper om dat één keer op te merken dan om het over het hele domein uit te rollen.
Een bevinding schrijven die je kunt verdedigen
Wanneer een vertaler verderop niet kan worden geïnspecteerd, zeg dan alleen wat het bewijs ondersteunt: de uitwisseling sterft ergens langs dit stuk van het pad na zoveel stilte, en de verantwoordelijke hop blijft onbenoemd. Een begrensde uitspraak doorstaat de beoordeling en wijst de volgende persoon op het juiste segment. Een verborgen router als oorzaak noemen doet geen van beide. Geef de begrensde bevinding aan wie het niet-observeerbare segment bezit, met het interval bijgevoegd.
RFC 4787 beschrijft waarom UDP-mapping-timers moeilijk uit één eindpunt af te leiden zijn, en juist die moeilijkheid maakt de begrensde bevinding de eerlijke. Timers zijn echt, en de onzekerheid eromheen ook.