VPN праз UDP замірае ў прастоі: фаервол забыў ваш паток

VPN падключаецца, працуе нейкі час, а потым перастае прапускаць трафік, пакуль кліент усё яшчэ паказвае сеанс. Перападлучэнне выпраўляе гэта, і таму ўсё выглядае як памылка кліента. Звычайна гэта фаервол або прылада NAT, якая скінула прастойнае UDP-супастаўленне і не ведае, што тунель яшчэ існуе.

Сімптом дастаткова паслядоўны для дыягностыкі: ён з'яўляецца пасля бяздзейнасці, а не пад нагрузкай.

Як выглядае прастойная затрымка

Вымерайце яе, а не апісвайце. Запішыце, колькі тунель стаіць без руху да спынення трафіку, ці ажыўляе яго новы зыходны пакет і ці захоўвае інтэрфейс кліента свой адрас. Калі новы запыт ад кліента працуе, а адказ на існуючы паток не, то падазронае — супастаўленне. Калі нічога не працуе, пакуль вы не перападключыцеся, стан сеансу кліента таксама знік.

Абодва выпадкі звязаныя з прастоем, і ім патрэбныя розныя выпраўленні.

Запішыце час перад тым, як нешта змяняць. Справаздача, што спыненне адбываецца прыблізна праз дзесяць прастойных хвілін, правяральная, а справаздача, што яно здараецца выпадкова, — не. Гэтая розніца вырашае, ці ганяцца вам за таймерам, ці за зменай маршрутызацыі.

Знайдзіце прыладу, якая забылася

Некалькі прылад могуць трымаць стан для аднаго патоку: лакальны маршрутызатар, вышэйшы перакладчык, мяжа воблака і фаервол хоста. У кожнай свой таймер, і перамагае самы кароткі. Пяціхвілінны перапынак звычайна азначае, што адна прылада наладжана значна ніжэй за іншыя.

Не думайце, што дакументаванае значэнне па змаўчанні — гэта тайм-аўт на вашым шляху. Гэта значэнне адной прылады.

• Хатні маршрутызатар: часта хвіліны, часам значна менш.
• Воблачны NAT або балансіроўшчык нагрузкі: шукайце дакументаваны прастойны тайм-аўт менавіта для UDP.
• Фаервол хоста: таймеры адсочвання 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 паўтарыце прастойны сцэнар дакладна як раней. Затым зрабіце сапраўды новы запыт з ахопленай праграмы. Укладка браўзера, якая ўжо была загружана, можа адлюстравацца з кэша і нічога вам не скажа.

Калі затрымка не праходзіць, перамясціцеся на адзін хоп вонкі і праверце табліцу станаў той прылады.