UDP-VPN stokt bij inactiviteit: de firewall vergat je flow

De VPN verbindt, werkt een tijdje en stopt dan met het doorlaten van verkeer terwijl de client nog een sessie toont. Opnieuw verbinden lost het op, waardoor het op een clientbug lijkt. Meestal is het een firewall of NAT-apparaat dat een inactieve UDP-mapping heeft laten vallen en geen idee heeft dat de tunnel nog bestaat.

Het symptoom is consistent genoeg om te diagnosticeren: het verschijnt na inactiviteit, niet onder belasting.

Hoe een stilstand bij inactiviteit eruitziet

Meet het in plaats van het te beschrijven. Noteer hoe lang de tunnel stil ligt voordat het verkeer stopt, of een nieuw uitgaand pakket hem weer tot leven wekt en of de clientinterface nog steeds zijn adres vasthoudt. Als een nieuw verzoek van de client werkt maar een antwoord op een bestaande flow niet, is de mapping de verdachte. Als niets werkt tot je opnieuw verbindt, is de sessietoestand van de client ook weg.

Beide hangen samen met inactiviteit, en ze vragen om verschillende oplossingen.

Schrijf de tijden op voordat je iets verandert. Een melding dat het na ongeveer tien inactieve minuten stopt is testbaar, terwijl een melding dat het willekeurig wegvalt dat niet is. Dat verschil bepaalt of je een timer of een routingwijziging najaagt.

Vind het apparaat dat het vergat

Meerdere apparaten kunnen toestand bijhouden voor dezelfde flow: de lokale router, een vertaler verderop, een cloudgrens en de firewall van de host. Elk heeft zijn eigen timer, en de kortste wint. Een onderbreking van vijf minuten betekent meestal dat één apparaat veel lager is ingesteld dan de andere.

Ga er niet van uit dat een gedocumenteerde standaardwaarde de timeout op jouw pad is. Het is de standaardwaarde van één apparaat.

• Thuisrouter: vaak minuten, soms veel minder.
• Cloud-NAT of loadbalancer: zoek de gedocumenteerde inactieve timeout specifiek voor UDP op.
• Firewall van de host: netfilter-trackingtimers gelden per flow.

Controleer de timers op het werkelijke pad

Op Linux zijn de netfilter-trackingtimers zichtbaar en aanpasbaar: sysctl net.netfilter.nf_conntrack_udp_timeout en net.netfilter.nf_conntrack_udp_timeout_stream. De tweede geldt zodra er verkeer in beide richtingen is gezien, waardoor een gevestigde tunnel een kale probe kan overleven.

RFC 4787 beschrijft het gedrag van UDP-NAT en de aanbevolen minimumwaarden. Dat is de referentie die je aanhaalt wanneer een leveranciersstandaard ongewoon kort lijkt.

Keepalive en opnieuw verbinden zijn verschillende gereedschappen

Een keepalive houdt een mapping in leven; opnieuw verbinden bouwt een dode sessie opnieuw op. Ze lossen verschillende storingen op en zijn geen uitwisselbare snelheidsinstellingen. De optie PersistentKeepalive van WireGuard stuurt een pakket met een vast interval om de NAT-binding open te houden. De optie keepalive van OpenVPN doet hetzelfde werk op zijn eigen manier. Geen van beide helpt als het apparaat in het midden de flow al is vergeten en beide richtingen laat vallen.

Zeer frequente probes voegen werk toe zonder de verkeerde grens te repareren.

Verifieer met een nieuw verzoek, niet met een paginaverversing

Herhaal na het wijzigen van een timer of het toevoegen van een keepalive het inactiviteitsscenario precies zoals eerst. Doe daarna een echt nieuw verzoek vanuit de gedekte applicatie. Een browsertab die al was geladen, kan uit de cache worden weergegeven en vertelt je niets.

Als de stilstand aanhoudt, ga een hop naar buiten en controleer de toestandstabel van dat apparaat.