Routa ett filialundernät via huvudkontorets SonicWall-internetutgång

Filialtelefoner bör gå ut via huvudkontoret medan filialbärbara fortsätter använda det lokala WAN:et, och ruttpolicyn ensam levererar inte det. En filialrutt kan välja tunneln, men tunnelpolicyn måste acceptera trafiken, huvudkontoret måste vidarebefordra och översätta den, och svaret måste komma tillbaka samma väg. Missa något av dessa tre och symtomet blir en delmängd klienter som tappar internet precis medan tunneln är uppe.

Börja med väljaren, inte rutten

Ruttpolicyn matchar på en källa, så källan måste vara stabil före allt annat. Placera de valda enheterna i en adressgrupp som en administratör underhåller eller, ännu bättre, på ett dedikerat segment vars medlemskap följer enhetsrollen. När vanlig DHCP-omsättning kan flytta en matchad adress till en annan maskin väljer policyn tyst fel klient, och den första rapporten handlar oftast om långsam surf som egentligen är en omväg.

Namnge gruppen efter policyn den tjänar, inte efter en våning eller avdelning, eftersom ruttregeln kommer överleva båda. Anteckna vilka enheter som finns i den och vem som får lägga till en.

Lägg till filialpolicyn och försvara sedan dess ordning

På filialens SonicWall väljer en ruttpolicy källgruppen, namnger de avsedda destinationerna och ställer in tunnelgränssnittet som gateway, och det är precis vad den stödda tunnelgränssnittsdesignen finns till för. Håll regler för lokala och privata destinationer ovanför den breda internetregeln, eftersom första träffen vinner och ett privat prefix som skjuts in i tunneln når huvudkontoret bara för att slängas. Bevara också brandväggens egen rutt till sin VPN-peer, annars följer tunneltransporten policyn den är beroende av. Inget av detta tvingar dig att konvertera varje befintlig policybaserad tunnel; ett tunnelgränssnitt är ett stött val bland flera.

Ordningen är den del som ändras av misstag. Den som lägger till ett undantag måste sätta in det ovanför den breda regeln, och den som redigerar den breda regeln kan vända hela designen med en enda sparning. Skriv den avsedda ordningen bredvid policyn och kontrollera den igen efter firmwareuppdateringar, eftersom gränssnittsnamn och policyrendering faktiskt förskjuts mellan versioner.

Slutför vägen på huvudkontoret

Tunnelpolicyn på huvudkontoret måste acceptera trafiken som filialrutten nu väljer. En kontor-till-kontor-väljare begränsad till huvudkontorets privata LAN är inte tillstånd att föra godtyckliga offentliga destinationer, så policyn behöver filialkällan och det destinationsområde du faktiskt avser. Huvudkontoret vidarebefordrar sedan den inkommande trafiken till sin internetuplänk enligt sina egna åtkomstregler, och SonicWalls exempel på central utgång innehåller källöversättning för fjärrnätet vid det centrala WAN:et. Utan den översättningen ser fjärrsidan en privat filialadress och har ingen rutt tillbaka.

Svaren är den andra halvan av kontraktet. De måste komma tillbaka genom tunneln eller genom den tillståndsfulla översättning som skapats för dem, och trafik till privata webbplatser kan behöva annan NAT-behandling än offentlig utgång. Håll dessa regler urskiljbara, eftersom en bred översättningsregel som döljer varje intern källa gör senare loggning och felsökning mycket svårare att läsa.

Bestäm vad gruppen gör när tunneln faller

Om den centrala utgången är ett krav och inte en preferens är återgång till det lokala WAN:et ett efterlevnadsfel även om användarna förblir online. SonicOS dokumenterar en rutt med droppad tunnelgränssnitt som det stödda sättet att hindra utvald trafik från att ta en oavsiktlig alternativ väg.

Anpassa ruttens omfattning och prioritet till den installerade versionen, och testa den genom att ta ner tunneln i stället för att lita på etiketten. En grupp som aldrig får gå ut lokalt bör misslyckas stängt, medan en grupp där tillgänglighet betyder mer legitimt kan falla tillbaka; båda är beslut, och inget av dem bör ske som standard.

Verifiera från tre klienter och rulla sedan rent tillbaka

En ping till den centrala gatewayen testar fel sak, eftersom den kommer från brandväggen och inte från en vald klient. Testa från enheter i stället, och testa tre av dem: en vald enhet, en vanlig enhet som ska stanna lokalt och en som är beroende av lokala tjänster.

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

Jämför var den offentliga begäran faktiskt dök upp. En vald klient bör nå internet via huvudkontorets utgång, och en vanlig klient bör fortfarande visa filialens egen adress på fjärrsidan; 203.0.113.10 är en dokumentationsadress som används som ersättning för destinationen du bryr dig om. Ta med DNS i samma omgång, eftersom en klient som frågar filialens resolver kan producera ett uppslag med ursprung i routern med en annan källa och därför en annan rutt.

Återrullning är den sparade policyordningen plus adressgruppen. Återställ den tidigare ordningen, ta bort gruppen från policyn och testa båda enhetsklasserna igen. Behåll den exporterade konfigurationen tillsammans med ändringsloggen, eftersom nästa ingenjör behöver veta vilken regel som var den breda innan någon redigerade den.