VPN кажа, што злучаны, але маршрут па змаўчанні мёртвы
Пераход з Wi-Fi на Ethernet можа пакінуць маршрут і рэзалвер на старым тунелі. Чытайце абодва станы асобна, потым выпраўце той, што памылковы.
Кліент паведамляе, што злучаны, значок у латцы выглядае звычайна, а нічога не загружаецца. Гэта пачалося адразу пасля пераходу з Wi-Fi на кабель або адразу пасля завяршэння абнаўлення дыстрыбутыва. Зламаўся не профіль, а стан, пабудаваны для папярэдняга базавага злучэння. У ядры ўсё яшчэ ёсць маршрут па змаўчанні, які паказвае на тунэльную прыладу, якой ніхто не валодае, або рэзалвер усё яшчэ пералічвае серверы на звяне, якое знікла. Абедзве паломкі выглядаюць як мёртвая сетка, і абедзве можна выправіць на месцы.
Састарэлыя часткі былі няправільнымі яшчэ да таго, як вы іх заўважылі. Простае выцягванне кабеля зрабіла іх бачнымі.
Спытайцеся ў ядра, куды пойдзе пакет
Спісы маршрутаў цяжка чытаць, бо яны пералічваюць усё, што ведае сістэма, уключаючы запісы, якія ўжо не дзейнічаюць. Пошук маршруту адказвае на адзінае вартае пытанне: якая прылада нясе гэты пакет прама зараз. Калі адказ называе тунэльную прыладу, ядро будзе выкарыстоўваць яе, нават калі за ёй няма ніводнага жывога працэсу кліента, і пакет трапляе ў інтэрфейс, які ніхто не падтрымлівае. Калі адказ называе адаптар Ethernet, а кліент настойвае, што злучэнне ёсць, тунель існуе, але страціў выбар, — гэта звычайны вынік пераходу з бесправадной сеткі на правадную.
Запусціце пошук двойчы: адзін раз для публічнага адраса, адзін — для ўнутранага, бо палітыка раздзеленага тунелю можа адзін правесці сумленна, а другі скінуць.
ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40
Рэзалвер таксама трымае мёртвае звяно
На хасце з systemd-resolved серверы DNS належаць звянам, а не аднаму глабальнаму спісу. VPN-звяно, якое ўпала, можа яшчэ нейкі час заставацца зарэгістраваным са сваімі серверамі, і тады кожны пошук чакае адрас, які ніколі не адкажа. Гэтая затрымка адчуваецца як мёртвая сетка і прымушае людзей глядзець на маршруты, калі маршрут у парадку.
resolvectl status
resolvectl query intranet.example.com
Чытайце блокі па кожным звяне і вызначце, якое звяно валодае патрэбным даменам. Тунель, які ўзняты, але не валодае ўнутраным даменам, перадае ўнутраныя імёны публічнаму рэзалверу, і сімптом неадрозны ад збою маршрутызацыі.
Выпраўце рэгістрацыю, а не /etc/resolv.conf. У сучасных усталёўках Ubuntu і Fedora гэты шлях — сімвалічная спасылка на стан рэзалвера падчас выканання, таму праўка альбо ігнаруецца, альбо перазапісваецца пры наступнай сеткавай падзеі.
VPN ніколі не запускаецца сам
NetworkManager уздымае VPN паверх базавага злучэння і даведваецца, за якім з іх ісці, з connection.secondaries на той базавай прыладзе. даведнік параметраў злучэння ясна ўказвае, што аўтападключэнне для профіляў VPN не рэалізаванае. Гэта і ёсць увесь механізм за гэтым класам збояў: зменіце базу — і VPN давядзецца спарыць нанова або актываваць уручную.
nmcli device status
nmcli connection show --active
nmcli connection up office-vpn
Калі актыўны спіс паказвае базу без VPN, тунель зусім не актыўны і маршрут ніколі не ўсталёўваўся, а не застаўся састарэлым. Калі актывацыя скардзіцца, што зыходнага злучэння не існуе, база, з якой ён быў спары, знікла, таму спачатку выпраўце базу або спарванне і перастаньце паўтараць спробу з VPN.
Абнаўленне можа скінуць налады без паведамлення
Абнаўленне дыстрыбутыва замяняе кліент і часта яго плагін NetworkManager, а захаваны профіль трымае тыя назвы ўласцівасцяў, з якімі быў запісаны. Усё, што новы плагін больш не распазнае, прапускаецца моўчкі. Профіль усё яшчэ актывуецца, прылада ўсё яшчэ з’яўляецца, але маршрут, які раней прыходзіў разам з ёй, больш не прыходзіць.
Напісаныя ўручную кукі таксама пераязджаюць. Скрыпт, які ўсталёўваў маршрут у прадказальны момант старой паслядоўнасці, цяпер можа выконвацца раней, чым інтэрфейс існуе, або пасля таго, як кліент ужо выйшаў па тайм-ауце.
Параўноўвайце жывы профіль з плагінам, які ў вас сапраўды ёсць, а не з паводзінамі, якія вы памятаеце. Калі ключ знік з дакументацыі, перанясіце працу ў скрыпт дыспетчара або ў падтрыманую замену, а не аднаўляйце старую ўласцівасць.
Тры станы, тры розныя выпраўленні
Вызначце, у якім стане вы знаходзіцеся, перш чым што-небудзь чапаць, бо перазапуск знішчае доказы, і няспраўнасць вернецца пры наступнай змене сеткі.
| What the lookup shows | What it means | Repair |
|---|---|---|
| A default route via a device that exists but is unused | Leftover route from an earlier activation | Remove the stale entry, or bounce the profile that installed it |
| A tunnel device with no client process | The client skipped its cleanup | Fix the disconnect path, then clear the leftover device state |
| No tunnel device and no active profile | Missing base connection or broken pairing | Bring up the base, then pair the VPN with it again |
Скончыце адным пошукам для публічнага адраса, адным для ўнутранага і адным запытам імені. Калі адрасы працуюць, а імя — не, то рэшткавая няспраўнасць — гэта вобласць дамена ў рэзалверы, і табліца маршрутаў тут ніколі не была праблемай.