Рэкурсіўная маршрутызацыя: калі тунель захоплівае ўласныя пакеты

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

Спачатку праверце знешні шлях

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

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

Чаму сесія трымаецца імгненне

Рукапацісканне завяршаецца да ўсталёўкі новага маршруту, таму першыя секунды выглядаюць здаровымі. Як толькі кліент дадае маршрут па змаўчанні, наступны знешні пакет ідзе за ім у інтэрфейс, праз які гэты знешні пакет павінен прайсці. Сервер нічога не бачыць, кліент паўтарае адпраўку, і спроба альбо сканчаецца чаканнем, якое мінула, альбо забівае сесію і пачынае спачатку.

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

Знайдзіце ўласніка выключэння для канчатковай кропкі

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

Для IPsec на аснове маршрутаў праверце селектары палітыкі, якія вырашаюць, якія пакеты трапляюць у тунель, і пераканайцеся, што адрас партнёра з іх выключаны. Для WireGuard метка міжсеткавага экрана інтэрфейса і яго правілы палітыкі трымаюць транспартныя пакеты па-за тунелем, таму ўручную дададзены маршрут па змаўчанні можа зламаць гэта ўпарадкаванне. Другі профіль VPN або кіраўніцкі скрыпт, які перапісвае маршрут па змаўчанні, часта бывае вінаватым. Шырокія правілы абыходу, дададзеныя адно за адным, — звычайны вынік, і яны ператвараюць памылку маршрутызацыі ў табліцу, якую ніхто не можа падтрымліваць.

Праверце яшчэ раз пасля змены сеткі

Маршрут да хоста праз шлюз Wi-Fi правільны, пакуль машына не пераедзе ў іншую сетку. Тады той самы сімптом вяртаецца без якіх-небудзь змен у канфігурацыі.

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

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