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 үчүн да улантпаңыз.