Humihinto ang VPN sa UDP kapag walang aktibidad: nakalimutan ng firewall ang iyong flow

Kumokonekta ang VPN, gumagana nang ilang sandali, at pagkatapos ay tumitigil sa pagpapadala ng trapiko habang nagpapakita pa rin ng sesyon ang kliyente. Naaayos ito sa muling pagkonekta, kaya mukhang bug ito ng kliyente. Karaniwang firewall o aparatong NAT ito na nagtapon ng walang aktibidad na UDP mapping at walang ideya na umiiral pa ang tunnel.

Sapat na pare-pareho ang sintomas para masuri: lumilitaw ito pagkatapos ng kawalan ng aktibidad, hindi sa ilalim ng karga.

Hitsura ng paghinto dahil sa kawalan ng aktibidad

Sukatin ito sa halip na ilarawan. Itala kung gaano katagal nananatiling walang aktibidad ang tunnel bago tumigil ang trapiko, kung binubuhay itong muli ng bagong papalabas na packet, at kung hawak pa rin ng interface ng kliyente ang address nito. Kung gumagana ang bagong hiling mula sa kliyente pero hindi gumagana ang tugon sa umiiral na flow, ang mapping ang pinaghihinalaan. Kung wala nang gumagana hanggang sa muling kumonekta ka, nawala rin ang estado ng sesyon ng kliyente.

Parehong may kaugnayan sa kawalan ng aktibidad, at kailangan nila ng magkaibang lunas.

Isulat ang mga oras bago ka magbago ng kahit ano. Ang ulat na humihinto ito pagkatapos ng mga sampung minutong walang aktibidad ay masusubok, samantalang ang ulat na basta na lang ito bumabagsak ay hindi. Ang pagkakaibang iyon ang magpapasya kung hinahabol mo ang isang timer o isang pagbabago sa routing.

Hanapin ang aparatong nakalimot

Maaaring magtabi ng estado ang ilang aparato para sa parehong flow: ang lokal na router, isang tagasalin sa itaas, isang hangganan ng cloud, at ang firewall ng host. Bawat isa ay may sariling timer, at ang pinakamaikli ang nananalo. Ang limang minutong pagkawala ay karaniwang nangangahulugang isang aparato ang naka-configure nang mas mababa kaysa sa iba.

Huwag ipagpalagay na ang nakadokumentong default ang time limit sa iyong landas. Default iyon ng isang aparato.

• Router sa bahay: madalas minuto, kung minsan ay mas kaunti pa.
• Cloud NAT o load balancer: hanapin ang nakadokumentong idle timeout partikular para sa UDP.
• Firewall ng host: nalalapat ang mga netfilter tracking timer sa bawat flow.

Suriin ang mga timer sa aktwal na landas

Sa Linux, nakikita at naaayos ang mga netfilter tracking timer: sysctl net.netfilter.nf_conntrack_udp_timeout at net.netfilter.nf_conntrack_udp_timeout_stream. Nalalapat ang pangalawa kapag may nakitang trapiko sa dalawang direksyon, kaya maaaring mabuhay nang mas matagal ang isang naitatag na tunnel kaysa sa simpleng pagsusuri.

RFC 4787 ang nagtatakda ng pag-uugali ng UDP NAT at ng mga inirerekomendang minimum. Iyon ang sangguniang dapat sipiin kapag ang default ng isang vendor ay mukhang hindi pangkaraniwang maikli.

Ang Keepalive at muling pagkonekta ay magkaibang kasangkapan

Pinapanatiling buhay ng keepalive ang isang mapping; itinatayo muli ng muling pagkonekta ang isang patay na sesyon. Niresolba nila ang magkaibang pagkabigo at hindi sila mapagpapalit na setting ng bilis. Ang opsyon PersistentKeepalive ng WireGuard ay nagpapadala ng packet sa takdang pagitan para manatiling bukas ang NAT binding. Ang opsyon keepalive ng OpenVPN ay gumagawa ng parehong trabaho sa sarili nitong paraan. Wala sa kanila ang makakatulong kung nakalimutan na ng aparato sa gitna ang flow at itinatapon ang dalawang direksyon.

Ang sobrang dalas na pagsusuri ay nagdaragdag ng trabaho nang hindi inaayos ang maling hangganan.

I-verify gamit ang bagong hiling, hindi sa pag-reload ng pahina

Pagkatapos mong baguhin ang isang timer o magdagdag ng keepalive, ulitin ang senaryo ng kawalan ng aktibidad nang eksakto tulad ng dati. Pagkatapos ay gumawa ng tunay na bagong hiling mula sa saklaw na aplikasyon. Ang tab ng browser na na-load na ay maaaring ma-render mula sa cache at wala itong sasabihin sa iyo.

Kung nagpapatuloy ang paghinto, lumipat ng isang hop palabas at suriin ang talahanayan ng estado ng aparatong iyon.