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

Ирети менен аткарылган алты текшерүү 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 конокту биринчи көрсөтөт; жана ошол эле алты жооп кайра жүктөөгө туруштук берет.