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 мрежа го опишува софтверскиот интерфејс на страната на домаќинот и како се разликува од поврзување со мост, што е референцата што вреди да се прочита пред да се претпостави дека двата режима се заменливи.