Clienții LAN ignoră VPN-ul routerului până se activează rutarea pe politici

Routerul ajunge la internet prin tunelul său, în timp ce laptopul din spate încă raportează adresa ISP. Adăugarea de reguli de acceptare nu ajută, iar acest eșec este instructiv: filtrarea răspunde dacă un pachet poate trece, nu încotro merge. Alegerea interfeței a fost deja făcută de o căutare de rutare care nu știe nimic despre lista ta de clienți. Repară căutarea și firewall-ul nu mai este suspectul.

O regulă de filtrare nu poate alege o interfață

Fluxul pachetelor pe un router Linux execută mai întâi decizia de rutare și apoi cârligul forward. Când o regulă se potrivește cu dispozitivul de tunel de ieșire, kernelul a decis deja că tunelul este calea de ieșire. Dacă tabelul principal încă preferă ruta implicită WAN, pachetul este pe drum spre ISP și regula de acceptare pe care tocmai ai scris-o nu îl vede niciodată. Acest singur fapt de ordine explică de ce o pagină de reguli noi de firewall nu schimbă nimic.

Exemplul de mai jos folosește un LAN de 192.168.8.0/24 pe br-lan, un dispozitiv de tunel tun0 și un set-top box la 192.168.8.23 care ar trebui să folosească tunelul.

Citește căutarea înainte de a edita reguli

Cere kernelului să rezolve o rută în numele acelui client. Răspunsul include dispozitivul de ieșire și adresa sursă care ar fi aleasă, și asta este tot ce trebuie pentru a confirma diagnosticul. Dacă răspunsul numește dispozitivul WAN, pachetul nu a avut niciodată șansa să ajungă la regula ta.

ip -4 route get 198.51.100.7 from 192.168.8.23

Repetă interogarea pentru un client care ar trebui să rămână pe calea obișnuită. Când ambele răspunsuri numesc același dispozitiv, nu există încă o politică după sursă, iar corectarea ține de rutare, nu de filtrare.

Leagă un tabel de clienții pe care vrei să îi acoperi

Rutarea pe politici inserează o căutare de reguli înaintea tabelului principal. Construiește un tabel a cărui rută implicită este tunelul, apoi leagă tabelul de un selector: o interfață de intrare, o adresă sursă sau un marcaj de firewall. Prioritățile decid ordinea, iar tabelul principal stă mult mai jos în listă, la 32766, așa că o regulă cu număr mic este consultată prima. Selectorii de interfață acoperă fiecare client de pe punte; selectorii de adresă acoperă o singură mașină.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

Interfețele firmware expun de obicei aceleași obiecte ca o pagină de rutare pe politici sau de politică VPN. O listă de dispozitive acolo este mai ușor de întreținut decât regulile scrise de mână și de obicei supraviețuiește actualizărilor care schimbă sintaxa regulilor.

Alege selectorul intenționat. O regulă de interfață este scurtă și rezistentă în timp, dar prinde și traficul de management al routerului care sosește pe acea punte. O regulă de sursă este exactă și are nevoie de editare ori de câte ori se schimbă lista de dispozitive. Notează alegerea, pentru că următoarea persoană care întreabă de ce un dispozitiv se comportă diferit o va necesita.

Ține destinațiile locale în afara tunelului

Un tabel nou cunoaște doar rutele pe care le pui în el. Prefixul LAN lipsește, așa că traficul imprimantei și al NAS-ului ar urma ruta implicită a tunelului și ar dispărea. O rută throw încheie căutarea în acest tabel și dă decizia înapoi tabelului principal.

ip -4 route add throw 192.168.8.0/24 table 200

Dacă sari peste acea rută, partajările locale se strică, iar sesiunea de management a routerului însuși poate dispărea dacă selectorul este mai larg decât s-a intenționat. Apoi rezolvă problema sursei: pachetele de tunel care încă poartă adrese LAN au nevoie ca partea îndepărtată să cunoască o cale de întoarcere, în timp ce masquerading pe tunel elimină această cerință și elimină și identitatea clientului pe care partea îndepărtată ar vedea-o.

Regulile și rutele adăugate în timpul execuției dispar după o repornire sau o actualizare de firmware. Adaugă-le la mecanismul de pornire al routerului, repornește o dată și testează din nou de la client: adresa sa publică, un al doilea client care ar trebui să rămână pe WAN și contoarele tunelului în timpul unei conexiuni noi.