VPN е включен, а VM е недостъпна? Маршрутът вероятно никога не е бил проблемът

Свържете VPN и разработващата VM, която отговаряше преди минута, замлъква. Очевидната история се пише сама: тунелът грабна маршрута, хостът вече изпраща гост-трафика в корпоративната мрежа, а решението е да добавите статичен маршрут или да превключите адаптера в режим на мост. Тази история понякога е вярна. Но това не е обичайната причина и действията по нея първо обикновено чупят нещо друго.

Мрежата host-only е софтуерна мрежа, притежавана от хоста и споделяна с неговите гости, отделна от всяко физическо свързване. Нищо в собствения интерфейс на VPN клиента не променя тази мрежа, затова преди да я пипате, разберете кой от четирите слоя всъщност се е провалил.

Маршрутът обикновено все още е локален

Питайте ядрото, а не първата страница на маршрутната таблица. В Linux ip route get 192.168.56.10 показва точния маршрут, интерфейс и адрес на източника, които ще бъдат използвани, което е различен отговор от четенето на маршрут по подразбиране и гадаене. Ако изходът посочва host-only интерфейса, тунелът изобщо не участва в този път.

Две неща наистина могат да го счупят и двете са проблеми с адреси, а не с VPN. Отдалечена подмрежа, която се застъпва с host-only префикса, прави по-конкретния маршрут победител, а VPN клиент, който инсталира широк маршрут с по-ниска метрика, може да отнеме префикса. И двете се виждат в една и съща команда: интерфейсът, посочен в изхода, ще бъде тунелът, а поправката принадлежи на този, който притежава този план на адресите.

Изборът на маршрут и допускането на пакети са различни решения

Това е частта, която мисловният модел обикновено пропуска. Дори с перфектен локален маршрут VPN клиентът може да откаже пакета. Много клиенти налагат политика за локален мрежов достъп, която решава кои дестинации са разрешени извън тунела, а свързана подмрежа не обновява този списък автоматично.

Затова отказът изглежда идентичен на маршрутен проблем от страната на приложението и напълно различен от страната на клиента. Ако ip route get посочва правилния интерфейс, а връзката все още изтича, спрете да редактирате маршрути и вместо това прочетете документираното поведение за локален достъп на клиента. Някои клиенти предоставят списък за разрешение за локални подмрежи, други блокират всичко, което не е тунелът, а трети блокират само когато е включен kill switch.

Това разграничение е важно, защото поправките не са взаимозаменяеми. Добавянето на маршрут не може да задоволи филтър, а изключването на филтър, за да стигнете до един гост, е много по-голямо решение, отколкото подсказва симптомът.

Гостът има три начина да каже не

Гост, който може да сърфира в интернет, не е доказал нищо за услугата, която искате. Слушателят може да е вързан към 127.0.0.1 вътре в госта и тогава никаква заявка от хоста не може да пристигне, колкото и добър да е пътят. Проверете с ss -ltn в госта и погледнете колоната с локалния адрес, а не само порта.

Следваща е собствената защитна стена на госта. Образ за разработка със стриктен режим по подразбиране може да приеме пакетите на хоста и да ги изхвърли на границата на услугата, което създава таймаут, изглеждащ точно като маршрутна черна дупка. Накрая е собствената конфигурация на услугата: уеб приложение, вързано към конкретно име на хост, или списък за разрешение с адреси на клиенти ще откаже заявка от host-only подмрежата дори когато всеки пакет пристига.

Минете през тези три неща, преди да обмислите смяна на мрежовия режим на VM. Всяко е по-малка промяна от препроектиране на свързването на госта и всяко има ясен тест.

Какво наистина представлява мостът и какво струва

Превключването на адаптера в режим на мост не е поправка на host-only пътя. Това е решение да поставите госта в друга мрежа, обикновено физическата LAN, където той става видим за всичко останало там. Това може да е точно това, което искате. Но не е това, което е правела първоначалната конфигурация.

Използвайте го, когато гостът наистина трябва да е равен възел в тази LAN и излагането е одобрено. Не го използвайте, защото една услуга е спряла да отговаря, тъй като промяната може да извади госта от изолацията, която го правеше безопасен за разработка.

След всяка одобрена корекция тествайте в фиксиран ред: нова заявка от хост към гост, необходим корпоративен ресурс през тунела и желаното отказано поведение с изключен тунел. Ако последното вече не е вярно, корекцията е отишла отвъд проблема.

Разделът на VirtualBox за host-only мрежа описва софтуерния интерфейс от страната на хоста и как се различава от свързване чрез мост; това е справката, която си струва да прочетете, преди да приемете, че двата режима са взаимозаменяеми.