UDP-VPN staak wanneer dit ledig is: die brandmuur het jou vloei vergeet

Die VPN verbind, werk ’n ruk lank en hou dan op om verkeer deur te laat terwyl die kliënt steeds ’n sessie wys. Herverbinding maak dit reg, wat dit soos ’n kliëntfout laat lyk. Dit is gewoonlik ’n brandmuur of NAT-toestel wat ’n ledige UDP-kaart laat val het en geen idee het dat die tonnel nog bestaan nie.

Die simptoom is konsekwent genoeg om te diagnoseer: dit verskyn ná onaktiwiteit, nie onder las nie.

Hoe ’n ledige staking lyk

Meet dit eerder as om dit te beskryf. Let op hoe lank die tonnel ledig sit voordat verkeer stop, of ’n nuwe uitgaande pakkie dit herleef, en of die kliëntkoppelvlak steeds sy adres hou. As ’n vars versoek van die kliënt werk maar ’n antwoord op ’n bestaande vloei nie, is die kaart die verdagte. As niks werk totdat jy herverbind nie, is die kliënt se sessietoestand ook weg.

Albei hou verband met ledigheid, en hulle het verskillende oplossings nodig.

Skryf die tye neer voordat jy enigiets verander. ’n Verslag dat dit ná ongeveer tien ledige minute stop, is toetsbaar, terwyl ’n verslag dat dit lukraak val nie is nie. Daardie verskil bepaal of jy ’n tydhouer of ’n roeteverandering jaag.

Vind die toestel wat vergeet het

Verskeie toestelle kan toestand vir dieselfde vloei hou: die plaaslike router, ’n opstroom-omsetter, ’n wolkgrens en die gasheer se brandmuur. Elkeen het sy eie tydhouer, en die kortste een wen. ’n Onderbreking van vyf minute beteken gewoonlik dat een toestel ver onder die ander opgestel is.

Moenie aanvaar dat ’n gedokumenteerde verstek die tydlimiet op jou pad is nie. Dit is een toestel se verstek.

• Tuisrouter: dikwels minute, soms baie minder.
• Wolk-NAT of lasbalanseerder: soek die gedokumenteerde ledige tydlimiet spesifiek vir UDP op.
• Gasheer se brandmuur: netfilter se naspeur-tydhouers geld per vloei.

Kontroleer die tydhouers op die werklike pad

Op Linux is die netfilter se naspeur-tydhouers sigbaar en verstelbaar: sysctl net.netfilter.nf_conntrack_udp_timeout en net.netfilter.nf_conntrack_udp_timeout_stream. Die tweede geld sodra verkeer in albei rigtings gesien is, wat die rede is waarom ’n gevestigde tonnel ’n kaal toets kan oorleef.

RFC 4787 beskryf UDP-NAT-gedrag en aanbevole minimums. Dit is die verwysing om aan te haal wanneer ’n verskaffer se verstek ongewoon kort lyk.

Keepalive en herverbinding is twee verskillende gereedskap

’n Keepalive hou ’n kaart lewendig; ’n herverbinding bou ’n dooie sessie weer op. Hulle los verskillende foute op en is nie omruilbare spoedinstellings nie. WireGuard se PersistentKeepalive stuur ’n pakkie met ’n vaste interval om die NAT-binding oop te hou. OpenVPN se keepalive opsie doen dieselfde werk op sy eie manier. Nie een help as die toestel in die middel die vloei al vergeet het en albei rigtings laat val nie.

Buitengewoon gereelde toetse voeg werk by sonder om die verkeerde grens reg te maak.

Verifieer met ’n nuwe versoek, nie ’n bladsyherlaai nie

Nadat jy ’n tydhouer verander of ’n keepalive bygevoeg het, herhaal die ledige scenario presies soos voorheen. Maak dan ’n werklik nuwe versoek vanaf die gedekte toepassing. ’n Blaaier-oortjie wat al gelaai was, kan uit die kas teken en sê vir jou niks.

As die staking voortduur, beweeg een hop uitwaarts en kontroleer daardie toestel se toestandtabel.