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

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

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

Почните из унутрашњости госта, а не из прегледача хоста

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

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

Пошаљите један захтев чију одредишну тачку знате

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

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

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

Резолвер проверите одвојено

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

То двоје могу да се разиђу у оба смера, а управо то разилажење је често права грешка.

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

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

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

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

Забележите режим и обим

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

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