Използва ли вашата VM VPN на хоста? Тествайте отвътре в госта

Проверявате публичния IP на хоста, той показва VPN, и заключавате, че VM е покрита. Това заключение не се подкрепя от теста. Гостът има своя таблица за маршрутизация, свой резолвер и свои интерфейси, а адресът на изход на хоста не казва нищо за тях.

Тестът трябва да се изпълни вътре в госта и трябва да назове какво е измерил.

Започнете вътре в госта, не в браузъра на хоста

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

Запишете режима, преди да промените нещо, защото той определя какво може да означава резултатът.

Направете една заявка, чиято дестинация познавате

Използвайте безобидна заявка към услуга, която съобщава адреса на източника, който е видяла. След това проверете собственото решение за маршрут на госта за тази дестинация: ip route get 203.0.113.5 отпечатва интерфейса и шлюза, които гостът ще използва.

Ако интерфейсът е нормалната мрежова карта на госта, трафикът не минава през тунел вътре в госта.

Втори адаптер, настройка за прокси или VPN клиент от страна на госта могат да променят отговора за едно приложение и не за друго. Тествайте приложението, което наистина ви интересува, а не обща заявка от шел.

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

Промененият адрес на изход не ви казва кой резолвер е обработил името на хоста. Заявете името изрично с инструмента, който отговаря на платформата, и отбележете кой сървър е отговорил. Разделеният DNS означава, че въпросът за резолвера и въпросът за маршрута имат различни отговори.

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

На хост със systemd resolvectl query посочва интерфейса и DNS сървъра зад отговора. По-старите настройки показват сървъра в изхода на dig — а целта и в двата случая е да видите кой сървър е отговорил, а не само дали е пристигнал отговор.

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

Ако изискването е никакъв трафик да не излиза извън тунела, успешната заявка не доказва нищо. Използвайте поддържания от клиента контролиран тест за отказ: спрете тунела по поддържания начин и вижте дали нова заявка от госта се блокира. Не приемайте, че kill switch на клиента на хоста покрива всяка виртуална схема за препращане. Документираният му обхват е единственото, на което можете да разчитате.

Гост, който се връща към физическата мрежова карта, когато тунелът падне, прави точно това, което режим NAT позволява.

Запишете режима и обхвата

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

Ако IPv4 е следвал тунела, кажете го. Не разширявайте твърдението към IPv6, друго пространство от имена или друга VM в друга мрежа.