VM srauto maršrutizavimas host-only tinkle per TUN OpenVPN serverį

host-only adapteriai sukuria vietinį virtualų tinklą, o maršrutizuoti TUN tuneliai perneša IP paketus tarp adresų. Nė vienas nėra tiltas į kitą, todėl veikianti konfigūracija turi pasakyti, kas perduoda ir kam priklauso grįžimo maršrutas. Sumaišius šiuos du priskyrimus, svečias atsako tuneliui šaltiniu, kurio tunelio klientas niekada neprašė. Toliau pateiktas sprendimas laiko abu priešdėlius atskirai ir padaro grįžimo kelią aiškų.

Du tinklai, du priešdėliai

Duokite tunelio telkiniui ir host-only tinklui skirtingus priešdėlius ir niekada nenaudokite vieno vietoj kito. Šiame pavyzdyje VPN telkinys yra 10.44.0.0/24, o host-only tinklas yra 192.168.99.0/24, hostas yra 192.168.99.1, o svečias – 192.168.99.20. To paties priešdėlio priskyrimas ir TUN įrenginiui, ir host-only adapteriui jų nesujungia. Tai sukuria du reikalavimus vienam adresų diapazonui, o maršrutizavimo lentelė tada atsako už tą reikalavimą, kurį netyčia išlaikė.

host-only adapteris egzistuoja hoste ir svečio viduje, ir jis pats savaime neturi kelio iš mašinos. Tiltinės ir NAT jungtys turi skirtingą poveikį, o perėjimas į tiltinį režimą nėra sąlyga pasiekti vieną svečio paslaugą.

Hostas jau turi kelią

Pažiūrėkite, kas yra, prieš ką nors pridėdami. Hostas turi sąsają host-only tinkle ir maršrutą tam priešdėliui, abu sukurti adapteriui pakilus.

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

Trečioji eilutė yra mechanizmas, kuris hostą paverčia šuoliu. Be jo iš tunelio atėjęs paketas adresuojamas tinklui, kurį hostas gali pasiekti, bet nepersiųs. Persiuntimas būtinas ir nepakankamas. Filtravimo politika vis dar sprendžia, ar leidžiamas tam tikras srautas tarp tunelio sąsajos ir host-only sąsajos, ir tas sprendimas turi būti raštu, o ne numatytojoje politikoje, kurios niekas neskaitė.

Stumkite maršrutą, tada filtruokite, ką jis pasiekia

Serveris gali pateikti host-only priešdėlį klientams, kurie priima stumiamus maršrutus, ir tai tas pats mechanizmas, naudojamas bet kuriam kitam potinkliui už tunelio.

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

Šios dvi taisyklės leidžia vieną paslaugą viena kryptimi ir jos atsakymus. Maršrutas, pasiekiantis visą priešdėlį, ir filtras, leidžiantis vieną prievadą, yra sąmoninga kombinacija; maršrutas kartu su besąlyginiu priėmimu yra būdas, kuriuo laboratorijos paslauga tampa atskleista. Stumiamas maršrutas taip pat nėra įgaliojimas. Klientas jį priima, hostas jį persiunčia, o svečio ugniasienė ir pati paslauga vis dar turi žodį.

Svečiui reikia kelio atgal

Svečias, pasiekiamas iš 10.44.0.x, turi siųsti savo atsakymus į hosto host-only adresą, arba hostas turi išversti šaltinį. Adreso gavimas iš VirtualBox DHCP nieko nesako apie nė vieną iš šių dviejų išdėstymų.

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

To maršruto pridėjimas svečio viduje išsaugo pradinį šaltinį, o tai išlaiko prasmingą kiekvieno kliento politiką ir žurnalus. Ribotas šaltinio vertimas hoste yra alternatyva, ir ji veikia, bet kainuoja tai, kad paslepiama, kuris klientas prisijungė. Persidengimas yra kitas gedimo režimas. Nuotolinis klientas, kurio namų LAN jau naudoja 192.168.99.0/24, stumiamą maršrutą skaitys kaip savo tinklą, ir joks pakeitimas serverio pusėje neišsprendžia šio dviprasmiškumo. Pernumeruokite vieną pusę arba pasirinkite priešdėlį, kuris mažai tikėtina susidurs.

TUN įrenginys perneša IP paketus, todėl numatytojo šliuzo pridėjimas svečio viduje nepaverčia tunelio Ethernet segmentu su host-only adapteriu. TAP tiltas yra kitoks sprendimas su savo klientų palaikymu ir adresų nuosavybe, o abiejų aprašymų maišymas veda prie konfigūracijų, kurios niekada nesutampa.

Patikrinkite, tada padarykite, kad tai išgyventų perkrovimą

Išbandykite vieną nekenksmingą paslaugą iš įprasto nuotolinio kliento, patikrinkite svečio grįžimo maršrutą ir įsitikinkite, kad paslauga, kurios neleidote, atmetama, o ne lėta.

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

Tada iš naujo paleiskite VPN paslaugą ir virtualios mašinos tinklą ir pakartokite tuos pačius tris patikrinimus. Ranka pridėtas maršrutas išlieka iki kito perkrovimo, o konfigūracija, kuri veikia tik šiltoje sesijoje, nėra sprendimas. Užrašykite abu priešdėlius, persiuntimo politiką ir svečio maršrutą kartu. Kas pridės kitą virtualią mašiną, jam prireiks visų trijų, ir kitaip jis juos iš naujo atras po vieną nepavykusį ryšį.