Rutarea traficului VM din rețeaua host-only printr-un server TUN OpenVPN

Țineți tunelul și prefixul host-only separate, împingeți ruta oaspetelui, apoi dați fiecărei mașini virtuale o cale de întoarcere deliberată prin gazdă.

Adaptoarele host-only creează o rețea virtuală locală, iar tunelurile TUN rutate transportă pachete IP între adrese. Niciunul nu este o punte către celălalt, de aceea o configurație funcțională trebuie să spună cine redirecționează și cui aparține ruta de întoarcere. Dacă aceste două atribuiri sunt inversate, oaspetele răspunde tunelului cu o sursă pe care clientul tunelului nu a cerut-o niciodată. Designul de mai jos păstrează ambele prefixe separate și face calea de întoarcere explicită.

Două rețele, două prefixe

Dați pool-ului tunelului și rețelei host-only prefixe diferite și nu reutilizați niciodată unul pentru celălalt. În acest exemplu pool-ul VPN este 10.44.0.0/24, iar rețeaua host-only este 192.168.99.0/24, cu gazda la 192.168.99.1 și un oaspete la 192.168.99.20. Atribuirea aceluiași prefix atât unui dispozitiv TUN, cât și adaptorului host-only nu le unește. Creează două pretenții asupra unui interval de adrese, iar tabela de rutare răspunde apoi pentru pretenția pe care a păstrat-o din întâmplare.

Adaptorul host-only există pe gazdă și în interiorul oaspetelui, și nu are de unul singur o cale în afara mașinii. Conexiunile în punte și NAT au o expunere diferită, iar trecerea în modul punte nu este o condiție pentru a ajunge la un singur serviciu al oaspetelui.

Gazda deține deja calea

Uitați-vă la ce există înainte de a adăuga ceva. Gazda are o interfață în rețeaua host-only și o rută pentru acel prefix, ambele create când adaptorul a pornit.

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

A treia linie este mecanismul care transformă gazda într-un salt. Fără el, un pachet care sosește din tunel este adresat unei rețele pe care gazda o poate atinge, dar nu o va redirecționa. Redirecționarea este necesară și nu suficientă. Politica de filtrare decide în continuare dacă un anumit flux între interfața tunelului și interfața host-only este permis, iar acea decizie trebuie să fie scrisă, nu într-o politică implicită pe care nimeni nu a citit-o.

Împingeți ruta, apoi filtrați ce atinge

Serverul poate furniza prefixul host-only clienților care acceptă rute împinse, ceea ce este același mecanism folosit pentru orice altă subrețea din spatele tunelului.

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

Aceste două reguli permit un singur serviciu într-o direcție și răspunsurile lui. O rută care atinge întregul prefix și un filtru care permite un singur port sunt o combinație deliberată; o rută plus o acceptare necondiționată este felul în care un serviciu de laborator devine un serviciu expus. O rută împinsă nu este nici autorizare. Clientul o acceptă, gazda o redirecționează, iar firewall-ul oaspetelui și serviciul însuși încă au un cuvânt de spus.

Oaspetele are nevoie de o cale de întoarcere

Un oaspete la care se ajunge din 10.44.0.x trebuie să-și trimită răspunsurile la adresa host-only a gazdei, sau gazda trebuie să traducă sursa. Primirea unei adrese de la DHCP-ul VirtualBox nu spune nimic despre niciuna dintre cele două aranjamente.

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

Adăugarea acelei rute în interiorul oaspetelui păstrează sursa originală, ceea ce menține semnificative politica și jurnalele pe client. Traducerea limitată a sursei pe gazdă este alternativa și funcționează, cu prețul de a ascunde care client s-a conectat. Suprapunerea este celălalt mod de eșec. Un client la distanță a cărui rețea LAN de acasă folosește deja 192.168.99.0/24 va citi ruta împinsă ca propria rețea, iar nicio modificare pe partea de server nu rezolvă acea ambiguitate. Renumeroți o parte sau alegeți un prefix care probabil nu se va ciocni.

Un dispozitiv TUN transportă pachete IP, așa că adăugarea unui gateway implicit în interiorul unui oaspete nu transformă tunelul într-un segment Ethernet cu adaptorul host-only. Puntea TAP este un design diferit, cu propriul suport pentru clienți și propria proprietate a adreselor, iar amestecarea celor două descrieri duce la configurații care nu converg niciodată.

Verificați, apoi faceți-l să supraviețuiască unei reporniri

Testați un serviciu inofensiv de la un client la distanță obișnuit, verificați ruta de întoarcere a oaspetelui și confirmați că un serviciu pe care nu l-ați permis este refuzat în loc să fie lent.

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

Apoi reporniți serviciul VPN și rețeaua mașinii virtuale și repetați aceleași trei verificări. O rută adăugată manual supraviețuiește până la următoarea repornire, iar o configurație care funcționează doar în sesiune caldă nu este un design. Notați împreună cele două prefixe, politica de redirecționare și ruta oaspetelui. Cine adaugă următoarea mașină virtuală va avea nevoie de toate trei și, altfel, le va redescoperi o conexiune eșuată după alta.

Articole similare