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 режимі рұқсат ететін нәрсені істеп жатыр.

Режимді және ауқымды жазып алыңыз

Гипервизор режимін, гостьтің интерфейсі мен маршрутын, резолверді және сыналған қолданбаны жазып алыңыз. Күнді де қосыңыз, өйткені snapshot-ты қалпына келтіру немесе гипервизорды жаңарту төртеуін де өзгертуі мүмкін.

Егер IPv4 туннельге ерсе, соны айтыңыз. Тұжырымды IPv6-ға, басқа namespace-ке немесе басқа желідегі басқа VM-ге таратпаңыз.