iptables: lăsați clienții VPN să ajungă doar la un singur host

Regula de care aveți nevoie este în FORWARD, nu în INPUT. Permiteți o singură destinație pentru grupul VPN, respingeți restul, apoi demonstrați-o cu contoare și o comandă de revenire.

Două tichete de suport care par fără legătură împart de fapt aceeași cauză. În primul, un administrator vrea ca serverul să accepte conexiuni doar din tunel; în al doilea, utilizatorii VPN ar trebui să ajungă la un singur host intern și la nimic altceva. Ambele politici aparțin de FORWARD, iar ambele sunt de obicei încercate în INPUT. Rezultatul arată ca un firewall și se comportă ca un substituent.

Care lanț răspunde la întrebarea dumneavoastră

Pachetele pe care un client VPN le trimite unui host din LAN, sau mai departe către internet, sunt redirecționate de nucleu și evaluate în FORWARD. INPUT și OUTPUT văd doar traficul care se termină pe serverul însuși sau care provine de acolo. Prin urmare, o respingere pentru tot ce nu sosește pe tun0 protejează ascultătorii proprii ai serverului și va închide și sesiunea SSH dacă fluxurile stabilite nu sunt admise mai întâi. Nu schimbă nimic în privința locurilor în care clienții au voie să meargă.

Numiți mai întâi întrebarea: cine poate ajunge la server sau încotro pot merge clienții. Majoritatea rețelelor au nevoie de ambele răspunsuri, în lanțuri diferite.

Mai întâi starea, apoi permisiunea, apoi refuzul

O listă de permisiuni funcționează doar dacă permisiunea specifică stă deasupra refuzului general și dacă traficul de retur este admis deasupra ambelor. Introduceți regulile în poziții explicite, apoi afișați lanțul cu iptables -S FORWARD ca ordinea să fie vizibilă, nu presupusă.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Două detalii decid dacă acest lucru supraviețuiește contactului cu trafic real. Fără regula de stare, răspunsurile la conexiunile tocmai permise sunt ele însele evaluate împotriva refuzului și eliminate. O regulă LOG fără limită poate umple o partiție mică la prima scanare care o atinge, așa că adăugați -m limit --limit 10/min înainte de a continua înregistrarea. REJECT returnează imediat o eroare, ceea ce este mai prietenos cât timp reglați lista; DROP aruncă în tăcere, așa că fiecare greșeală apare ca o expirare a timpului. Alegeți unul intenționat și scrieți alegerea în registrul de modificări.

Redirecționarea și NAT trebuie să funcționeze deja

Filtrarea nu poate dovedi că există o cale. Confirmați mai întâi că nucleul redirecționează deloc, și faceți această setare permanentă în loc de o comandă unică în shell. Filtrul este ultimul strat, nu primul.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Unde anume stă mascarea depinde de unde ies clienții. Dacă pleacă spre o rețea îndepărtată prin tunel, regula NAT se pune pe acea interfață, nu pe interfața WAN. Apoi urmăriți contoarele: dacă contorul POSTROUTING nu se mișcă niciodată în timp ce numărul de admiteri din FORWARD crește, calea de retur este ruptă, iar filtrul este în regulă. Această citire economisește o după-amiază de rescriere a unor reguli care nu au fost niciodată problema.

Blocul de poștă aparține unui lanț mai departe

Blocarea portului 25 în INPUT oprește doar poșta adresată serverului VPN. Un client compromis care trimite poștă prin tunel este redirecționat, așa că blocul trebuie să stea în FORWARD lângă 465 și 587. Dacă o aplicație retransmite poștă în mod legitim, puneți destinația și portul ei deasupra acelei reguli.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Lăsați contorul de respingeri să ruleze o săptămână înainte de a strânge orice altceva. Numărul care se oprește din creștere este fluxul legitim pe care tocmai l-ați rupt.

Recitiți totul, apoi demonstrați dintr-un client

Citiți setul de reguli așa cum îl raportează nucleul, nu așa cum l-a scris scriptul dumneavoastră. Începeți cu iptables -S FORWARD, apoi tabelul NAT cu iptables -t nat -L POSTROUTING -n -v, apoi intrarea conntrack pentru fluxul pe care îl testați. Țineți la îndemână o comandă de revenire sau o golire programată cât timp durează lucrarea. Fiecare apel are nevoie de -w, altfel doi administratori se vor ciocni pe blocajul xtables. Nimic din toate acestea nu este opțional într-o fereastră de modificări.

Încheiați testând dintr-un client din interiorul grupului și dintr-unul din afara lui. O regulă care funcționează doar de pe mașina pe care ați scris-o nu este o politică.

Articole similare