Isännän liikenteen reititys VPN:n läpi VM:ssä: kuusi tarkistusta

Kuusi järjestyksessä tehtyä tarkistusta ratkaisevat, voiko VM toimia oman isäntänsä VPN-yhdyskäytävänä. Hypervisori ei tee tästä mitään puolestasi: vieras omistaa tunnelin, isäntä omistaa reitin, ja niiden välinen verkko on tavallista reititystä. Pidän listaa, koska yhden vaiheen väliin jättäminen antaa aina saman oireen, hiljaisuuden, jossa isäntä pingaa vierasta iloisesti eikä tavoita mitään sisäistä.

Aloita syystä. Joko yrityksen asiakasohjelma asennetaan vain vieraan sisään tai käytäntö pitää sen siellä, ja tarvitset silti sisäisen build-palvelimen isännästä. Jos isäntä saa oman asiakasohjelman, tee se sen sijaan: yksi tunneli isännässä voittaa joka kerta kaksi verkkoa plus NATin.

Tarkistus 1: isäntä tarvitsee yhteyden, jolle se voi antaa osoitteen

Isännällä on oltava liitäntä samassa etuliitteessä kuin vieraan toinen sovitin. Host-only VirtualBoxissa, host-only tai mukautettu VMnet VMware Workstationissa, sisäinen silta tai tap-laite QEMU/KVM:ssä ja Internal-kytkin Hyper-V:ssä kelpaavat kaikki. Vieras 192.168.56.2, isäntä 192.168.56.1, etuliite 192.168.56.0/24 on asetelma, jota käytän laboratorioissa.

QEMU:n käyttäjätilan verkko (-netdev user, oletusarvoinen SLIRP-tausta) ja VirtualBoxin NAT epäonnistuvat tässä tarkistuksessa täysin. Vieraan paketit päätyvät isännän välityspalveluprosessiin, joten isäntä ei koskaan näe laitetta, joka kantaa vieraan osoitteita, eikä sillä ole mitään, mihin reitin voisi osoittaa. Hyper-V:n Default Switch on sama tarina. Jos ping 192.168.56.2 isännästä epäonnistuu, pysähdy: mikään myöhemmin lisätty reitti ei korjaa sitä.

Tarkistus 2: vieras välittää ja kääntää

Isännän paketit saapuvat host-only-lähdeosoitteella ja sisäisellä kohteella, joten vieraan on välitettävä ne ja piilotettava ne sitten tunnelinsa osoitteen taakse. Linux-vieraassa se tarkoittaa edelleenlähetystä, FORWARD accept -paria ja source NATia tunnelia kohti:

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-sääntö on se osa, jonka ihmiset jättävät pois. Yritysten reitittimet tietävät harvoin, että 192.168.56.0/24 on olemassa; säännön kanssa sisäiset palvelimet näkevät vieraan tunneliosoitteen ja vastaavat siihen, ja vastaus löytää tiensä takaisin vieraalle.

Windows-vieras on kömpelömpi. IPEnableRouter=1 kohdassa SYSTEM\CurrentControlSet\Services\Tcpip\Parameters kytkee edelleenlähetyksen ilman käännöstä, joten se toimii vain siellä, missä yrityksen reititys osoittaa jo takaisin teidän host-only-etuliitteeseen. Internet Connection Sharing kääntää, mutta numeroi jaetun sovittimen uudelleen osoitteeseen 192.168.137.1, joten lue osoite, jonka se todella otti, ennen kuin kirjoitat isännän reittejä.

Tarkistus 3: isännän reitit nimeävät vieraan, eivät tunnelia

Päästä vieraan läpi vain ne etuliitteet, joita isäntä tarvitsee. Linuxissa yksi reitti etuliitettä kohden riittää ja se palautuu siististi:

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

Windowsissa vastine on route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Jätä -p pois, kun vielä testaat, jotta huono reitti kuolee uudelleenkäynnistyksessä, ja lisää se, kun polku toimii. Älä poista isännän oletusreittiä, ellet halua jokaisen isännän sovelluksen käyttävän tunnelia; jos täystunneli on todella vaatimus, lisää kaksi /1-reittiä ja pidä suora reitti hypervisorin verkkoon:

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-isännässä tarkista myös liitännän metriikka. Reitti, joka lisättiin host-only-sovittimen ollessa poissa käytöstä, jää tauluun mutta ei koskaan kuljeta liikennettä, ja toinen sovitin pienemmällä metriikalla voi voittaa saman etuliitteen haun.

Tarkistus 4: DNS seuraa reittiä, ei tunnelin oletusta

Reitit liikuttavat paketteja; ratkaisija päättää, mitkä nimet tuottavat paketteja. Rajaa yrityksen ratkaisija yrityksen vyöhykkeeseen sen sijaan että korvaisit isännän ratkaisijan, ja osoita se DNS-palvelimelle, johon uusi reitti jo yltää. Kun isännässä on systemd-resolved:

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

Windowsissa nimenselvityskäytännön taulun merkintä tekee saman: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Jos vieras ajaa omaa ratkaisijaansa host-only-osoitteessa, käytä sitä osoitetta sen sijaan, mutta vasta kun olet vahvistanut, että se vastaa osoitteessa 192.168.56.2 eikä loopbackissa.

Tarkista sitten MTU, ennen kuin syytät DNS:ää hitaista sivuista. Tunnelin liitäntä on pienempi kuin isännän 1500 tavun liitäntä, joten isäntä, joka lähettää täysikokoisia segmenttejä DF-bitti asetettuna, saa ne pudotetuiksi jossain vieraan sisällä. Klassinen oire on toimiva ping ja sisäinen verkkosovellus, joka pysähtyy TLS-kättelyn jälkeen. Kiristä MSS vieraan edelleenlähetyspolulla:

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

Tarkistus 5: varmista molemmista päistä

Isännästä traceroute tai tracert sisäiseen osoitteeseen pitäisi näyttää 192.168.56.2 ensimmäisenä hyppynä, ei fyysistä yhdyskäytävää. Vieraassa seuraa, miten sama yritys lähtee: tcpdump -ni any host 10.20.30.40 näyttää välitetyn pyynnön host-only-puolella ja käännetyn tunnelissa. Pyyntö, joka lähtee, palaa ja jättää isännän silti hiljaiseksi, viittaa paluupolkuun.

Kaksi vikaa selittää suurimman osan tästä. Joko vieraan tunneli ei kanna paluureittiä host-only-etuliitteelle, koska NAT-sääntö puuttuu, tai isännän reitti osoittaa osoitteeseen, jota vieraalla ei enää ole uudelleenkäynnistyksen jälkeen. Lue osoitteet uudelleen komennoilla ip -br addr ja ip route get sen sijaan että luottaisit edellisen istunnon muistiinpanoihin.

Tarkistus 6: tee siitä uudelleenkäynnistyksen ja hypervisorin päivityksen kestävä

Säilytä molemmat puolet: netplan- tai NetworkManager-reittikonfiguraatio isännässä, route add ... -p Windowsissa ja net.ipv4.ip_forward=1 tiedostossa /etc/sysctl.d/ sekä palomuurisäännöstö, joka latautuu uudelleen vieraassa. Ota vieraasta snapshot heti kun konfiguraatio on vahvistettu, ennen kuin seuraava yritysasiakkaan päivitys saapuu.

Host-only-verkot numeroidaan uudelleen, kun hypervisori luo sovittimensa uudelleen, mikä mitätöi hiljaa jokaisen reitin ja NAT-säännön, jotka on rakennettu 192.168.56.0/24 päälle. Päivityksen jälkeen toista kolme ensimmäistä tarkistusta järjestyksessä; se vie minuutin ja nappaa tapauksen, jossa isännällä on vielä reittinsä, kun taas vieras on siirtynyt uuteen aliverkkoon.

IPv6 tarvitsee oman kierroksensa. ip6tables-säännöt, AAAA-tietueet ja toinen isännän reittiperhe eivät seuraa IPv4-asetuksia, ja IPv6:n kautta tavoitettava yrityspalvelu näyttää pysyvästi rikkinäiseltä, kun IPv4 toimii.

Läpi tai ei, järjestyksessä: isäntä voi pingata vieraan host-only-osoitetta; vieras välittää ja tekee MASQUERADEn tunnelia kohti; ip route get palauttaa vieraan sisäisen etuliitteen yhdyskäytäväksi; yrityksen nimet ratkeavat rajatun ratkaisijan kautta; traceroute näyttää vieraan ensimmäisenä; ja samat kuusi vastausta kestävät uudelleenkäynnistyksen.