Limitați un listener VPN la interfețele la care vă refereați
Un listener wildcard și o regulă de firewall sunt controale diferite. Citiți socketurile reale cu ss, apoi verificați familia de adrese și firewallul.
Un serviciu VPN este accesibil de oriunde socketul său este legat și firewallul său permite. Sunt două decizii separate, iar oamenii de obicei iau doar una dintre ele. Citirea listenerului real durează zece secunde și lămurește o întrebare pe care presupunerile nu o pot lămuri. Începeți de acolo, apoi schimbați un control pe rând.
Tot ce urmează presupune că puteți executa comenzi pe gazdă cu root sau sudo.
Citiți socketurile înainte de a schimba ceva
Pe Linux, ss -lunp listează listenerii UDP cu adresa locală, portul și procesul lor, iar ss -ltnp face același lucru pentru TCP. Căutați portul VPN și citiți cu atenție coloana adresei. 0.0.0.0:51820 și [::]:51820 înseamnă fiecare interfață, în timp ce 10.0.0.5:51820 înseamnă o adresă pe o interfață. Manualul ss documentează coloanele dacă ieșirea nu vă este familiară. Dacă numele procesului lipsește, rulați aceeași comandă cu sudo, deoarece coloana proprietarului necesită privilegii.
Notați adresa. Este faptul de care depinde restul acestui ghid.
Legați-vă de o adresă, nu de o dorință
OpenVPN leagă listenerul de o adresă specifică prin directiva local, iar acesta este modul acceptat de a-l restrânge la nivel de proces. Nu fiecare implementare oferă un echivalent, iar un protocol fără opțiune de legare nu poate fi îngustat astfel. Dacă al dumneavoastră nu are niciuna, firewallul este singurul control, iar notele de implementare ar trebui să spună clar acest lucru. Pe o gazdă cu mai multe adrese, legați-vă de cea care privește spre tunel; legarea de o adresă flotantă este de obicei o greșeală.
Un serviciu care trebuie să supraviețuiască unei schimbări de adresă are nevoie de un plan pentru legarea învechită, nu doar de o linie de configurare.
Verificați familia de adrese separat
IPv4 și IPv6 sunt socketuri separate. Un proces legat de 0.0.0.0 poate accepta în continuare IPv6 printr-un socket cu stivă dublă, sau nu, în funcție de opțiunea socketului și de valoarea implicită a platformei. Citirea doar a liniei IPv4 a înșelat mai mult de o revizuire de implementare. Enumerați ambele familii înainte de a concluziona că listenerul este îngust.
Dacă IPv6 nu face parte din proiectare, dezactivarea lui la nivel de socket este mai curată decât speranța că firewallul îl acoperă. Este o decizie de politică, așa că înregistrați-o împreună cu restul alegerilor de interfață.
Suprapuneți firewallul peste legare
O legare îngustă nu înlocuiește o regulă de firewall, iar o regulă de firewall nu îngustează o legare wildcard. Folosiți ambele: legați-vă acolo unde implementarea o acceptă, apoi permiteți portul doar din sursele care ar trebui să ajungă la el. Grupurile de securitate din cloud stau în fața firewallului gazdei, așa că verificați ambele când calea traversează o frontieră VPC. Regula efectivă este intersecția celor două, iar fiecare strat poate doar să scadă accesibilitatea.
Testați dintr-o sursă permisă și dintr-una exclusă în mod deliberat. O conexiune din localhost nu demonstrează nimic despre granița publică.
Înregistrați ce ați ales
Notați adresa legată, interfața care o deține, regula de firewall și scopul ei. O placă NIC de schimb sau o adresă cloud realocată pot schimba expunerea fără ca cineva să editeze profilul. Datați nota, deoarece adresele cloud se mută între revizuiri mai des decât se așteaptă oamenii.
Acea notă face din următoarea revizuire o comparație în loc de un proiect de arheologie.