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 трансляция трафигин көрбөйт.