Rut en filialundersnett ut gjennom hovedkontorets SonicWall-internetuttak
Velg en filialkildegruppe, godta den i tunnelpolicyen, oversett ved den sentrale WAN-en, og test deretter tre klienter. En rute alene lager ingen gateway.
Filialtelefoner bør gå ut gjennom hovedkontoret mens filialbærbare fortsatt bruker den lokale WAN-en, og rutepolicyen alene leverer ikke det. En filialrute kan velge tunnelen, men tunnelpolicyen må godta trafikken, hovedkontoret må videresende og oversette den, og svaret må komme tilbake samme vei. Mangler ett av disse tre, er symptomet en delmengde klienter som mister internett akkurat mens tunnelen er oppe.
Begynn med velgeren, ikke ruten
Rutepolicyen matcher på en kilde, så kilden må være stabil før noe annet. Sett de valgte enhetene i en adressegruppe som en administrator vedlikeholder, eller bedre, på et dedikert segment der medlemskapet følger enhetsrollen. Når vanlig DHCP-utskiftning kan flytte en matchet adresse til en annen maskin, velger policyen stille feil klient, og den første rapporten handler vanligvis om treg surfing som egentlig er en omvei.
Navngi gruppen etter policyen den tjener, ikke etter en etasje eller avdeling, fordi ruterregelen vil overleve begge. Noter hvilke enheter som er i den, og hvem som kan legge til en.
Legg til filialpolicyen, og forsvare deretter rekkefølgen
På filialens SonicWall velger en rutepolicy kildegruppen, navngir de tiltenkte destinasjonene og setter tunnelgrensesnittet som gateway, og det er nettopp derfor det støttede tunnelgrensesnittdesignet finnes. Hold regler for lokale og private destinasjoner over den brede internettregelen, fordi første treff vinner, og et privat prefiks som skyves inn i tunnelen, når hovedkontoret bare for å bli droppet. Bevar også brannmurens egen rute til VPN-motparten, ellers vil tunneltransporten følge policyen den er avhengig av. Ingenting av dette tvinger deg til å konvertere hver eksisterende policybasert tunnel; et tunnelgrensesnitt er ett støttet valg blant flere.
Rekkefølgen er den delen som endres ved et uhell. Den som legger til et unntak, må sette det inn over den brede regelen, og den som redigerer den brede regelen, kan snu hele designet med én lagring. Skriv den tiltenkte rekkefølgen ved siden av policyen og kontroller den på nytt etter fastvareoppdateringer, fordi grensesnittnavn og policygjengivelse faktisk endrer seg mellom versjoner.
Fullfør veien i hovedkontoret
Tunnelpolicyen i hovedkontoret må godta trafikken som filialruten nå velger. En kontor-til-kontor-velger begrenset til hovedkontorets private LAN er ikke tillatelse til å føre vilkårlige offentlige destinasjoner, så policyen trenger filialkilden og destinasjonsområdet du faktisk mener. Hovedkontoret videresender deretter den ankommende trafikken til sin internett-uplink etter sine egne tilgangsregler, og SonicWalls eksempel på sentralt uttak inkluderer kildeoversettelse for fjernnettverket ved den sentrale WAN-en. Uten den oversettelsen ser den fjerne siden en privat filialadresse og har ingen rute tilbake til den.
Svarene er den andre halvdelen av kontrakten. De må komme tilbake gjennom tunnelen eller gjennom den tilstandsfulle oversettelsen som er laget for dem, og trafikk til private nettsteder kan trenge en annen NAT-behandling enn offentlig utgang. Hold disse reglene atskilbare, fordi én bred oversettelsesregel som skjuler hver intern kilde gjør senere logging og feilsøking mye vanskeligere å lese.
Bestem hva gruppen gjør når tunnelen faller
Hvis det sentrale uttaket er et krav og ikke en preferanse, er tilbakefall til den lokale WAN-en et samsvarsbrudd selv om brukerne blir online. SonicOS dokumenterer en rute med dropp av tunnelgrensesnittet som den støttede måten å hindre utvalgt trafikk i å ta en utilsiktet alternativ vei.
Tilpass rutens omfang og prioritet til den installerte versjonen, og test den ved å ta tunnelen ned i stedet for å stole på etiketten. En gruppe som aldri skal gå ut lokalt, bør feile lukket, mens en gruppe der tilgjengelighet betyr mer, kan falle tilbake på lovlig vis; begge er beslutninger, og ingen av dem bør skje som standard.
Verifiser fra tre klienter, og rull deretter rent tilbake
En ping til den sentrale gatewayen tester feil ting, fordi den kommer fra brannmuren og ikke fra en valgt klient. Test fra enheter i stedet, og test tre av dem: en valgt enhet, en vanlig enhet som skal forbli lokal, og en som er avhengig av lokale tjenester.
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
Sammenlign hvor den offentlige forespørselen faktisk dukket opp. En valgt klient bør nå internett gjennom hovedkontorets uttak, og en vanlig klient bør fortsatt vise filialens egen adresse på den fjerne siden; 203.0.113.10 er en dokumentasjonsadresse som brukes som erstatning for destinasjonen du bryr deg om. Ta med DNS i samme runde, fordi en klient som spør filialens resolver, kan produsere et oppslag med opprinnelse i ruteren med en annen kilde og derfor en annen rute.
Tilbakerulling er den lagrede policyrekkefølgen pluss adressegruppen. Gjenopprett den forrige rekkefølgen, fjern gruppen fra policyen, og test begge enhetsklassene på nytt. Oppbevar den eksporterte konfigurasjonen sammen med endringsloggen, fordi den neste ingeniøren trenger å vite hvilken regel som var den brede før noen redigerte den.