Rutează o subrețea LAN prin OpenVPN și păstrează ruta implicită

Păstrează ruta implicită a LAN-ului în timp ce o subrețea trece prin tunel. Compară un tabel de politici cu modificări în tabelul principal, apoi alege NAT sau o rută pe partea serverului.

Mașinile care rutează pentru un LAN și, în același timp, formează un VPN ajung în aceeași dispută cu ele însele: tunelul vrea să dețină ruta implicită, iar LAN-ul are nevoie de ea înapoi. Când OpenVPN se conectează, poate instala o rută implicită prin tunel sau o pereche de jumătăți de rute implicite, ceea ce este corect pentru un laptop și greșit pentru o poartă ai cărei vecini așteaptă răspunsuri de la adresa sa LAN. Răspunsul nu este să sari peste VPN. Răspunsul este să dai celor două decizii tabele diferite.

O rută implicită, doi proprietari

Traficul redirecționat și traficul originat local nu trebuie să urmeze aceeași cale. Clienții LAN au nevoie de tunel doar pentru destinațiile pe care le alegi, în timp ce sesiunile de administrare ale gazdei înseși și răspunsurile ei către acești clienți au nevoie de ruta implicită a LAN-ului. Amestecarea ambelor în tabelul principal impune un singur răspuns la două întrebări diferite.

OpenVPN are un comutator exact pentru asta. route-noexec împiedică clientul să atingă deloc tabelul principal, iar valorile pe care le-ar fi folosit sunt exportate către un script route-up ca route_vpn_gateway, dev și adresele interfeței. Apoi tu decizi ce tabel primește ce rută, în cod pe care îl poți citi mai târziu.

Tabel de politici versus rescrierea celui principal

ApproachWhat it buysWhat it costs
Separate table plus source ruleLAN traffic and host traffic keep independent defaultsEvery lookup now depends on rule order
Editing the main table onlyFewer moving parts on a single-purpose hostOne mistake takes the gateway offline entirely
Two half-default routesWorks for a full-tunnel clientAmbiguous on a host that must answer on its LAN address

Tabelul separat este singura opțiune care scalează dincolo de o subrețea. Dă-i un nume o dată, apoi referă-te la el după nume, ca nimeni să nu fie nevoit să țină minte un număr:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Adresele de aici sunt substituenți. Înlocuiește prefixul LAN, poarta tunelului și numele dispozitivului din propria implementare înainte de a rula ceva.

Regula trebuie să se potrivească și cu gazda

O regulă care se potrivește doar cu prefixul LAN acoperă pachetele redirecționate. Nu acoperă traficul pe care poarta însăși îl originează, nici răspunsurile pe care le trimite înapoi clienților LAN, care poartă adresa LAN a porții ca sursă. Acele căutări cad în main și pot încă ieși prin tunel.

Adaugă o a doua regulă pentru adresa LAN proprie a porții sau lărgește prima regulă la o mulțime care le include pe amândouă. Ordinea contează: pune prima regula mai specifică și verifică rezultatul cu o căutare care numește sursa în mod explicit.

ip route get 203.0.113.9 from 192.168.50.1

Dacă asta raportează dispozitivul tunelului pentru o destinație care ar trebui să rămână locală, setul de reguli este greșit indiferent de ce conține tabelul.

NAT sau o rută pe partea cealaltă

Serverul VPN cunoaște subrețeaua tunelului și nimic altceva. Pachetele care sosesc cu o adresă de sursă LAN nu au cale de întoarcere decât dacă cineva o asigură, și există exact două moduri de a o asigura. Adăugarea unei rute pentru prefixul LAN pe server păstrează sursa originală vizibilă de la un capăt la altul, ceea ce un design auditat vrea de obicei. Mascarea pe poartă rescrie sursa la adresa tunelului și nu are nevoie de nicio cooperare din partea serverului.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Alege NAT când nu controlezi serverul și nu poți adăuga rute acolo. Alege ruta pe partea serverului când contează jurnalele, controlul accesului sau simetria căii de întoarcere, pentru că mascarea șterge adresa originală din tot ce înregistrează partea cealaltă.

În orice caz, redirecționarea trebuie activată, iar filtrarea strictă a căii inverse poate arunca răspunsul când main nu ar fi ales tunelul pentru acea sursă. Verifică valoarea efectivă înainte de a da vina pe tunel.

Fă ca divizarea să supraviețuiască unei reconectări

Regulile și rutele adăugate manual dispar când interfața este recreată, iar o intrare veche în tabel poate supraviețui sesiunii care a justificat-o. Pune regula tabelului, ruta tunelului și intrarea de mascare în scriptul route-up al clientului și golește tabelul la începutul scriptului, ca o poartă veche să nu poată supraviețui în sesiunea nouă.

Verifică de la ambele capete: o căutare pe poartă cu sursa LAN și o cerere reală de la un client LAN către o destinație care trebuie să treacă prin tunel. O rută care există dar nu este niciodată selectată se comportă exact ca nicio rută, până când citești contoarele.

Articole similare