Limitați un gateway OpenVPN la o singură rețea LAN cu reguli UFW

Decideți permisiunea înainte de a deschide un fișier de firewall: clienții autentificați pot deschide conexiuni către o singură subrețea anume, iar gateway-ul trebuie să respingă orice altă cale de tranzit chiar și atunci când un client instalează rute suplimentare. Acea propoziție este proiectul, iar fiecare regulă de mai jos există pentru a o impune. Ceva mai larg, cum ar fi întregul spațiu de adrese private, ieșirea în internet prin tunel sau traficul între egali, este un alt proiect care are nevoie de propria decizie. Regulile sunt, de asemenea, intenționat plictisitoare, pentru că un firewall deștept este acela pe care nimeni nu îl poate audita mai târziu.

Scrieți mai întâi topologia și permisiunea

Exemplul folosește un server Community OpenVPN cu un dispozitiv TUN în spațiul utilizatorului numit tun0, un bazin de clienți 10.77.0.0/24, și o subrețea conectată 192.168.60.0/24 pe lan0. Redirecționarea IPv4 funcționează deja, iar LAN-ul are deja o rută de întoarcere către bazin, așa că nimic de aici nu depinde de traducerea între ele.

Firewall-ul de pe acest host aparține UFW, iar niciun set de reguli de container și nicio tabelă nftables separată nu poate instala o cale de acceptare anterioară. O scurtătură de descărcare a fluxului care sare peste filtru ar face lanțurile de pază decorative, așa că confirmați că niciuna nu este activă. Lăsați redirecționarea client-to-client proprie a OpenVPN dezactivată, pentru că traficul între egali care nu traversează niciodată filtrul sistemului de operare nu poate fi limitat cu ea. Ascultătorul extern și regulile de administrare rămân așa cum sunt, deoarece această schimbare guvernează traficul decriptat al tunelului în loc să înlocuiască firewall-ul.

Puneți paznicii înaintea acceptărilor timpurii ale UFW

O permisiune de rută urmată de o respingere nu este suficientă pentru o graniță strictă. Regulile before standard acceptă traficul stabilit și anumite ICMP înainte ca vreo regulă de utilizator să fie consultată, așa că un flux permis săptămâna trecută poate rămâne în afara noii restricții de destinație doar pentru că încă are stare. Faceți o copie de siguranță a fișierelor UFW și țineți o consolă în afara benzii deschisă înainte de editare.

În secțiunea *filter a fișierului /etc/ufw/before.rules, declarați două lanțuri lângă declarațiile existente și înaintea oricărei linii de regulă.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Imediat după declarații, și înaintea permisiunilor de intrare și redirecționare, săriți în ele și definiți ce admit.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Păstrați restul secțiunii și linia COMMIT a acesteia. Inserarea unei a doua tabele de filtru sau ștergerea unor reguli nelegate este modul în care o schimbare de firewall devine o întrerupere, iar fișierul este la un singur restart de a fi singura copie care contează.

Citiți ce admite și ce refuză fiecare paznic

Primul lanț continuă procesarea doar când sursa este în bazin, destinația este singura subrețea, interfața de ieșire este LAN-ul și pachetul călătorește în direcția originală a fluxului său. Orice altceva care vine din tunel este aruncat, inclusiv o sursă din afara bazinului și orice destinație dincolo de subrețeaua permisă.

Un pachet între egali intră și iese prin tun0, deci eșuează testul de interfață LAN chiar înainte de a se ajunge la o verificare a destinației. Conexiunile noi din LAN către clienți eșuează și ele testul direcției de răspuns, ceea ce închide implicit calea inversă de apelare.

Ținta RETURN menține politica UFW obișnuită în joc. Aceste lanțuri filtrează, iar permisiunea de rută pe care o adăugați apoi decide în continuare dacă un pachet supraviețuitor este acceptat. Tocmai acea separare vă permite să schimbați mai târziu subrețeaua permisă într-un singur loc. Dacă paznicii ar accepta pachetele direct, fiecare regulă viitoare ar trebui adăugată de două ori.

Autorizați subrețeaua și închideți ușile laterale

Previzualizați mai întâi permisiunea de rută, apoi scoateți steagul de previzualizare pentru a o aplica: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. După aceea, revizuiți ordinea regulilor de utilizator, pentru că o respingere anterioară învinge în continuare o permisiune ulterioară. O permisiune pentru întreaga subrețea este și forma greșită când doar portul HTTPS al unui singur host ar trebui să fie accesibil.

Observați ce face aruncarea intrării: clienții tunelului nu pot ajunge la niciun serviciu pe gateway-ul însuși, inclusiv un ascultător DNS legat de adresa sa din LAN. Găzduirea DNS acolo necesită o excepție deliberată înainte de aruncare și un contract de permisiune revizuit. Dacă UFW administrează IPv6, adăugați aruncări corespunzătoare și pentru tun0 în before6.rules, pentru că o listă de destinații IPv4 nu spune nimic despre pachetele IPv6.

Verificați politica încărcată, nu previzualizarea

Previzualizați reîncărcarea, aplicați-o într-o fereastră de mentenanță și citiți setul de reguli activ.

sudo ufw --dry-run reload
sudo ufw show raw

Confirmați că paznicii tunelului apar înaintea permisiunilor implicite de stare și ICMP. Un ufw status simplu nu afișează regulile before editate manual, motiv pentru care operatorii concluzionează că lipsește o regulă atunci când ea este de fapt încărcată. Citiți listarea brută de sus în jos în loc să căutați un fragment. Dacă paznicii apar după o permisiune de stare, granița nu face ceea ce sugerează fișierul.

Apoi testați comportamentul, nu textul. Deschideți o conexiune nouă către un host permis și urmăriți răspunsul, direcționați o cerere inofensivă către o destinație din afara subrețelei și confirmați că moare, încercați o conexiune între egali, încercați un serviciu local gateway-ului și încercați o conexiune nesolicitată din LAN către un client. Includeți un flux din afara ariei care exista înainte de schimbare și ștergeți doar acel flux în loc să goliți întreaga tabelă de urmărire a mașinii.

Notați limitele lângă reguli: aceasta limitează tranzitul și nimic altceva. Nu împiedică un client să își folosească propria conexiune la internet, nu împiedică un host LAN permis să retransmită trafic mai departe și nu înlocuiește autentificarea din interiorul serviciilor permise.