Două clienturi OpenVPN pe un singur gateway Linux: împărțiți politica

Două demoni OpenVPN pot raporta amândoi un tunel reușit în timp ce gateway-ul trimite fiecare client prin același. Nimic din strângerea de mână nu decide ce tunel folosește un client; nucleul decide, pachet cu pachet, parcurgând regulile de politică și apoi tabelul pe care fiecare regulă îl numește. Privit așa, configurația încetează să mai fie despre opțiunile OpenVPN și devine o matrice de rutare cu doi proprietari.

Nucleul decide, nu demonul

Un pachet redirecționat ajunge pe interfața LAN și codul de rutare evaluează lista de reguli în ordinea priorității. Prima regulă al cărei selector se potrivește numește un tabel, iar rutele acelui tabel aleg dispozitivul de ieșire. Dacă tabelul nu are o rută potrivită, căutarea continuă la regula următoare, și exact acest detaliu face ca o configurație pe jumătate terminată să eșueze în liniște, nu zgomotos.

Procesul tunelului nu are niciun cuvânt în acea parcurgere. Creează o interfață și poate instala rute, dar dacă pachetul unui anumit client intră în acea interfață depinde în întregime de tabelul către care a fost trimis. De aceea două tuneluri cu rute importate identice concurează, iar ultimul care scrie câștigă pentru toți. De aceea o configurație poate părea echilibrată în fișiere și totuși trimite toți clienții printr-un singur demon.

Dați fiecărei instanțe propriul set de resurse

Începeți cu numele, pentru că numele reutilizate sunt modul în care cele două instanțe ajung să partajeze stare din greșeală. Atribuiți dispozitive de tunel distincte, fișiere de configurare distincte, credențiale distincte și unități de serviciu distincte. Notați punctul final exterior și adresa tunelului fiecărei instanțe în același tabel ca matricea de politică, ca o modificare ulterioară să aibă un singur loc de privit.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull ține rutele împinse de un server în afara tabelului local, și exact asta vreți când tabelele de politică ar trebui să fie explicite. Dacă un anumit server împinge și o opțiune redirect-gateway, și dacă versiunea dumneavoastră de client suportă forma cu filtru, merită verificat în manual în loc de presupus.

Scrieți matricea: sursă, tabel, dispozitiv

Pentru fiecare grup de clienți, adăugați o regulă care selectează un tabel după adresa sursă, apoi puneți calea dorită în acel tabel:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Tabelul are nevoie de rutele de destinație pe care grupul ar trebui să le aibă, plus orice excepții locale sau de administrare care mențin gateway-ul utilizabil. Un tabel care conține doar o rută implicită este o politică de tunel complet pentru acel grup, ceea ce poate fi exact corect, dar ar trebui să fie o decizie, nu o omisiune.

Transportul tunelului însuși nu este într-un grup de clienți

Pachetele criptate ale fiecărui demon se nasc pe gateway însuși, adresate partenerului exterior. O regulă care se potrivește doar cu un prefix de sursă de client lasă acele pachete în pace, și de aceea regulile limitate la sursă sunt mai sigure decât cele care se potrivesc cu tot. O regulă fără selector poate captura transportul tunelului însuși și îl poate trimite înapoi printr-un tunel, iar atunci conexiunea eșuează într-un mod care pare o problemă a furnizorului.

Țineți sesiunea de administrare locală și calea stratului inferior explicit în afara tabelelor de politică. Notați acele excepții lângă matrice; fac parte din proiectare, nu sunt o soluție de ocol care trebuie redescoperită în timpul unui incident.

Alegerea unei căi nu o permite

Permisiunea de redirecționare este o a doua decizie luată mai târziu pe cale. O regulă de firewall care acceptă pachete ce ies prin al doilea tunel nu face codul de rutare să îl aleagă, iar un tabel corect nu acordă permisiunea de a redirecționa. Ambele trebuie să existe, iar un test care dovedește doar una vă va induce în eroare cu privire la cealaltă. Când un grup funcționează și celălalt nu, verificați acești doi pași separat în loc să rescrieți tabelele.

Traducerea sursei este o a treia decizie și ar trebui limitată la grupul sursă și la dispozitivul de tunel care o poartă efectiv. Adăugați un lanț dedicat pentru cele două instanțe în loc să goliți lanțul postrouting, pentru că servicii nelegate pot avea intrări acolo, iar o golire le elimină în tăcere.

Ce se întâmplă când cade un tunel

Decideți comportamentul la eșec dinainte. Când un tabel de tunel își pierde ruta, căutarea cade la regula următoare, iar traficul grupului continuă prin celălalt tunel sau prin legătura superioară obișnuită fără nicio eroare. Dacă asta nu este acceptabil, adăugați o regulă terminală cu un număr de prioritate mai mic care returnează un rezultat inaccesibil pentru acea sursă, ca pierderea să fie vizibilă în loc să fie absorbită.

Trimiteți o cerere nouă din fiecare grup sursă și notați patru fapte: tabelul selectat, dispozitivul de ieșire, sursa tradusă și dacă răspunsul s-a întors pe aceeași cale. Apoi coborâți un tunel și repetați. Două dispozitive TUN într-o listă de interfețe dovedesc că ambele demoni au pornit; nu spun nimic despre care a fost folosit de un anumit client. A doua rulare, cu un tunel lipsă, este cea care arată dacă regula dumneavoastră de rezervă face ce intenționați.