Maršrutējiet filiāles apakštīklu caur galvenā biroja SonicWall interneta izeju

Filiāles tālruņiem jāiziet caur galveno biroju, kamēr filiāles klēpjdatori turpina izmantot vietējo WAN, un vien maršrutēšanas politika to nenodrošinās. Filiāles maršruts var izvēlēties tuneli, bet tuneļa politikai ir jāpieņem trafiks, galvenajam birojam tas jāpārsūta un jāiztulko, un atbildei jāatgriežas pa to pašu ceļu. Ja izlaidīsiet kaut vienu no šiem trim, simptoms būs klientu apakškopa, kas zaudē internetu tieši tad, kad tunelis ir aktīvs.

Sāciet ar selektoru, nevis ar maršrutu

Maršrutēšanas politika saskan pēc avota, tāpēc avotam jābūt stabilam pirms visa cita. Ievietojiet izvēlētās ierīces adrešu grupā, ko uztur administrators, vai vēl labāk atsevišķā segmentā, kura dalība seko ierīces lomai. Kad parastā DHCP maiņa var pārvietot atbilstošo adresi uz citu mašīnu, politika klusi izvēlas nepareizo klientu, un pirmais ziņojums parasti ir par lēnu pārlūkošanu, kas patiesībā ir apkārtceļš.

Nosauciet grupu pēc politikas, kurai tā kalpo, nevis pēc stāva vai nodaļas, jo maršrutēšanas noteikums pārdzīvos abus. Pierakstiet, kuras ierīces tajā ir un kurš drīkst pievienot vienu.

Pievienojiet filiāles politiku un pēc tam aizstāviet tās secību

Filiāles SonicWall maršruta politika izvēlas avota grupu, nosauc paredzētos galamērķus un iestata tuneļa saskarni kā vārteju, un atbalstītais tuneļa saskarnes dizains pastāv tieši tam. Turiet vietējo un privāto galamērķu noteikumus virs plašā interneta noteikuma, jo uzvar pirmā atbilstība, un tunelī iespiests privātais prefikss galvenajā birojā nonāk tikai tāpēc, lai tiktu izmests. Saglabājiet arī pašas ugunsmūra maršrutu uz tā VPN partneri, citādi tuneļa transports sekos politikai, no kuras tas ir atkarīgs. Nekas no tā neliek jums pārveidot katru esošo uz politiku balstīto tuneli; tuneļa saskarne ir viena atbalstīta izvēle starp vairākām.

Secība ir tā daļa, kas mainās nejauši. Ikviens, kas pievieno izņēmumu, tam jāievieto virs plašā noteikuma, un ikviens, kas rediģē plašo noteikumu, var apgriezt visu dizainu ar vienu saglabāšanu. Pierakstiet paredzēto secību blakus politikai un pēc programmaparatūras atjauninājumiem pārbaudiet to vēlreiz, jo saskarņu nosaukumi un politiku attēlojums tiešām mainās starp versijām.

Pabeidziet ceļu galvenajā birojā

Galvenā biroja tuneļa politikai ir jāpieņem trafiks, ko tagad izvēlas filiāles maršruts. Starpbiroju selektors, kas ierobežots ar galvenā biroja privāto LAN, nav atļauja pārvadāt patvaļīgus publiskus galamērķus, tāpēc politikai vajag filiāles avotu un galamērķu diapazonu, ko jūs patiešām domājat. Pēc tam galvenais birojs pārsūta šo ienākošo trafiku uz savu interneta uplinku saskaņā ar saviem piekļuves noteikumiem, un SonicWall centrālās izejas piemērs ietver avota tulkojumu attālajam tīklam centrālajā WAN. Bez šī tulkojuma tālā puse redz privātu filiāles adresi un tai nav maršruta atpakaļ uz to.

Atbildes ir otra līguma puse. Tām jāatgriežas pa tuneli vai pa tām izveidoto stāvokļa tulkojumu, un privāto vietņu trafikam var būt vajadzīga citāda NAT apstrāde nekā publiskai izejai. Turiet šos noteikumus atšķiramus, jo viens plašs tulkošanas noteikums, kas slēpj katru iekšējo avotu, vēlāko reģistrēšanu un problēmu novēršanu padara daudz grūtāk lasāmu.

Izlemiet, ko grupa dara, kad tunelis nokrīt

Ja centrālā izeja ir prasība, nevis izvēle, atgriešanās pie vietējā WAN ir atbilstības pārkāpums, pat ja lietotāji paliek tiešsaistē. SonicOS dokumentē maršrutu ar tuneļa saskarnes nomešanu kā atbalstīto veidu, kā neļaut izvēlētajam trafikam doties neparedzētā alternatīvā ceļā.

Saskaņojiet šī maršruta apjomu un prioritāti ar instalēto versiju un pārbaudiet to, nolaižot tuneli, nevis paļaujoties uz etiķeti. Grupai, kurai nekad nevajadzētu iziet vietēji, jācieš slēgta atteice, savukārt grupa, kurā pieejamība ir svarīgāka, var likumīgi atkrist; abi ir lēmumi, un nevienam no tiem nevajadzētu notikt pēc noklusējuma.

Pārbaudiet no trim klientiem un pēc tam tīri atritiniet

Ping uz centrālo vārteju pārbauda nepareizo lietu, jo tas nāk no ugunsmūra, nevis no izvēlēta klienta. Pārbaudiet no ierīcēm un pārbaudiet trīs no tām: izvēlētu ierīci, parastu ierīci, kurai jāpaliek vietējai, un vienu, kas ir atkarīga no vietējiem pakalpojumiem.

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

Salīdziniet, kur publiskais pieprasījums patiešām parādījās. Izvēlētam klientam jāsasniedz internets pa galvenā biroja izeju, un parastam klientam tālajā pusē joprojām jārāda sava filiāles adrese; 203.0.113.10 ir dokumentācijas adrese, kas izmantota kā jums svarīgā galamērķa aizstājējs. Iekļaujiet DNS tajā pašā piegājienā, jo klients, kas vaicā filiāles risinātājam, var radīt no maršrutētāja izcēlušos vaicājumu ar citu avotu un tāpēc citu maršrutu.

Atritināšana ir saglabātā politiku secība plus adrešu grupa. Atjaunojiet iepriekšējo secību, izņemiet grupu no politikas un atkārtoti pārbaudiet abas ierīču klases. Saglabājiet eksportēto konfigurāciju kopā ar izmaiņu ierakstu, jo nākamajam inženierim jāzina, kurš noteikums bija plašais, pirms kāds to rediģēja.