Rutați o subrețea de sucursală prin ieșirea de internet SonicWall a sediului central

Telefoanele sucursalei ar trebui să iasă prin sediul central, în timp ce laptopurile sucursalei continuă să folosească WAN-ul local, iar politica de rutare singură nu va realiza asta. O rută a sucursalei poate selecta tunelul, dar politica tunelului trebuie să accepte traficul, sediul central trebuie să îl redirecționeze și să îl traducă, iar răspunsul trebuie să revină pe același drum. Dacă lipsește oricare dintre cele trei, simptomul va fi un subset de clienți care pierd internetul exact cât timp tunelul este activ.

Începeți cu selectorul, nu cu ruta

Politica de rutare se potrivește pe o sursă, așa că sursa trebuie să fie stabilă înainte de orice altceva. Puneți dispozitivele alese într-un grup de adrese întreținut de un administrator sau, mai bine, pe un segment dedicat a cărui apartenență urmează rolul dispozitivului. Când rotația obișnuită DHCP poate muta o adresă potrivită pe altă mașină, politica selectează în tăcere clientul greșit, iar primul raport este de obicei despre navigare lentă care este de fapt un ocol.

Numiți grupul după politica pe care o deservește, nu după un etaj sau un departament, pentru că regula de rutare le va supraviețui ambelor. Notați ce dispozitive sunt în el și cine poate adăuga unul.

Adăugați politica sucursalei și apoi apărați-i ordinea

Pe SonicWall-ul sucursalei, o politică de rută selectează grupul de surse, numește destinațiile dorite și setează interfața tunelului ca poartă, iar designul de interfață de tunel acceptat există exact pentru asta. Țineți regulile pentru destinații locale și private deasupra regulii largi de internet, pentru că prima potrivire câștigă, iar un prefix privat împins în tunel ajunge la sediul central doar ca să fie aruncat. Păstrați și ruta proprie a firewall-ului către partenerul său VPN, altfel transportul tunelului va urma politica de care depinde. Nimic din toate acestea nu vă obligă să convertiți fiecare tunel existent bazat pe politică; o interfață de tunel este o opțiune acceptată între mai multe.

Ordinea este partea care se schimbă din greșeală. Cine adaugă o excepție trebuie să o insereze deasupra regulii largi, iar cine editează regula largă poate inversa întregul design cu o singură salvare. Scrieți ordinea dorită lângă politică și verificați-o din nou după actualizările de firmware, pentru că denumirea interfețelor și randarea politicilor chiar se schimbă între versiuni.

Finalizați calea la sediul central

Politica tunelului din sediul central trebuie să accepte traficul pe care ruta sucursalei îl selectează acum. Un selector între birouri limitat la LAN-ul privat al sediului central nu este permisiunea de a transporta destinații publice arbitrare, așa că politica are nevoie de sursa sucursalei și de intervalul de destinații pe care îl intenționați cu adevărat. Sediul central redirecționează apoi acel trafic de intrare către uplink-ul său de internet conform propriilor reguli de acces, iar exemplul de ieșire centrală al SonicWall include traducerea sursei pentru rețeaua la distanță la WAN-ul central. Fără acea traducere, partea îndepărtată vede o adresă privată a sucursalei și nu are rută de întoarcere.

Răspunsurile sunt cealaltă jumătate a contractului. Ele trebuie să revină prin tunel sau prin traducerea cu stare creată pentru ele, iar traficul către site-uri private poate necesita un tratament NAT diferit de cel al ieșirii publice. Țineți acele reguli distincte, pentru că o singură regulă largă de traducere care ascunde fiecare sursă internă face jurnalizarea și depanarea ulterioară mult mai greu de citit.

Decideți ce face grupul când cade tunelul

Dacă ieșirea centrală este o cerință și nu o preferință, revenirea la WAN-ul local este o nerespectare a conformității chiar dacă utilizatorii rămân online. SonicOS documentează o rută de eliminare a interfeței tunelului ca modalitatea acceptată de a împiedica traficul selectat să ia o cale alternativă nedorită.

Potriviți domeniul și prioritatea acelei rute cu versiunea instalată și testați-o coborând tunelul în loc să vă încredeți în etichetă. Un grup care nu trebuie să iasă niciodată local ar trebui să eșueze închis, în timp ce un grup în care disponibilitatea contează mai mult poate reveni în mod legitim; ambele sunt decizii și niciuna nu ar trebui să se întâmple implicit.

Verificați din trei clienți, apoi reveniți curat

Un ping către poarta centrală testează lucrul greșit, pentru că provine de la firewall, nu de la un client selectat. Testați din dispozitive, și testați trei dintre ele: un dispozitiv selectat, un dispozitiv obișnuit care ar trebui să rămână local și unul care depinde de servicii locale.

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

Comparați unde a apărut de fapt cererea publică. Un client selectat ar trebui să ajungă la internet prin ieșirea sediului central, iar un client obișnuit ar trebui să prezinte în continuare adresa proprie a sucursalei pe partea îndepărtată; 203.0.113.10 este o adresă de documentare folosită ca substitut pentru destinația care vă interesează. Includeți DNS în aceeași trecere, pentru că un client care întreabă resolverul sucursalei poate produce o interogare originată de router cu altă sursă și, prin urmare, altă rută.

Revenirea este ordinea politicilor salvată plus grupul de adrese. Restaurați ordinea anterioară, eliminați grupul din politică și retestați ambele clase de dispozitive. Păstrați configurația exportată împreună cu înregistrarea modificării, pentru că următorul inginer trebuie să știe care regulă era cea largă înainte ca cineva să o editeze.