Opriți clienții VPN să se atingă unul pe altul în tunel

Doi clienți pot deschide amândoi gazda de salt și totuși să nu aibă nimic de-a face cu a se deschide unul pe altul. A ajunge la un serviciu este o decizie de forwarding, în timp ce a ajunge la o pereche este o decizie de politică, iar majoritatea stivelor VPN le țin în obiecte separate. Nimic din ce configurați pentru prima nu o impune pe a doua. Prin urmare, sarcina nu este să adăugați o regulă, ci să găsiți obiectul care decide traficul între perechi pe acest server, să scrieți refuzul acolo și să îl demonstrați dintr-un client.

O rută către serviciul partajat nu este o permisiune între perechi

Anunțarea subrețelei clienților spune unei perechi cum să pună un pachet pe fir către adresa altui client. Dacă pachetul este livrat se decide după aceea, de ceea ce îl trimite mai departe. Pe o poartă Linux este lanțul FORWARD; într-un daemon din spațiul utilizator este tabelul propriu de sesiuni al tunelului. O rută răspunde la accesibilitate și lasă permisiunea neatinsă.

De aceea o verificare de izolare care citește doar rute nu demonstrează nimic. Un /24 poate fi împins la fiecare client în timp ce fiecare pachet între perechi este aruncat la cârligul de forwarding. Cazul periculos este inversul: nicio regulă explicită, o valoare implicită permisivă și o izolare care există doar pentru că nimeni nu a testat-o.

Scrieți cerința pe o singură linie înainte de a deschide un terminal. Ajungeți la blocul de servicii și la gazda de salt, nu ajungeți la nimic altceva în interiorul blocului de clienți.

Aflați cine trimite mai departe pachetul perechii

Două comportamente ale serverului arată la fel din partea clientului și cer reguli diferite. Fie nucleul trimite din nou pachetul afară din interfața tunelului, fie daemonul îl copiază între sesiuni și nucleul nu îl vede niciodată.

WireGuard face parte din primul grup: nu are comutator între perechi, așa că un pachet de la 10.8.0.4 la 10.8.0.5 ajunge pe wg0, lovește cârligul de forwarding și este rutat din nou afară din wg0 când AllowedIPs acoperă ambele adrese. OpenVPN este al doilea grup de îndată ce client-to-client este setat în configurația serverului, pentru că acea directivă predă pachetul între sesiuni în spațiul utilizator. Verificați configurația încărcată pentru acea directivă înainte de a scrie ceva. O regulă de nucleu care nu vede niciodată trafic nu poate fi distinsă de o regulă care funcționează, și așa se termină o implementare fără nicio izolare.

Citiți configurația efectivă, nu fișierul pe care presupuneți că este încărcat, pentru că pachetele distribuțiilor aduc propriile incluziuni. Dacă daemonul face forwarding, refuzul aparține controalelor sale pe client, iar un firewall al gazdei filtrează doar traficul adresat gazdei. Dacă nucleul face forwarding, cârligul de forwarding este singurul loc care contează.

Implementările rutate și traduse au nevoie de încă o verificare: sursa pe care o vede un client îndepărtat poate să nu fie cea așteptată. Atunci o regulă care se potrivește cu subrețeaua clienților nu se potrivește cu nimic. Notați adresa care supraviețuiește traducerii înainte de a scrie potrivirea și preferați să potriviți perechea de interfețe în loc să ghiciți adrese NAT.

Dați fiecărei adrese o identitate care poate fi revocată singură

Izolarea se prăbușește de îndată ce două dispozitive împart o singură acreditare. O regulă legată de acea identitate nu le poate separa, iar revocarea unui laptop pierdut revocă tot grupul. Certificate per dispozitiv sau chei per pereche țin revocarea locală și politica lizibilă, pentru că fiecare adresă corespunde exact unei persoane sau mașini. Acolo unde proiectul nu poate face asta, spuneți-o în manualul de operare în loc să descrieți regula ca fină.

Alocarea adreselor trebuie să fie de acord cu politica. Rezervați un bloc pentru servicii, un bloc pentru clienți, și distribuiți adrese de clienți dintr-un pool pe care îl controlați, nu dintr-un interval primul-venit-primul-servit. Dacă serverul traduce sau face punte, țineți tabelul de mapare lângă configurație, pentru că acel tabel este ce are nevoie următorul cititor ca să rederive regula.

Puneți refuzul acolo unde pachetul traversează tunelul

Pe o poartă care face forwarding pentru traficul WireGuard, două reguli acoperă cazul: permiteți blocul de servicii, apoi aruncați restul blocului de clienți. Perechea de interfețe contează la fel de mult ca adresele, pentru că potrivirea doar pe destinație prinde și traficul venit din LAN. Încărcați-le în această ordine ca permisiunea să fie evaluată prima.

Cu nftables perechea intră într-un tabel inet filter existent, permisiunea mai întâi și aruncarea apoi. Ambele potriviri fixează perechea de interfețe și adresele.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Citiți lanțul înapoi după încărcare în loc să vă bazați pe starea de ieșire, și confirmați că ambele reguli stau în ordinea dorită. Adăugați reguli ip6 potrivite pentru pool-ul IPv6, altfel perechea v4 este doar decor pe un tunel cu două stive. Dacă serverul are deja o politică de forwarding permisivă, adăugați aruncarea în loc să înlocuiți lanțul în întregime.

Când client-to-client este activat pe OpenVPN, aceste reguli de forwarding nu se potrivesc niciodată cu traficul între perechi și refuzul trebuie să trăiască în controalele proprii ale daemonului. Păstrați regulile de nucleu pentru traficul adresat gazdei, dar nu le socotiți drept controlul de izolare.

Demonstrați refuzul dintr-un client, nu de pe server

Testarea de pe poartă nu demonstrează nimic, pentru că traficul generat local ia calea de ieșire și nu traversează niciodată cârligul de forwarding. Folosiți doi clienți reali: unul care ar trebui să ajungă la serviciu și unul care ar trebui refuzat. Rulați mai întâi cazul permis, ca un tunel rupt să nu fie luat drept politică funcțională.

Din clientul permis, confirmați că serviciul răspunde pe portul său. Din același client, încercați adresa perechii și așteptați o aruncare silențioasă în loc de un refuz:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

Un pachet aruncat și o pereche offline arată amândouă ca un timeout, așa că verificați contoarele înainte de a concluziona ceva. Confirmați că numărătorul regulii de aruncare crește în timp ce perechea este dovedit activă. Repetați pe IPv6, unde o regulă ip6 lipsă lasă refuzul v4 să pară eficient. Notați rezultatele acceptate și refuzate în manual cu data, pentru că următoarea migrare va rederiva regula.