Zone Shorewall pentru cele două căi ale pachetelor OpenVPN
Separați transportul OpenVPN criptat de traficul de client decriptat, dați tunelului propria zonă și permiteți doar serviciul de care are nevoie clientul.
Două fluxuri de pachete traversează o poartă Shorewall care termină OpenVPN, și doar unul dintre ele este criptat. Primul este transportul clientului către ascultătorul VPN de pe interfața orientată spre internet. Al doilea este cererea decriptată care părăsește interfața tunelului către un server de birou sau un serviciu de pe poartă. Desenați-le pe amândouă înainte de a edita politica, pentru că o regulă care îl satisface pe primul nu face nimic pentru al doilea.
Desenați cele două fluxuri înainte de a edita politica
Scrieți fluxurile ca rânduri cu sursă, destinație, protocol și port. Pe calea exterioară, sursa este adresa publică a clientului, iar destinația este portul de ascultare al porții; Shorewall tratează aceasta ca trafic de la internet la firewall. Pe calea interioară, sursa este intervalul de adrese al tunelului, iar destinația este serviciul aprobat. Cele două rânduri au proprietari diferiți chiar și atunci când un singur administrator le întreține pe amândouă.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
Adăugați un rând doar dacă cererea se termină pe poarta însăși, cum ar fi accesul la resolver sau la administrare. Un serviciu de pe gazdă urmează politica de intrare a gazdei, nu calea redirecționată. Amestecarea celor două este motivul pentru care o regulă îngustă de tunel ajunge să expună o interfață de administrare.
Atribuiți zona tunelului și sfera interfeței
Zona călătorului este declarată în /etc/shorewall/zones, interfața tunelului este atașată în /etc/shorewall/interfaces, iar conexiunea exterioară este descrisă în /etc/shorewall/tunnels. Adaptați-vă la sintaxa versiunii instalate, pentru că ordinea coloanelor și numele opțiunilor s-au schimbat între versiunile majore. Portul de exemplu din ghid nu este un motiv pentru a permite un port diferit de cel pe care demonul ascultă efectiv. TCP și UDP nu sunt interschimbabile doar pentru că numerele coincid.
Ghidul grupează interfețele cu tun+. Pe o gazdă cu mai mult de un tunel, acel metacaracter poate plasa un al doilea VPN cu alt nivel de încredere în aceeași zonă. Revizuiți sfera față de interfețele care există efectiv și țineți denumirea în ciclul de viață al managerului de conexiuni în loc să editați numele interfețelor manual.
Ghidul istoric conține exemple de configurare OpenVPN mult mai vechi, iar sfaturile sale criptografice nu trebuie copiate într-o implementare actuală. Împrumutați în schimb modelul de zone și fluxuri. Luați baza criptografică din politica OpenVPN întreținută a porții.
Permiteți doar calea pe care ați clasificat-o
O acceptare largă din zona VPN către LAN este o schiță de pornire, nu o politică terminată. Scrieți sursa de client permisă, adresa reală a serviciului, protocolul și portul. Apoi citiți regulile de deasupra și valoarea implicită a zonei, pentru că o adăugare îngustă nu anulează o permisiune largă care se potrivește deja. Traficul către gazda porții este o relație separată de traficul redirecționat prin ea.
Traficul între clienți are nevoie de propria decizie. client-to-client din OpenVPN și routeback din Shorewall afectează ambele dacă clienții se pot atinge, iar niciunul nu ar trebui activat doar pentru ca o aplicație LAN să funcționeze. Decideți unde se aplică izolarea înainte de a o testa.
Țineți calea de răspuns în același plan. Serviciul sau routerul său trebuie să știe cum să returneze traficul în intervalul tunelului, sau proiectarea trebuie să traducă sursa în mod deliberat și în sfera prevăzută.
Validați, apoi demonstrați ambele căi
Validați configurația înainte de a reporni orice și țineți deschisă o sesiune administrativă independentă în caz că noua politică este greșită.
shorewall checkDupă o verificare curată, aplicați configurația și recitiți ce a încărcat Shorewall. Aceste citiri descriu politica în execuție, nu ceea ce pare să spună un fișier.
shorewall show zones
ip route get 192.168.10.20Testați o cerere permisă nouă și o cerere refuzată intenționat de la același client. O strângere de mână OpenVPN reușită dovedește doar schimbul exterior; serviciul permis și resursa refuzată dovedesc politica interioară pe care o intenționați. Apoi reconectați clientul și repetați, pentru că numele și adresa interfeței tunelului se pot schimba între sesiuni. Dacă rezultatul diferă, corectați sfera zonei în loc să lărgiți regula.