Ostalari trafikoa VM bateko VPN baten bidez bideratzea: sei egiaztapen

Sei egiaztapen, ordenean exekutatuta, VM bat bere ostalariaren VPN atebide izan daitekeen erabakitzen dute. Hiperbisoreak ez du horietako ezer egiten zuretzat: gonbidatuak tunela du, ostalariak ibilbide bat du, eta bien arteko sarea bideratze arrunta da. Zerrenda mantentzen dut, pauso bat saltatzeak beti sintoma bera ematen duelako, isiltasuna, ostalariak gonbidatuari pozik ping egiten dion eta barruko ezer ez duen egoeran.

Hasi arrazoiarekin. Edo enpresak bezeroa gonbidatuaren barruan bakarrik instalatzen da, edo politikak han mantentzen du, eta zuk oraindik ostalaritik barneko build zerbitzaria behar duzu. Ostalariak bere bezero propioa izan dezakeen kasuan, egin hori: ostalarian tunel batek beti irabazten die bi sare gehi NAT bati.

1. egiaztapena: ostalariak helbidera dezakeen lotura behar du

Ostalariak interfaze bat izan behar du gonbidatuaren bigarren egokitzailea dagoen aurrizki berean. Host-only VirtualBoxen, host-only edo VMnet pertsonalizatua VMware Workstationen, zubi internua edo tap gailua QEMU/KVMn, eta Internal etengailua Hyper-Vn egokiak dira guztiak. Gonbidatua 192.168.56.2, ostalaria 192.168.56.1, aurrizkia 192.168.56.0/24 laborategietan erabiltzen dudan diseinua da.

QEMUren erabiltzaile moduko sareak (-netdev user, SLIRP backend lehenetsia) eta VirtualBoxen NATak huts egiten dute egiaztapen honetan erabat. Gonbidatuaren paketeak ostalarian proxy prozesu batera iristen dira, beraz ostalariak ez du inoiz gonbidatuaren helbideak daramatzan gailurik ikusten eta ez du ibilbidea seinalatzeko ezer. Hyper-Vren Default Switch istorio bera da. Ostalaritik ping 192.168.56.2 huts egiten badu, gelditu: geroago gehitzen den ibilbide batek ere ez du konponduko.

2. egiaztapena: gonbidatuak birbidaltzen eta itzultzen du

Ostalaritik datozen paketeak host-only helbide bat eta barne helmuga batekin iristen dira, beraz gonbidatuak birbidali behar ditu eta gero bere tunelaren helbidearen atzean ezkutatu. Linux gonbidatu batean horrek birbidalketa, FORWARD accept pare bat eta tuneleraino source NAT esan nahi du:

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 araua jendeak uzten duen zatia da. Enpresa bideratzaileek gutxitan dakite 192.168.56.0/24 existitzen denik; arauarekin, barne zerbitzariek gonbidatuaren tunelaren helbidea ikusten dute eta hura erantzuten dute, eta erantzunak bidea aurkitzen du gonbidatuarengana itzultzeko.

Windows gonbidatua traketsagoa da. SYSTEM\CurrentControlSet\Services\Tcpip\Parameters azpiko IPEnableRouter=1 birbidalketa pizten du itzulpenik gabe, beraz enpresa bideratzeak jada zure host-only aurrizkira itzultzen duen tokian bakarrik funtzionatzen du. Internet Connection Sharing ek itzultzen du, baina partekatutako egokitzailea 192.168.137.1 ra birzenbakitzen du, beraz irakurri benetan hartu zuen helbidea ostalariaren ibilbideak idatzi aurretik.

3. egiaztapena: ostalariaren ibilbideek gonbidatua aipatzen dute, ez tunela

Bidali gonbidatuaren bidez ostalariak behar dituen aurrizkiak bakarrik. Linuxen aurrizki bakoitzeko ibilbide bat nahikoa da eta garbi itzultzen da:

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

Windowsen baliokidea route add 10.20.0.0 mask 255.255.0.0 192.168.56.2 da. Utzi -p kanpoan probatzen ari zaren bitartean, ibilbide txar bat berrabiaraztean hil dadin, eta gehitu bidea funtzionatzen duenean. Ez ezabatu ostalariaren ibilbide lehenetsia ostalariaren aplikazio guztiek tunela erabili behar dutenik ez bada; tunel osoa benetan baldintza bada, gehitu bi /1 ibilbideak eta mantendu hiperbisorearen sarerako ibilbide zuzena:

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 ostalarian, egiaztatu interfazearen metrika ere. Host-only egokitzailea desgaituta zegoela gehitutako ibilbidea taulan geratzen da baina ez du inoiz trafikorik eramaten, eta metrika txikiagoa duen bigarren egokitzaile batek aurrizki beraren bilaketa irabaz dezake.

4. egiaztapena: DNSak ibilbidea jarraitzen du, ez tunelaren lehenetsia

Ibilbideek paketeak mugitzen dituzte; ebazleak erabakitzen du zein izenek sortzen dituzten paketeak. Mugatu enpresa ebazlea enpresa gunera, ostalariaren ebazlea ordezkatu beharrean, eta seinalatu ibilbide berriak jada iristen duen DNS zerbitzari batera. Ostalarian systemd-resolved erabiliz:

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

Windowsen izen ebazpen politikaren taulako sarrera batek gauza bera egiten du: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Gonbidatuak host-only helbidean bere ebazlea exekutatzen badu, erabili helbide hori horren ordez, baina 192.168.56.2 n eta ez loopbacken erantzuten duela egiaztatu ondoren.

Ondoren egiaztatu MTUa DNSa orrialde geldoen errua leporatu aurretik. Tunelaren interfazea ostalariaren 1500 byteko interfazea baino txikiagoa da, beraz DF bita jarrita tamaina osoko segmentuak bidaltzen dituen ostalariak gonbidatuaren barruan nonbait galtzen ditu. Sintoma klasikoa ping funtzionatzen duela eta TLS esku-ukaldiaren ondoren trabatzen den barne web aplikazio bat da. Estutu MSS gonbidatuaren birbidalketa bidean:

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

5. egiaztapena: egiaztatu bi muturretatik

Ostalarian, traceroute edo tracert barne helbide batera lehen jauzian 192.168.56.2 erakutsi behar du, ez atebide fisikoa. Gonbidatuan, ikusi saiakerak nola irteten duen: tcpdump -ni any host 10.20.30.40 k host-only aldean birbidalitako eskaera eta tunelean itzulitakoa erakusten ditu. Irteten, itzultzen eta ostalaria isilik uzten duen eskaerak itzulera bidea seinalatzen du.

Hutsegite bi azaltzen dute horren zatirik handiena. Edo gonbidatuaren tunelak ez du itzulera ibilbiderik host-only aurrizkiarentzat NAT araua falta delako, edo ostalariaren ibilbideak gonbidatuak berrabiarazi ondoren jada ez duen helbide bat seinalatzen du. Irakurri berriro helbideak ip -br addr eta ip route get erabiliz, aurreko saioko oharretan fidatu beharrean.

6. egiaztapena: egin berrabiarazteari eta hiperbisorearen bertsio-berritze bati aurre egiteko moduan

Iraunarazi bi erdiak: netplan edo NetworkManager ibilbide konfigurazioa ostalarian, route add ... -p Windowsen, eta net.ipv4.ip_forward=1 /etc/sysctl.d/ n gehi gonbidatuan berriz kargatzen den suebaki arau multzoa. Hartu gonbidatuaren snapshot bat konfigurazioa egiaztatu bezain laster, enpresaren hurrengo bezero eguneraketa iritsi aurretik.

Host-only sareak birzenbakitzen dira hiperbisoreak bere egokitzaileak birsortzen dituenean, eta horrek isilka baliogabetzen ditu 192.168.56.0/24 ren gainean eraikitako ibilbide eta NAT arau guztiak. Bertsio-berritze baten ondoren, errepikatu lehen hiru egiaztapenak ordenean; minutu bat kostatzen du eta ostalariak bere ibilbidea oraindik duen bitartean gonbidatua azpisare berri batera aldatu den kasua harrapatzen du.

IPv6k bere pasabide propioa behar du. ip6tables arauek, AAAA erregistroek eta ostalariaren bigarren ibilbide familiak ez diote IPv4 ezarpenari jarraitzen, eta IPv6 bidez iristen den enpresa zerbitzu bat betiko hautsita egongo da IPv4 funtzionatzen duen bitartean.

Pasa edo huts, ordenean: ostalariak gonbidatuaren host-only helbideari ping egin diezaioke; gonbidatuak birbidaltzen eta MASQUERADE egiten du tunelerantz; ip route get k gonbidatua itzultzen du barne aurrizkiaren atebide gisa; enpresa izenak ebazle mugatuaren bidez ebazten dira; traceroute k gonbidatua lehenik erakusten du; eta sei erantzun berberak berrabiarazteari eusten diote.