UDP VPN застанува при мирување: firewall-от го заборави вашиот тек

VPN се поврзува, работи некое време и потоа престанува да пропушта сообраќај додека клиентот сѐ уште покажува сесија. Повторното поврзување го поправа, поради што изгледа како грешка во клиентот. Обично е firewall или NAT уред што исфрлил неактивно UDP мапирање и нема поим дека тунелот сѐ уште постои.

Симптомот е доволно доследен за дијагноза: се појавува по неактивност, а не под оптоварување.

Како изгледа застој при мирување

Измерете го наместо да го опишувате. Запишете колку долго тунелот мирува пред сообраќајот да запре, дали нов излезен пакет го оживува и дали интерфејсот на клиентот сѐ уште ја држи својата адреса. Ако ново барање од клиентот работи, но одговорот на постоечки тек не, мапирањето е осомничено. Ако ништо не работи додека не се поврзете повторно, и состојбата на сесијата во клиентот е изгубена.

Двете се поврзани со мирување и бараат различни поправки.

Запишете ги времињата пред да промените нешто. Извештај дека запира по околу десет минути мирување е проверлив, додека извештај дека паѓа случајно не е. Таа разлика одлучува дали ќе бркате тајмер или промена во рутирањето.

Најдете го уредот што заборавил

Неколку уреди можат да држат состојба за истиот тек: локалниот рутер, преведувачот погоре, границата на облакот и firewall-от на домаќинот. Секој има свој тајмер и победува најкраткиот. Петминутен прекин обично значи дека еден уред е конфигуриран значително под другите.

Не претпоставувајте дека документираната стандардна вредност е тајмаутот на вашата патека. Тоа е стандардна вредност на еден уред.

• Домашен рутер: често минути, понекогаш многу помалку.
• Облачен NAT или балансер на оптоварување: побарајте документираниот тајмаут за мирување специјално за UDP.
• Firewall на домаќинот: тајмерите за следење на netfilter важат по тек.

Проверете ги тајмерите на вистинската патека

Во Linux, тајмерите за следење на netfilter се видливи и прилагодливи: sysctl net.netfilter.nf_conntrack_udp_timeout и net.netfilter.nf_conntrack_udp_timeout_stream. Вториот важи кога сообраќајот е виден во двете насоки, затоа воспоставен тунел може да го надживее обичната проверка.

RFC 4787 го опишува однесувањето на UDP NAT и препорачаните минимуми. Тоа е референцата што треба да се цитира кога стандардната вредност на производителот изгледа невообичаено кратка.

Keepalive и повторно поврзување се различни алатки

Keepalive го одржува мапирањето живо; повторното поврзување ја гради мртвата сесија одново. Тие решаваат различни дефекти и не се заменливи поставки за брзина. Поставката на WireGuard PersistentKeepalive испраќа пакет во фиксен интервал за да ја држи NAT врската отворена. Опцијата на OpenVPN keepalive ја врши истата работа на свој начин. Ниту една не помага ако уредот во средината веќе го заборавил текот и ги исфрла двете насоки.

Многу честите проверки додаваат работа без да ја поправат погрешната граница.

Проверете со ново барање, не со повторно вчитување на страница

Откако ќе промените тајмер или ќе додадете keepalive, повторете го сценариото на мирување точно како претходно. Потоа упатете навистина ново барање од покриената апликација. Веќе вчитано јазиче во прелистувачот може да се прикаже од кешот и нема да ви каже ништо.

Ако застојот продолжи, поместете се еден хоп нанадвор и проверете ја табелата со состојби на тој уред.