Stuur een taksubnet uit via die hoofkwartier se SonicWall-internetuitgang

Takfone moet deur die hoofkwartier uitgaan terwyl takskootrekenaars die plaaslike WAN bly gebruik, en die roetebeleid alleen sal dit nie lewer nie. 'n Takroete kan die tonnel kies, maar die tonnelbeleid moet die verkeer aanvaar, die hoofkwartier moet dit aanstuur en vertaal, en die antwoord moet op dieselfde pad terugkom. Mis enige van dié drie en die simptoom is 'n subset kliënte wat presies internet verloor terwyl die tonnel op is.

Begin by die keurder, nie by die roete nie

Roetebeleid pas op 'n bron, dus die bron moet stabiel wees voordat enigiets anders gebeur. Sit die gekose toestelle in 'n adresgroep wat 'n administrateur onderhou, of beter, op 'n toegewyde segment waarvan die lidmaatskap die toestelrol volg. Wanneer gewone DHCP-wisseling 'n gepaste adres na 'n ander masjien kan skuif, kies die beleid stilswyend die verkeerde kliënt, en die eerste verslag gaan gewoonlik oor stadige blaai wat eintlik 'n ompad is.

Noem die groep na die beleid wat dit dien, nie na 'n vloer of 'n department nie, want die roetereël sal albei oorleef. Teken aan watter toestelle daarin is en wie een mag byvoeg.

Voeg die takbeleid by en verdedig dan sy volgorde

Op die tak-SonicWall kies 'n roetebeleid die brongroep, benoem die beoogde bestemmings en stel die tonnelkoppelvlak as die poort, en dit is waarvoor die ondersteunde tonnelkoppelvlak-ontwerp bestaan. Hou plaaslike en privaatbestemming-reëls bo die breë internetreël, want die eerste passing wen en 'n privaat voorvoegsel wat in die tonnel gedruk word, kom by die hoofkwartier aan net om weggegooi te word. Bewaar ook die firewall se eie roete na sy VPN-eweknie, anders sal die tonnelvervoer die beleid volg waarvan dit afhanklik is. Niks hiervan dwing jou om elke bestaande beleidsgebaseerde tonnel om te skakel nie; 'n tonnelkoppelvlak is een ondersteunde keuse onder verskeie.

Volgorde is die deel wat per ongeluk verander. Enigiemand wat 'n uitsondering byvoeg, moet dit bo die breë reël invoeg, en enigiemand wat die breë reël wysig, kan die hele ontwerp in een stoor omkeer. Skryf die beoogde volgorde langs die beleid en hersien dit ná firmware-opdaterings, want koppelvlakbenaming en beleidweergawe verskuif wel tussen weergawes.

Voltooi die pad by die hoofkwartier

Die tonnelbeleid by die hoofkwartier moet die verkeer aanvaar wat die takroete nou kies. 'n Interkantoor-keurder wat op die hoofkwartier se privaat LAN gemik is, is nie toestemming om willekeurige publieke bestemmings te dra nie, so die beleid het die takbron en die bestemmingsreeks nodig wat jy werklik beoog. Die hoofkwartier stuur dan daardie aankomende verkeer na sy internetoplink onder sy eie toegangsreëls, en SonicWall se sentrale-uitgang-voorbeeld sluit bronvertaling vir die afgeleë netwerk by die sentrale WAN in. Sonder daardie vertaling sien die verre kant 'n privaat takadres en het dit geen roete terug daarheen nie.

Antwoorde is die ander helfte van die kontrak. Hulle moet deur die tonnel of deur die staatvolle vertaling wat daarvoor geskep is, terugkeer, en privaatwerf-verkeer mag dalk anders as publieke uitgang deur NAT behandel word. Hou daardie reëls onderskeibaar, want een breë vertaalreël wat elke interne bron verberg, maak latere logboeke en probleemoplossing baie moeiliker leesbaar.

Besluit wat die groep doen wanneer die tonnel wegval

As die sentrale uitgang 'n vereiste eerder as 'n voorkeur is, is terugval na die plaaslike WAN 'n nakomingsfout selfs al bly gebruikers aanlyn. SonicOS dokumenteer 'n drop-tonnelkoppelvlak-roete as die ondersteunde manier om te keer dat gekose verkeer 'n onbedoelde alternatiewe pad neem.

Pas daardie roete se omvang en prioriteit onder die geïnstalleerde weergawe, en toets dit deur die tonnel af te bring eerder as om die etiket te vertrou. 'n Groep wat nooit plaaslik mag uitgaan nie, moet geslote faal, terwyl 'n groep waar beskikbaarheid meer saak maak, wettig mag terugval; albei is besluite, en nie een moet by verstek gebeur nie.

Verifieer vanaf drie kliënte en rol dan skoon terug

'n Ping na die sentrale poort toets die verkeerde ding, want dit ontstaan by die firewall eerder as by 'n gekose kliënt. Toets eerder vanaf toestelle, en toets drie daarvan: 'n gekose toestel, 'n gewone toestel wat plaaslik moet bly, en een wat van plaaslike dienste afhanklik is.

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

Vergelyk waar die publieke versoek werklik opgeduik het. 'n Gekose kliënt behoort die internet deur die hoofkwartier se uitgang te bereik, en 'n gewone kliënt behoort steeds die tak se eie adres aan die verre kant te toon; 203.0.113.10 is 'n dokumentasieadres wat as 'n plaasvervanger vir die bestemming wat jou saak maak, gebruik word. Sluit DNS in dieselfde ronde in, want 'n kliënt wat die tak-resolver navraag doen, kan 'n roeteerder-oorsprong-opsoeking met 'n ander bron en dus 'n ander roete lewer.

Terugrol is die gestoorde beleidsvolgorde plus die adresgroep. Herstel die vorige volgorde, verwyder die groep uit die beleid, en toets albei toestelklasse weer. Hou die uitgevoerde konfigurasie by die veranderingsrekord, want die volgende ingenieur moet weet watter reël die breë een was voordat iemand dit gewysig het.