Завіслы VPN пасля перазагрузкі роўтара: тры рэчы, якія змяніліся

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

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

Умова першая: змяненне лакальнага адраса

Перазагрузка можа выдаць машыне іншы адрас. Тады VPN, наладжаны з фіксаванай лакальнай канцавой кропкай, працягвае выкарыстоўваць прывязку, якой ужо не існуе. Тое ж датычыцца кліента, які прывязаў свой сокет да старога адраса. Інтэрфейс тунеля можа заставацца ўзнятым, пакуль кожны пакет, які ён стварае, ідзе ў нікуды.

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

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Умова другая: знікненне перакладзенага адлюстравання

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

Менавіта тут тунель без keepalive спыняецца ціха, а не гучна падае. Дакументаваныя абмежаванні WireGuard апісваюць тую ж форму адмовы. Няправільны стан канцавой кропкі дае адкінутыя пакеты, а не дыягностыку.

Пастаянны keepalive на 25 секунд звычайнае памякчэнне, бо ён абнаўляе адлюстраванне раней, чым скончыцца тайм-аўт прастою. Ён не рамантуе адлюстраванне, якое ўжо знікла. Спалучайце keepalive з логікай перападключэння, а не лічыце яго выпраўленнем.

Умова трэцяя: змяненне публічнага адраса

Калі уласны знешні адрас роўтара змяніўся, усё на тым баку, што фільтруе па адрасе крыніцы, цяпер бачыць іншага суразмоўцу. Тунель можа ўзняцца, а сервер можа ўсё яшчэ адкідаць трафік; гэта выглядае як зламаны кліент, а насамрэч гэта палітыка на тым канцы.

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

Аднаўляйце ў правільным парадку

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

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

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