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

Когато хостът отново достига госта и гостът достига LAN, вие възстановихте пътя, с който започнахте. Когато само едно от тези работи, останалата повреда е на територията на другия собственик и разликата ви казва коя територия е това.

Подобни статии