Stuur één branch-subnet via de SonicWall-internetuitgang van het hoofdkantoor

Branchtelefoons moeten via het hoofdkantoor naar buiten gaan, terwijl branchlaptops het lokale WAN blijven gebruiken, en het routebeleid alleen levert dat niet. Een branchroute kan de tunnel kiezen, maar het tunnelbeleid moet het verkeer accepteren, het hoofdkantoor moet het doorsturen en vertalen, en het antwoord moet via dezelfde weg terugkomen. Mist u één van die drie, dan is het symptoom een subset van clients die precies internet verliezen terwijl de tunnel actief is.

Begin bij de selector, niet bij de route

Routebeleid matcht op een bron, dus de bron moet stabiel zijn voordat iets anders gebeurt. Zet de gekozen apparaten in een adresgroep die een beheerder onderhoudt, of beter, op een toegewijd segment waarvan het lidmaatschap de apparaatrol volgt. Wanneer gewone DHCP-uitwisseling een gematcht adres naar een andere machine kan verplaatsen, kiest het beleid stil de verkeerde client, en het eerste rapport gaat meestal over traag browsen dat eigenlijk een omweg is.

Noem de groep naar het beleid dat hij dient, niet naar een verdieping of afdeling, want de routeregel overleeft beide. Noteer welke apparaten erin zitten en wie er een mag toevoegen.

Voeg het branchbeleid toe en verdedig daarna de volgorde

Op de branch-SonicWall selecteert een routebeleid de brongroep, benoemt de bedoelde bestemmingen en stelt de tunnelinterface als gateway in, en daar is het ondersteunde tunnelinterfaceontwerp precies voor bedoeld. Houd regels voor lokale en privébestemmingen boven de brede internetregel, want de eerste match wint en een privéprefix die in de tunnel wordt geduwd, bereikt het hoofdkantoor alleen om te worden weggegooid. Bewaar ook de eigen route van de firewall naar zijn VPN-peer, anders volgt het tunneltransport het beleid waarvan het afhangt. Niets hiervan dwingt u om elke bestaande op beleid gebaseerde tunnel om te zetten; een tunnelinterface is één ondersteunde keuze uit meerdere.

De volgorde is het deel dat per ongeluk verandert. Wie een uitzondering toevoegt, moet die boven de brede regel invoegen, en wie de brede regel bewerkt, kan het hele ontwerp met één opslag omkeren. Schrijf de bedoelde volgorde naast het beleid en controleer die opnieuw na firmware-updates, want interfacenamen en beleidsweergave verschuiven echt tussen releases.

Maak het pad af op het hoofdkantoor

Het tunnelbeleid op het hoofdkantoor moet het verkeer accepteren dat de branchroute nu selecteert. Een tusselkantoor-selector die beperkt is tot het privé-LAN van het hoofdkantoor is geen toestemming om willekeurige openbare bestemmingen te vervoeren, dus het beleid heeft de branchbron en het bestemmingsbereik nodig dat u werkelijk bedoelt. Het hoofdkantoor stuurt dat inkomende verkeer vervolgens door naar zijn internetuplink volgens zijn eigen toegangsregels, en SonicWalls voorbeeld van een centrale uitgang bevat bronvertaling voor het externe netwerk op de centrale WAN. Zonder die vertaling ziet de verre kant een privé-branchadres en heeft geen route terug.

Antwoorden zijn de andere helft van het contract. Ze moeten terugkomen via de tunnel of via de stateful vertaling die voor hen is gemaakt, en verkeer naar privésites kan een andere NAT-behandeling nodig hebben dan openbare uitgang. Houd die regels onderscheidbaar, want één brede vertaalregel die elke interne bron verbergt, maakt latere logging en probleemoplossing veel moeilijker leesbaar.

Bepaal wat de groep doet als de tunnel wegvalt

Als de centrale uitgang een vereiste is en geen voorkeur, is terugvallen op het lokale WAN een compliance-fout, zelfs als gebruikers online blijven. SonicOS documenteert een route met een gedropte tunnelinterface als de ondersteunde manier om te voorkomen dat geselecteerd verkeer een onbedoeld alternatief pad neemt.

Stem het bereik en de prioriteit van die route af op de geïnstalleerde release, en test hem door de tunnel neer te halen in plaats van het label te vertrouwen. Een groep die nooit lokaal naar buiten mag, hoort gesloten te falen, terwijl een groep waar beschikbaarheid belangrijker is legitiem mag terugvallen; beide zijn beslissingen, en geen van beide hoort standaard te gebeuren.

Verifieer vanaf drie clients en rol dan schoon terug

Een ping naar de centrale gateway test het verkeerde, omdat hij bij de firewall begint en niet bij een geselecteerde client. Test in plaats daarvan vanaf apparaten, en test er drie: een geselecteerd apparaat, een gewoon apparaat dat lokaal moet blijven, en een dat afhankelijk is van lokale diensten.

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

Vergelijk waar het openbare verzoek werkelijk opdook. Een geselecteerde client hoort het internet via de uitgang van het hoofdkantoor te bereiken, en een gewone client hoort aan de verre kant nog steeds het eigen adres van de branch te tonen; 203.0.113.10 is een documentatieadres dat als plaatsvervanger dient voor de bestemming die u belangrijk vindt. Neem DNS in dezelfde ronde mee, want een client die de resolver van de branch vraagt, kan een opzoeking opleveren die bij de router begint met een andere bron en dus een andere route.

Terugdraaien is de opgeslagen beleidsvolgorde plus de adresgroep. Herstel de vorige volgorde, verwijder de groep uit het beleid en test beide apparaatklassen opnieuw. Bewaar de geëxporteerde configuratie bij het wijzigingsrecord, want de volgende engineer moet weten welke regel de brede was voordat iemand die bewerkte.