VM-liikenteen reititys host-only-verkossa TUN OpenVPN -palvelimen kautta

Host-only-sovittimet luovat paikallisen virtuaaliverkon, ja reititetyt TUN-tunnelit kuljettavat IP-paketteja osoitteiden välillä. Kumpikaan ei ole silta toiseen, siksi toimivan kokoonpanon on kerrottava, kuka välittää ja kenelle paluureitti kuuluu. Jos nämä kaksi määritystä menevät väärin, vieras vastaa tunnelille lähteellä, jota tunnelin asiakas ei koskaan pyytänyt. Alla oleva suunnittelu pitää molemmat etuliitteet erillään ja tekee paluureitistä eksplisiittisen.

Kaksi verkkoa, kaksi etuliitettä

Anna tunnelialtaalle ja host-only-verkolle eri etuliitteet äläkä koskaan käytä yhtä toisen sijaan. Tässä esimerkissä VPN-allas on 10.44.0.0/24 ja host-only-verkko on 192.168.99.0/24, isäntä on 192.168.99.1 ja vieras 192.168.99.20. Saman etuliitteen antaminen sekä TUN-laitteelle että host-only-sovittimelle ei yhdistä niitä. Se luo kaksi vaatimusta yhdelle osoitealueelle, ja reititystaulu vastaa sitten sen vaatimuksen puolesta, jonka se sattui pitämään.

Host-only-sovitin on olemassa isännässä ja vieraan sisällä, ja sillä ei ole itsessään reittiä ulos koneesta. Sillatuilla ja NAT-liitännöillä on erilainen näkyvyys, eikä siltatilaan siirtyminen ole edellytys yhden vieraspalvelun saavuttamiselle.

Isännällä on reitti jo

Katso, mitä on olemassa ennen kuin lisäät mitään. Isännällä on liitäntä host-only-verkossa ja reitti sille etuliitteelle, molemmat syntyivät, kun sovitin nousi.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

Kolmas rivi on mekanismi, joka tekee isännästä hypyn. Ilman sitä tunnelista saapuva paketti on osoitettu verkkoon, jonka isäntä tavoittaa mutta ei välitä eteenpäin. Välitys on välttämätöntä eikä riitä. Suodatinpolitiikka päättää edelleen, sallitaanko tietty virta tunnelin liitännän ja host-only-liitännän välillä, ja se päätös kuuluu kirjalliseen muotoon eikä oletuspolitiikkaan, jota kukaan ei lukenut.

Työnnä reitti ja suodata sitten, mihin se yltää

Palvelin voi antaa host-only-etuliitteen asiakkaille, jotka hyväksyvät työnnetyt reitit, mikä on sama mekanismi kuin mille tahansa muulle tunnelin takaiselle aliverkolle.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Nämä kaksi sääntöä sallivat yhden palvelun yhteen suuntaan ja sen vastaukset. Reitti, joka yltää koko etuliitteeseen, ja suodatin, joka sallii yhden portin, ovat tarkoituksellinen yhdistelmä; reitti plus ehdoton hyväksyntä on tapa, jolla laboratoriopalvelusta tulee altistettu palvelu. Työnnetty reitti ei ole valtuutus sekään. Asiakas hyväksyy sen, isäntä välittää sen, ja vieraan palomuuri ja palvelu itse sanovat yhä sanansa.

Vieras tarvitsee tien takaisin

Vieraan, johon päästään osoitteesta 10.44.0.x, on lähetettävä vastauksensa isännän host-only-osoitteeseen, tai isännän on käännettävä lähde. Osoitteen saaminen VirtualBoxin DHCP:stä ei kerro kummastakaan järjestelystä mitään.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Tämän reitin lisääminen vieraan sisällä säilyttää alkuperäisen lähteen, mikä pitää asiakaskohtaisen politiikan ja lokit merkityksellisinä. Rajoitettu lähdekäännös isännässä on vaihtoehto, ja se toimii, mutta sen hinnalla, että se kätkee, mikä asiakas yhdisti. Päällekkäisyys on toinen vikatila. Etäasiakas, jonka kotiverkko käyttää jo 192.168.99.0/24, lukee työnnetyn reitin omana verkkoaan, eikä mikään palvelinpuolen muutos korjaa tätä monitulkintaisuutta. Numeroi toinen puoli uudelleen tai valitse etuliite, joka tuskin törmää.

TUN-laite kuljettaa IP-paketteja, joten oletusyhdyskäytävän lisääminen vieraan sisällä ei tee tunnelista Ethernet-segmenttiä host-only-sovittimen kanssa. TAP-silta on eri suunnittelu, jolla on oma asiakastukensa ja osoitteenomistuksensa, ja kahden kuvauksen sekoittaminen johtaa kokoonpanoihin, jotka eivät koskaan lähene toisiaan.

Varmista ja tee siitä sitten uudelleenkäynnistyksen kestävä

Testaa yhtä vaaratonta palvelua tavallisesta etäasiakkaasta, tarkista vieraan paluureitti ja vahvista, että palvelu, jota et sallinut, hylätään eikä ole hidas.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Käynnistä sitten VPN-palvelu ja virtuaalikoneen verkko uudelleen ja toista samat kolme tarkistusta. Käsin lisätty reitti säilyy seuraavaan uudelleenkäynnistykseen asti, eikä kokoonpano, joka toimii vain lämpimässä istunnossa, ole suunnittelu. Kirjaa kaksi etuliitettä, välityspolitiikka ja vieraan reitti yhteen. Seuraavan virtuaalikoneen lisääjä tarvitsee kaikki kolme ja löytää ne muuten uudelleen yksi epäonnistunut yhteys kerrallaan.