VM 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

Коли хост знову досягає госта, а гост досягає локальної мережі, ви відновили шлях, з якого почали. Коли працює лише одне з цього, залишкова несправність на території іншого власника, і різниця каже, яка це територія.

Схожі статті