Vagrant VM исчезнува кога 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, сте ја вратиле патеката со која почнавте. Кога работи само една од тие, преостанатиот дефект е на територијата на другиот сопственик, а разликата ви кажува која територија е тоа.

Поврзани статии