VM ішіндегі VPN арқылы хост трафигін маршруттау: алты тексеру

VM-ді өз хосты трафигін маршруттайтын VPN қақпасына айналдыру үшін алты реттік тексеру: адаптер режимі, қайта жіберу, NAT, хост маршруттары, DNS, MTU.

Ретімен орындалатын алты тексеру VM өз хосты үшін VPN қақпасы бола алатынын анықтайды. Гипервизор бұның ешқайсысын сіз үшін жасамайды: туннель қонаққа тиесілі, маршрут хостқа тиесілі, ал олардың арасындағы желі — қарапайым маршруттау. Бұл тізімді ұстаймын, өйткені бір қадамды өткізіп жіберу әрдайым бірдей симптом береді, тыныштық, хост қонақты көңілді пингтейді де ішкі ештеңеге жетпейді.

Себебінен бастаңыз. Не корпоративтік клиент тек қонақтың ішіне орнатылады, не саясат оны сонда ұстайды, ал сізге әлі де хосттан ішкі build сервері керек. Егер хостқа өз клиенті рұқсат етілсе, оны жасаңыз: хосттағы бір туннель әрдайым екі желі мен NAT-тан артық.

Тексеру 1: хостқа мекенжай бере алатын байланыс керек

Хостта қонақтың екінші адаптерімен бір префикстегі интерфейс болуы керек. VirtualBox-те host-only, VMware Workstation-да host-only немесе арнайы VMnet, QEMU/KVM-де ішкі көпір немесе tap құрылғысы, Hyper-V-те Internal коммутаторы — бәрі жарамды. Қонақ 192.168.56.2, хост 192.168.56.1, префикс 192.168.56.0/24 зертханаларда қолданатын орналасуым.

QEMU-дің пайдаланушы режиміндегі желісі (-netdev user, әдепкі SLIRP backend) және VirtualBox NAT бұл тексеруден толықтай өтпейді. Қонақ пакеттері хосттағы прокси процесіне жетеді, сондықтан хост қонақтың мекенжайларын тасымалдайтын құрылғыны ешқашан көрмейді және маршрутты бағыттайтын ештеңесі жоқ. Hyper-V-тің Default Switch-і де сол әңгіме. Егер хосттан ping 192.168.56.2 сәтсіз болса, тоқтаңыз: кейін қосылған ешбір маршрут мұны түзетпейді.

Тексеру 2: қонақ қайта жібереді және түрлендіреді

Хосттан келетін пакеттер host-only бастау мекенжайымен және ішкі межелі орынмен келеді, сондықтан қонақ оларды қайта жіберуі керек, содан кейін өз туннель мекенжайының артына жасыруы керек. Linux қонағында бұл қайта жіберу, FORWARD accept жұбы және туннельге қарай source NAT дегенді білдіреді:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

MASQUERADE ережесі — адамдар қалдыратын бөлік. Корпоративтік маршрутизаторлар 192.168.56.0/24 бар екенін сирек біледі; ережемен ішкі серверлер қонақтың туннель мекенжайын көріп, оған жауап береді, ал жауап қонаққа қайту жолын табады.

Windows қонағы ыңғайсызырақ. SYSTEM\CurrentControlSet\Services\Tcpip\Parameters астындағы IPEnableRouter=1 қайта жіберуді түрлендірусіз қосады, сондықтан ол тек корпоративтік маршруттау сіздің host-only префиксіңізге қайта көрсететін жерде жұмыс істейді. Internet Connection Sharing түрлендіреді, бірақ ортақ адаптерді 192.168.137.1 мекенжайына қайта нөмірлейді, сондықтан хост маршруттарын жазбас бұрын оның нақты алған мекенжайын оқыңыз.

Тексеру 3: хост маршруттары қонақты атайды, туннельді емес

Қонақ арқылы хостқа қажет префикстерді ғана жіберіңіз. Linux-та бір префикске бір маршрут жеткілікті және ол таза қайтарылады:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Windows-та баламасы — route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Сынақ кезінде -p қалдырыңыз, жаман маршрут қайта жүктеуде өлсін, ал жол жұмыс істегенде қосыңыз. Хосттың әдепкі маршрутын жоймаңыз, егер хосттың әр қолданбасы туннельді пайдалануы керек болмаса; егер шынымен толық туннель қажет болса, екі /1 маршрутын қосып, гипервизор желісіне тікелей маршрутты сақтаңыз:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Windows хостта интерфейс метрикасын да тексеріңіз. host-only адаптері өшірулі тұрғанда қосылған маршрут кестеде қалады, бірақ ешқашан трафик тасымалдамайды, ал метрикасы төмен екінші адаптер сол префиксті іздеуді ұтып алуы мүмкін.

Тексеру 4: DNS маршрутты ұстанады, туннельдің әдепкісін емес

Маршруттар пакеттерді жылжытады; шешуші қандай атаулар пакет тудыратынын шешеді. Корпоративтік шешушіні хост шешушісін ауыстырудың орнына корпоративтік аймақпен шектеп, оны жаңа маршрут әлдеқашан жететін DNS серверіне бағыттаңыз. Хостта systemd-resolved арқылы:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Windows-та атау шешу саясаты кестесінің жазбасы дәл сол жұмысты жасайды: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Егер қонақ host-only мекенжайында өз шешушісін іске қосса, оның орнына сол мекенжайды қолданыңыз, бірақ оның loopback-те емес, 192.168.56.2-де жауап беретінін растағаннан кейін ғана.

Содан кейін баяу беттер үшін DNS-ті кінәламас бұрын MTU-ды тексеріңіз. Туннель интерфейсі хосттың 1500 байттық интерфейсінен кіші, сондықтан DF биті қойылған толық өлшемді сегменттерді жіберетін хост оларды қонақтың ішінде бір жерде жоғалтады. Классикалық симптом — жұмыс істейтін ping және TLS қол алысуынан кейін тұрып қалатын ішкі веб қолданба. Қонақтың қайта жіберу жолында MSS-ті тарылтыңыз:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Тексеру 5: екі жақтан тексеріңіз

Хосттан ішкі мекенжайға traceroute немесе tracert бірінші хоп ретінде физикалық қақпаны емес, 192.168.56.2 көрсетуі керек. Қонақта сол әрекеттің шығуын бақылаңыз: tcpdump -ni any host 10.20.30.40 host-only жағында қайта жіберілген сұранысты және туннельде түрлендірілгенін көрсетеді. Шығып, қайтып келгенімен хостты үнсіз қалдыратын сұраныс қайту жолына нұсқайды.

Бұның көбін екі ақау түсіндіреді. Не қонақтың туннелінде host-only префиксі үшін қайту маршруты жоқ, өйткені NAT ережесі жоқ, не хост маршруты қонақ қайта жүктеуден кейін ұстамайтын мекенжайға көрсетеді. Өткен сессияның жазбаларына сенудің орнына мекенжайларды ip -br addr және ip route get арқылы қайта оқыңыз.

Тексеру 6: оны қайта жүктеуге және гипервизорды жаңартуға төзімді етіңіз

Екі жартысын да сақтаңыз: хостта netplan немесе NetworkManager маршрут конфигурациясы, Windows-та route add ... -p, және /etc/sysctl.d/ ішінде net.ipv4.ip_forward=1 пен қонақта қайта жүктелетін firewall ережелер жинағы. Конфигурация расталған бойда, келесі корпоративтік клиент жаңартуы келмей тұрып, қонақтың snapshot-ын алыңыз.

host-only желілер гипервизор өз адаптерлерін қайта жасағанда қайта нөмірленеді, бұл 192.168.56.0/24 негізінде салынған әрбір маршрут пен NAT ережесін үнсіз жарамсыз етеді. Жаңартудан кейін алғашқы үш тексеруді ретімен қайталаңыз; бұл бір минут алады және хостта маршруты әлі бар, ал қонақ жаңа қосалқы желіге көшкен жағдайды ұстайды.

IPv6 өз айналымын қажет етеді. ip6tables ережелері, AAAA жазбалары және хост маршруттарының екінші тобы IPv4 баптауын ұстанбайды, ал IPv6 арқылы қолжетімді корпоративтік қызмет IPv4 жұмыс істеп тұрғанда мәңгі бұзылған болып көрінеді.

Өтсе де, өтпесе де, ретімен: хост қонақтың host-only мекенжайын пингтей алады; қонақ туннельге қарай қайта жібереді және MASQUERADE жасайды; ip route get ішкі префикс үшін қақпа ретінде қонақты қайтарады; корпоративтік атаулар шектелген шешуші арқылы шешіледі; traceroute қонақты бірінші көрсетеді; және сол алты жауап қайта жүктеуге төтеп береді.

Қатысты мақалалар