Blochează un client OpenVPN din LAN fără a opri tunelul

Un client de pe serverul tău OpenVPN trebuie să piardă accesul la LAN în timp ce toate celelalte tuneluri rămân active. Dacă cauți asta, cel mai bun răspuns spune de obicei că daemonul nu poate, ceea ce este doar pe jumătate adevărat: OpenVPN nu are firewall pe client, dar gazda care termină tunelul filtrează deja pachete. Cele două decizii care contează sunt identitatea pe care o blochezi și poziția regulii. Fă-le corect și schimbarea devine o singură linie pe care o poți testa și elimina.

Fixează clientul înainte de a scrie regula

OpenVPN închiriază adrese de tunel dintr-un pool, așa că 10.8.0.6 este un loc, nu o persoană. Când sesiunea se termină, închirierea revine și poate fi dată următoarei conexiuni, ceea ce înseamnă că o regulă scrisă împotriva acelei adrese urmează locul, nu utilizatorul. Decide mai întâi ce blochezi de fapt: o adresă pentru un experiment scurt sau un certificat pentru cineva pe care vrei să-l ții afară.

Pentru a lega adresa de certificat, creează un fișier în directorul indicat de client-config-dir și dă fișierului exact common name al certificatului. Pune în el o directivă, ifconfig-push 10.8.0.6 255.255.255.0, iar acel client păstrează aceeași adresă de tunel la reconectări. Trebuie să existe două setări pentru ca asta să funcționeze: client-config-dir trebuie declarat în configurația serverului, iar adresa trimisă trebuie să fie într-o subrețea pe care serverul o poate ruta. Dacă lipsește una, fișierul este ignorat fără eroare, ceea ce face următorul test de firewall înșelător.

O blocare temporară poate folosi o adresă din pool, atât timp cât tichetul notează ce sesiune o deținea la momentul respectiv.

Ordinea decide dacă aruncarea rulează

Pe un gateway Linux care transmite între tunel și LAN, pachetele trec prin lanțul FORWARD. Citește comanda de mai jos ca pe o propoziție: inserează în capul lui FORWARD, potrivește traficul care intră din tun0, de la acea singură gazdă, adresat subrețelei LAN, și aruncă-l.

iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP

-I este ceea ce face regula să ruleze. Adăugată cu -A, ajunge sub orice acceptare largă pentru subrețeaua tunelului și nu vede niciodată un pachet. Verifică poziția cu iptables -vnL FORWARD --line-numbers și citește și contoarele: o aruncare în cap care nu numără nimic înseamnă că traficul vine pe altă cale.

Adresa LAN proprie a gateway-ului este altă cale. Pachetele trimise către cutie merg în INPUT, nu în FORWARD, așa că un client poate pierde o gazdă din LAN și totuși să deschidă pagina de administrare a routerului. Adaugă regula INPUT corespunzătoare când contează.

Ce nu poate vedea filtrul

Filtrarea are loc când un pachet este evaluat, așa că o sesiune TCP stabilită poate continua până se închide sau este resetată. Dacă blocarea trebuie să muște imediat, curăță fluxurile urmărite pentru acea sursă cu conntrack -D -s 10.8.0.6 după ce regula intră. Dacă câteva secunde de suprapunere sunt acceptabile, notează acea alegere în loc să o lași implicită. În orice caz, următoarea persoană trebuie să știe dacă regula oprește traficul viu sau doar conexiunile noi.

Traficul între parteneri nu atinge niciodată firewall-ul gazdei. Cu client-to-client activat, OpenVPN transmite acele pachete în interiorul daemonului, așa că nici FORWARD nici INPUT nu le văd. Singurele soluții sunt oprirea client-to-client sau acceptarea faptului că partenerii se pot atinge; o regulă iptables nu va vedea acel trafic.

IPv6, firmware și supraviețuirea după repornire

O regulă IPv4 nu spune nimic despre IPv6. Dacă tunelul și LAN-ul transportă ambele familii, regula echivalentă trebuie să existe în ip6tables, sau în setul de reguli nftables care deține politica pe acea gazdă. Firmware-ul routerului ascunde adesea netfilter în spatele propriei abstracții, așa că sintaxa și numele tabelelor copiate de pe un forum pot să nu se aplice.

Pe OpenWrt, calea documentată este o intrare de configurare a firewall-ului și nu o linie iptables scrisă de mână, iar o linie scrisă de mână poate dispărea când firewall-ul se reîncarcă. Alte distribuții restaurează regulile prin netfilter-persistent, o unitate de pornire sau un depozit al producătorului, iar aceste mecanisme nu sunt interschimbabile. Dovedește-l pe cel ales cu o repornire, pentru că o reîncărcare exersează altă cale.

Verifică pe cale, apoi revino curat

Testează fiecare cale separat, pentru că o verificare reușită le ascunde pe celelalte. Un client blocat ar trebui să ajungă în continuare la internet prin tunel, dar să eșueze către o gazdă LAN, un al doilea client ar trebui să ajungă la aceeași gazdă, iar adresa gateway-ului și calea către partener au nevoie fiecare de propria observație. Scrie rezultatele lângă regulă ca următoarea schimbare să aibă o bază. Tabelul de mai jos este setul care merită păstrat în tichet.

Revenirea este o ștergere după specificație, nu un flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP elimină exact acea intrare și lasă restul lanțului intact. Elimină aceeași linie din fișierul care restaurează regulile la pornire, reîncarcă-l și confirmă că clientul ajunge din nou la gazda LAN. Un flush al lui FORWARD ar anula și reguli pe care nu le-ai scris, ceea ce transformă o revenire într-un al doilea incident.

Înainte de a închide tichetul, confirmă trei lucruri: adresa fixată corespunde certificatului, regula stă deasupra acceptărilor cu un contor diferit de zero, iar fișierul de persistență conține aceeași regulă pe care ai testat-o. Dacă lipsește ceva, blocarea este o iluzie într-o sesiune shell.