NAT немесе көпірлі VM желісі: VPN трафигін қайсысы тасымалдайды?
NAT қонақтары хосттың туннелін тек клиент маршрут бойынша туннельдегенде қарызға алады; көпірлі қонақтар өздері маршруттайды. Қонақты тексеріңіз, содан кейін сәйкес режимді таңдаңыз.
Көпір және NAT бір қонақты VPN-ге қосудың екі тәсілі емес; олар туннель іске қосылғанға дейін қонақтың пакеттері кімдікі екенін шешеді. NAT режимінде гипервизор қонақтың трафигін қайта жазып, оны хост жағындағы кодтан шығарады, сондықтан қонақ хост сол кодқа берген маршрутпен жүреді. Көпірлі режимде қонақ физикалық сегментте өз байланыс деңгейіндегі сәйкестігін алады және өз әдепкі шлюзін таңдайды, бұл хосттың туннелін оған маңызсыз етеді, тек LAN маршрутизаторы туннель жасамаса. Мен VM-ді VPN-де деп санауды қойып, оны сол қонақтың әдепкі маршруты қайда бағытталғаны туралы сұрақ ретінде қарастыра бастадым. Төмендегі тест режимге бірнеше минут алады және болжамсыз шешеді.
NAT қонақты гипервизор кодының артында ұстайды, онда хост маршруттары қолданылады
VirtualBox-та NAT қонағы 10.0.2.0/24-те отырады, виртуалды шлюз 10.0.2.2-де, DNS проксиі 10.0.2.3-те, ал физикалық желіге өз маршруты жоқ. Шығатын пакеттерді NAT қозғалтқышы алады, көзі хост болатындай қайта жазады және хосттың IP стегіне береді. Одан әрі қонақтың трафигі хост ағыны, ал маршрутты іздеу межелік бойынша жүреді: хостқа 0.0.0.0/1 және 128.0.0.0/1 орнататын толық туннель клиенті оны ұстап алады, VM бар екенін ешқашан білмей. Oracle-дың VirtualBox желілері туралы тарауы осы әдепкі мәндерді тізімдейді, егер мекенжайларды өз құрылымыңызда растағыңыз келсе.
libvirt-тің әдепкі желісі 192.168.122.0/24-тен сол жерге жетеді, онда dnsmasq лизингтер таратып, хост ішкі желіні маскарадтайды, сондықтан қонақтың пакеттері қайтадан хосттың маршруттау шешіміне келеді. Ерекшелік — трафикті маршрут бойынша емес, процесс бойынша таңдайтын клиент. Егер бөлінген туннель тізімінде тек браузеріңіз болса және басқа ештеңе болмаса, NAT қозғалтқышы бұл тізімде жоқ, ал қонақ машинадан туннельсіз шығады, хосттың браузері әлі де қамтылған болып көрінеді. Бір ішкі желі, қарама-қарсы нәтиже.
Көпір қонаққа физикалық LAN-да өз орнын береді
Көпірлі қонаққа нақты адаптерге қосылған виртуалды NIC беріледі, ол өз MAC мекенжайын алады және физикалық желіден DHCP лизингін алады. Оның әдепкі шлюзі LAN маршрутизаторы, гипервизор емес, ал кадрлары сол адаптер арқылы сымға шығады. Хосттың туннель маршруттары хост кестесінде тұрады және ешқашан сұралмайды, өйткені қонақтың кадрлары хосттың IP стегіне ешқашан кірмейді.
Бұл екі жаққа да кесіледі. mDNS және SMB шолуы жұмыс істей бастайды, өйткені қонақ LAN хабар тарату трафигін көреді, ал қонақ арасында хосттың брандмауэры жоқ сол сегменттің басқа машиналарынан қолжетімді болады. Көпір сонымен қатар қонақты бар туннель арқылы итерудің жолы емес: VM-ді хосттың WireGuard немесе OpenVPN интерфейсіне қосу — VirtualBox немесе libvirt сіз үшін жасайтын нәрсе емес. Егер көпірлі қонақ туннельден өтуі керек болса, туннель сол LAN-ның бір жерінде аяқталуы керек.
Дауды бітіретін тест
Екі режимде де бірдей тексерулерді орындап, жауаптарды жазып алыңыз:
- Хостта
curl -s https://ifconfig.meжалпыға ашық v4 мекенжайын береді. - Қонақта сол команда, қосымша әдепкі шлюз үшін Linux-та
ip routeнемесе Windows-таGet-NetRoute -DestinationPrefix 0.0.0.0/0. - Шешушінің сәйкестігі: қонақта
resolvectl statusнемесеcat /etc/resolv.conf, оның 10.0.2.3-ке немесе LAN серверіне сілтейтінін көру үшін. - Мекенжай тобы:
ip -6 addr show scope globalжәне бір v6 сұранысы, өйткені v4 туннелі қонақта болуы мүмкін ғаламдық v6 мекенжайы туралы ештеңе айтпайды.
Сәйкес келетін жалпыға ашық мекенжайлар қонақ хосттың жолында екенін білдіреді. LAN-ның әдеттегі шығысына сәйкес келетін қонақ мекенжайы олай емес екенін білдіреді. Адамдар өткізіп жіберетін қадам — бақылау: хосттың туннелін төмендетіп, қонақтың сұранысын қайталаңыз. Егер қонақ шолуды жалғастырса, ол хосттың туннеліне ешқашан тәуелді болмаған, режим атауы қандай нұсқаса да. NAT режимінде хост туннелі төменде болғанда қонақ интернеттен айырылуы керек, егер клиент туннельсіз трафикке рұқсат беретіндей конфигурацияланбаса, оны өздігінен білу керек.
Екі сигнал өтірік айтады. Сәтті ping қолжетімділікті дәлелдейді, шығу жолын емес. Ал DNS-ке 10.0.2.3 проксиі хосттың шешушісі арқылы жауап беруі мүмкін, сол кезде TCP басқа маршрутпен жүреді, осылайша бет жүктеледі, ал кіру ешқашан аяқталмайды.
Жұмысқа қай режим сәйкес келеді
Режим — маршруттау шешімі, сондықтан оны әдеттен емес, талаптан таңдаңыз:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
Бірінші жол — адамдар сүрінетін жер: NAT пен хосттағы толық туннель клиенті қонақты шынымен қамтиды, бірақ клиент маршрут бойынша туннельдеп, хосттың жоғарғы байланысы сол туннель болғанша ғана. Клиентті тек браузерге арналған рұқсат тізіміне ауыстырыңыз, сонда қамту еш жерде ешқандай қатесіз жоғалады. Төртінші жол — керісінше қате: ыңғайлылық үшін көпірленген қонақ кеңсе LAN-ында SMB немесе SSH-ке үнсіз жауап бере бастайды.
VPN-ге таңылатын ақаулар
Windows-та NAT аудармасы VirtualBox VM процесінің ішінде жүреді, сондықтан әр қолданбаға арналған клиент виртуалды машиналарға арналған жалпы ереженің орнына дәл сол бейнені өз тізімінде ұстауы керек. Клиент жаңартуы өз процестер тізімін қайта құрғанда, NAT қонақтары бірінші қамтудан айырылады, ал есеп хост жақсы болған кезде LAN-ға жететін, бірақ интернетке жетпейтін VM сияқты оқылады.
Wi-Fi-ға көпір салу — тағы бір классика. Кіру нүктелері бөгде бастау MAC-і бар кадрларды сирек жібереді, сондықтан wlan0-ға көпір не толығымен сәтсіз болады, не AP-дағы клиент оқшаулауы оны тастай бастағанша жұмыс істейді. VirtualBox сымсыз адаптерді бәрібір өз тізімінде ұсынады. Егер хост Wi-Fi-да болса және қонақ көпірленуі керек болса, болжаудың орнына тексеруді жоспарлаңыз.
MTU — үшіншісі. Көпірлі қонақ LAN-ның 1500 байт MTU-ын сақтайды, ал егер ол өз WireGuard клиентін 1420-де жүргізсе, үлкен TLS қол алысулары тұрып қалады, кішкентай сұраныстар сәтті болады. NAT астында хост туннелінің MTU-ы хосттың мәселесі, бірақ қонақ әлі де 1500-ге сенеді, ал don't-fragment биті қосылған UDP дәл солай жоғалады.
Режимді жазып алып, әр адаптер өзгерісінен кейін қайта тексеріңіз
Режимді, көпір қолданатын хост интерфейсін, қонақтың әдепкі шлюзін, оның шешушісін және оның v4 және v6 шығу мекенжайларын жазып алыңыз. Дәл осы жазба келесі ақауды арзан етеді: ноутбук доктан Wi-Fi-ға ауысқанда, көпірлі қонақ көпірмен бірге басқа физикалық адаптерге өтіп, басқа ішкі желіде қайта лизинг алуы мүмкін, ал NAT қонағы өзінің 10.0.2.x мекенжайын сақтап, үнсіз басқа жоғарғы байланысты мұраға алады.
Билетті жаппас бұрын осылардың әрқайсысын растаңыз:
- Қонақтың шығу мекенжайы хосттың шығу мекенжайынан өзгеше, сондықтан ол хосттың туннелінде емес.
- Шешуші — 10.0.2.3 проксиі немесе LAN сервері, және қайсысы жауап бергенін білесіз.
- Туннель жобасы тек v4 болса, қонақта ғаламдық v6 мекенжайы жоқ.
- Хосттың туннелі төменде болғанда қонақ шолуды тоқтатады, немесе оның оған ешқашан тәуелді болмағанын енді білесіз.
- Қонақ өзіне қатысы жоқ LAN хабар тарату трафигін көрмейді.