Дали вашата VM го користи VPN-от на хостот? Тестирајте од внатрешноста на гостинот

Ја проверувате јавната IP-адреса на хостот, таа го покажува VPN-от и заклучувате дека VM-от е покриен. Тој заклучок не е поддржан од тестот. Гостинот има своја сопствена табела за маршрутирање, свој резолвер и свои интерфејси, а излезната адреса на хостот не кажува ништо за нив.

Тестот мора да се изврши внатре во гостинот и мора да именува што измерил.

Започнете од внатрешноста на гостинот, а не од прелистувачот на хостот

Прво запишете го мрежниот режим на хипервизорот: NAT, bridged, host-only или macvtap. Во NAT режим хостот го маршрутира сообраќајот на гостинот, па тунелот на хостот може или не може да важи, зависно од тоа како клиентот ги поставува маршрутите. Во bridged режим гостинот е рамноправен учесник на физичката LAN и тунелот на хостот е неважен. Овие два режима даваат спротивни одговори од истата конфигурација на хостот.

Запишете го режимот пред да промените нешто, бидејќи токму тој одредува што може да значи резултатот.

Направете едно барање чија дестинација ја знаете

Употребете безопасно барање до услуга што ја пријавува изворната адреса што ја видел. Потоа проверете ја сопствената одлука за маршрутирање на гостинот за таа дестинација: ip route get 203.0.113.5 ја печати интерфејсот и портата што гостинот ќе ги користи.

Ако интерфејсот е нормалниот NIC на гостинот, сообраќајот не оди низ тунел внатре во гостинот.

Втор адаптер, поставка за прокси или VPN клиент на страната на гостинот може да го промени одговорот за една апликација, но не и за друга. Тестирајте ја апликацијата што навистина ви е важна, а не општо барање од shell.

Проверете го резолверот одделно

Променетата излезна адреса не ви кажува кој резолвер го обработил името на хостот. Прашајте го името експлицитно со алатката што одговара на платформата и забележете кој сервер одговорил. Split DNS значи дека прашањето за резолверот и прашањето за маршрутирањето имаат различни одговори.

Тие две можат да се разидуваат во двете насоки, а токму тоа разидување често е вистинската грешка.

На systemd хост, resolvectl query го именува интерфејсот и DNS серверот зад одговорот. Постарите поставки го прикажуваат серверот во излезот од dig. Во секој случај поентата е да се види кој сервер одговорил, а не само дали пристигнал одговор.

Тестирајте ја политиката за неуспех, а не само успехот

Ако барањето е никаков сообраќај да не излегува надвор од тунелот, успешното барање не докажува ништо. Употребете го контролираниот тест за неуспех што клиентот го поддржува: запрете го тунелот на поддржаниот начин и видете дали ново барање од гостинот е блокирано. Не претпоставувајте дека kill switch-от на клиентот на хостот ги покрива сите виртуелни шеми за препраќање. Неговиот документиран опсег е единственото на што можете да се потпрете.

Гостин што се враќа на физичкиот NIC кога тунелот ќе падне го прави токму она што го дозволува NAT режимот.

Запишете го режимот и опсегот

Запишете го режимот на хипервизорот, интерфејсот и маршрутата на гостинот, резолверот и апликацијата што сте ја тестирале. Додајте го датумот, бидејќи враќањето на snapshot или ажурирањето на хипервизорот може да ги промени сите четири.

Ако IPv4 го следеше тунелот, кажете го тоа. Не го проширувајте тврдењето на IPv6, друг namespace или друг VM на друга мрежа.