Віртуальная машына Vagrant знікае пры падключэнні VPN: чый маршрут зламаўся

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

Сачыце за маршрутам, а не за машынай

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

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

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

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Прачытайце табліцу хоста да і пасля

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

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

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

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

Калі дыяпазон NAT госця і ёсць сутыкненне

VirtualBox NAT па змаўчанні выкарыстоўвае 10.0.2.0/24, і тунель, які штурхае той жа дыяпазон, прымушае госця адпраўляць гэты трафік на свой NAT-шлюз замест рэальнага прызначэння. Пакет ніколі не пакідае хост, таму ніякі журнал міжсеткавага экрана на тым баку яго не пакажа. Docker Machine мае той жа клас канфлікту ў плане «толькі хост», і змена гэтага плана можа запатрабаваць перастварэння машыны разам з яе сертыфікатамі.

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

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

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Аднавіце шлях, не змагаючыся з кліентам

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

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

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

Праверце выпраўленне з абодвух бакоў

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

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

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

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