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 талд дамжуулсан хүсэлт, туннель дээр хөрвүүлсэн хүсэлтийг харуулна. Гарч, буцаж ирээд хост-ыг чимээгүй үлдээсэн хүсэлт буцах зам руу заана.

Үүний ихэнхийг хоёр алдаа тайлбарладаг. Нэг бол NAT дүрэм байхгүйн улмаас зочны туннель host-only префикс рүү буцах маршрут агуулдаггүй, эсвэл хост-ийн маршрут дахин ачаалсны дараа зочинд байхгүй хаяг руу заана. Өмнөх сессийн тэмдэглэлд итгэхийн оронд хаягуудыг 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 зочныг эхлээд харуулна; мөн тэр зургаан хариулт дахин ачаалалтыг давана.

Холбоотой нийтлэлүүд