Zona VPN din OpenWrt, redirecționare și mascare: ce vă trebuie?

Trei modificări se amestecă de fiecare dată când o VPN întâlnește OpenWrt: deschiderea unui port, permiterea redirecționării și activarea mascarării. Ele răspund la întrebări diferite, iar de obicei doar una dintre ele este cerința reală. Citirea fiecărui control după rolul de trafic pe care îl guvernează transformă o presupunere într-o decizie și vă spune și ce simptom să așteptați când modificarea este greșită. Începeți prin a numi rolul care a eșuat, nu căsuța pe care o țineți minte.

Numiți rolul traficului înainte de a atinge un control

Intrarea zonei decide ce poate ajunge la routerul însuși. Ieșirea zonei acoperă traficul pe care routerul îl generează, redirecționarea zonei este valoarea implicită pentru traficul care traversează o zonă, iar mascarea decide dacă adresa sursă este rescrisă la ieșire. Sunt patru întrebări diferite, iar o politică de zonă răspunde la toate deodată cu aceeași valoare, de aceea o modificare la nivelul întregii zone este un instrument grosier. O regulă numită poate răspunde la una dintre ele fără a le atinge pe celelalte.

Harta utilă este după rolul traficului, pentru că exact asta puteți observa când ceva eșuează. Fiecare rol de mai jos are un control care îl decide și un simptom care indică spre el:

Un serviciu care ascultă pe router are nevoie de o singură regulă de intrare îngustă

Un server OpenVPN pe router primește trafic adresat routerului, așa că legătura sa exterioară depinde de politica de intrare a zonei care îl transportă. Permiteți transportul și portul configurate și lăsați tot restul din acea zonă respins. O singură regulă de port este o modificare mult mai mică decât o acceptare la nivelul întregii zone, și este cea pe care o veți putea explica și după un an.

Două lucruri fac acea regulă sigură de păstrat: numește portul pe care serviciul îl folosește efectiv și stă lângă definiția zonei, astfel încât următoarea persoană să vadă de ce există. Liniile de mai jos sunt forma, iar portul ține locul a ceea ce este configurat pe server. Schimbați acel port în ambele locuri când serviciul se mută, pentru că o regulă rămasă pe cel vechi este invizibilă până la un audit.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Validați înainte de reîncărcare, pentru că o eroare de sintaxă într-un fișier de firewall poate lăsa routerul fără un set de reguli funcțional. Într-o versiune care folosește fw4 verificarea este o comandă separată și eșuează zgomotos în loc să accepte în silință un bloc rupt. Reîncărcați doar după ce verificarea trece și păstrați fișierul anterior acolo unde îl puteți pune la loc.

fw4 check
service firewall reload

Cererea unui client trece prin redirecționare, nu prin intrare

După autentificare, cererea unui client de tunel pentru un serviciu din LAN produce un flux redirecționat, așa că controlul care o decide este relația de redirecționare dintre zona tunelului și zona LAN. Atribuiți interfața tunelului zonei dorite, apoi declarați direcția, sursele și serviciul. Atribuirea zonei este cea care dă sens regulii de redirecționare, iar cele două se înțeleg doar citite împreună. O relație de redirecționare care numește zona tunelului drept sursă și zona LAN drept destinație se citește ca o singură decizie deliberată, în timp ce două acceptări la nivelul întregii zone se citesc ca un accident.

A ajunge la routerul însuși folosește în continuare calea de intrare, de aceea un ping către gateway nu spune nimic despre partajarea de fișiere din spatele lui. Acele două eșecuri trăiesc în blocuri diferite și se repară cu modificări diferite. Scrieți ambele căi separat înainte de a o schimba pe oricare.

Mascarea este o decizie de rutare, nu o permisiune

Mascarea rescrie adresa sursă a traficului de ieșire selectat. Poate salva un proiect de ieșire în care partea îndepărtată nu are rută de întoarcere și ascunde, de asemenea, adresele clienților individuali de orice serviciu care înregistrează sau autorizează după adresă. Dezactivarea ei este o alegere de rutare privind calea de întoarcere, nu un comutator de securitate care închide o gaură de intrare. Un tunel care funcționează cu traducerea activă și eșuează în momentul în care aceasta este dezactivată are de obicei o rută de întoarcere lipsă, nu o regulă de firewall lipsă.

Alternativa rutată are nevoie de o rută de întoarcere la partea îndepărtată în loc de traducere. Niciuna dintre opțiuni nu oferă permisiunea firewall sau contul aplicației, de aceea dezactivarea mascarării aproape niciodată nu repară un client de tunel care nu ajunge nicăieri. Tratați separat și politica IPv4 și IPv6, deoarece o singură setare de traducere nu descrie ambele familii.

Dovediți decizia cu o cerere permisă și una respinsă

Trimiteți o cerere care ar trebui permisă și una care ar trebui respinsă, apoi identificați controlul care a luat fiecare decizie. O pagină care se încarcă din întâmplare nu este dovadă; dovada este regula care s-a potrivit, în lanțul în care s-a potrivit. Respingerea contează la fel de mult ca succesul, pentru că arată că politica face ceva în loc ca totul să fie permis.

Două comenzi vă dau acea dovadă într-o versiune actuală. Contorul regulii potrivite se mișcă atunci când cererea este acceptată, iar jurnalul arată eliminarea dacă ați activat înregistrarea pentru regulă:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Păstrați o cale de administrare pe care o mai puteți folosi înainte de a schimba orice politică de firewall și urmați procesul de validare și revenire al proprietarului configurației. O modificare care vă încuie în afara routerului nu este un rezultat de test, este un al doilea incident. Notați zona și rolul traficului lângă fiecare observație, astfel încât perechea de rezultate să explice politica în loc să descrie o încărcare norocoasă de pagină.