VM-i liikluse marsruutimine host-only-võrgus läbi TUN OpenVPN serveri

Host-only-adapterid loovad kohaliku virtuaalvõrgu ja marsruuditud TUN-tunnelid kannavad IP-pakette aadresside vahel. Kumbki ei ole teise jaoks sild, seetõttu peab töötav seadistus ütlema, kes edastab ja kellele kuulub tagasitee marsruut. Kui need kaks omistust valesti lähevad, vastab külaline tunnelile allikaga, mida tunneli klient kunagi ei küsinud. Alljärgnev disain hoiab mõlemad prefiksid eraldi ja teeb tagasitee selgesõnaliseks.

Kaks võrku, kaks prefiksit

Andke tunnelipõhjale ja host-only-võrgule erinevad prefiksid ega kasuta kunagi ühte teise jaoks. Selles näites on VPN-i põhi 10.44.0.0/24 ja host-only-võrk 192.168.99.0/24, host on 192.168.99.1 ja külaline 192.168.99.20. Sama prefiksi omistamine nii TUN-seadmele kui ka host-only-adapterile ei ühenda neid. See loob ühele aadressivahemikule kaks nõuet ja marsruutimistabel vastab siis selle nõude eest, mille see juhuslikult alles jättis.

Host-only-adapter on olemas hostil ja külalise sees, ja sel ei ole iseenesest teed masinast välja. Silla- ja NAT-ühendustel on erinev nähtavus ning sillarežiimile üleminek ei ole ühe külaliseteenuse kättesaamise eeldus.

Hostil on tee juba olemas

Vaadake, mis on olemas, enne kui midagi lisate. Hostil on liides host-only-võrgus ja selle prefiksi marsruut, mõlemad loodi adapteri käivitumisel.

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

Kolmas rida on mehhanism, mis muudab hosti hüppeks. Ilma selleta on tunnelist saabuv pakett adresseeritud võrku, mille host suudab kätte saada, kuid mida ta ei edasta. Edastamine on vajalik ja mitte piisav. Filtreerimispoliitika otsustab endiselt, kas konkreetne voog tunneli liidese ja host-only-liidese vahel on lubatud, ja see otsus kuulub kirjalikku kujule, mitte vaikepoliitikasse, mida keegi ei lugenud.

Lükake marsruut ja seejärel filtreerige, mida see ulatub

Server saab anda host-only-prefiksi klientidele, kes aktsepteerivad lükatud marsruute, mis on sama mehhanism, mida kasutatakse iga teise tunneli taga oleva alamvõrgu jaoks.

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

Need kaks reeglit lubavad ühte teenust ühes suunas ja selle vastuseid. Marsruut, mis ulatub kogu prefiksini, ja filter, mis lubab ühe pordi, on teadlik kombinatsioon; marsruut pluss tingimusteta lubamine on viis, kuidas laboriteenusest saab avatud teenus. Lükatud marsruut ei ole ka volitus. Klient võtab selle vastu, host edastab selle ning külalise tulemüür ja teenus ise ütlevad endiselt oma sõna.

Külaline vajab teed tagasi

Külaline, kelleni jõutakse aadressilt 10.44.0.x, peab saatma oma vastused hosti host-only-aadressile või peab host allikat tõlkima. Aadressi saamine VirtualBoxi DHCP-st ei ütle kummagi korralduse kohta midagi.

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

Selle marsruudi lisamine külalise sees säilitab algse allika, mis hoiab kliendipõhise poliitika ja logid mõttekad. Piiratud allika tõlkimine hostil on alternatiiv ja see töötab, aga selle hinnaga, et varjab, milline klient ühendus. Kattuvus on teine rikkerežiim. Kaugklient, mille kodune LAN kasutab juba 192.168.99.0/24, loeb lükatud marsruuti oma võrguna ja ükski serveripoolne muudatus ei kõrvalda seda mitmetähenduslikkust. Nummerdage üks pool ümber või valige prefiks, mis tõenäoliselt ei kattu.

TUN-seade kannab IP-pakette, seega vaikeühenduse lisamine külalise sees ei muuda tunnelit Etherneti segmendiks koos host-only-adapteriga. TAP-sild on erinev disain oma klienditoe ja aadressiomandiga ning kahe kirjelduse segamine viib seadistusteni, mis ei lähene kunagi.

Kontrollige ja seejärel tehke see taaskäivitusele vastupidavaks

Testige ühte kahjutut teenust tavalisest kaugkliendist, kontrollige külalise tagasiteed ja kinnitage, et teenus, mida te ei lubanud, lükatakse tagasi, mitte ei ole aeglane.

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

Seejärel taaskäivitage VPN-teenus ja virtuaalmasina võrk ning korrake samu kolme kontrolli. Käsitsi lisatud marsruut püsib järgmise taaskäivituseni ja seadistus, mis töötab ainult soojas sessioonis, ei ole disain. Kirjutage kaks prefiksit, edastuspoliitika ja külalise marsruut koos üles. Kes lisab järgmise virtuaalmasina, vajab kõiki kolme ja muidu avastab need uuesti ühe ebaõnnestunud ühenduse kaupa.