Rut en filialundernet ud gennem hovedkontorets SonicWall-internetudgang

Filialtelefoner bør gå ud gennem hovedkontoret, mens filialbærbare fortsat bruger den lokale WAN, og ruteordningen alene leverer ikke det. En filialrute kan vælge tunnelen, men tunnelpolitikken skal acceptere trafikken, hovedkontoret skal videresende og oversætte den, og svaret skal komme tilbage samme vej. Går blot ét af de tre galt, er symptomet en delmængde af klienter, der mister internettet præcis, mens tunnelen er oppe.

Start med vælgeren, ikke ruten

Rutepolitik matcher på en kilde, så kilden skal være stabil, før noget andet gøres. Sæt de valgte enheder i en adressegruppe, som en administrator vedligeholder, eller endnu bedre på et dedikeret segment, hvis medlemskab følger enhedsrollen. Når almindelig DHCP-udskiftning kan flytte en matchet adresse til en anden maskine, vælger politikken lydløst den forkerte klient, og den første rapport handler normalt om langsom browsing, som i virkeligheden er en omvej.

Navngiv gruppen efter den politik, den tjener, frem for efter en etage eller en afdeling, fordi ruterreglen overlever begge. Notér, hvilke enheder der er i den, og hvem der må tilføje en.

Tilføj filialpolitikken, og forsvart derefter dens rækkefølge

På filialens SonicWall vælger en rutepolitik kildegruppen, navngiver de tilsigtede destinationer og sætter tunnelinterfacet som gateway, hvilket er præcis det, det understøttede tunnelinterface-design findes til. Hold regler for lokale og private destinationer over den brede internetregel, fordi det første match vinder, og et privat præfiks, der skubbes ind i tunnelen, når kun hovedkontoret for at blive droppet. Bevar også firewallens egen rute til dens VPN-peer, ellers følger tunneltransporten den politik, den afhænger af. Intet af dette tvinger dig til at konvertere hver eksisterende politikbaseret tunnel; et tunnelinterface er ét understøttet valg blandt flere.

Rækkefølgen er den del, der ændres ved et uheld. Enhver, der tilføjer en undtagelse, skal indsætte den over den brede regel, og enhver, der redigerer den brede regel, kan vende hele designet med én gemning. Skriv den tilsigtede rækkefølge ved siden af politikken, og tjek den igen efter firmwareopdateringer, fordi interface-navngivning og politikgengivelse faktisk ændrer sig mellem versioner.

Færdiggør vejen på hovedkontoret

Tunnelpolitikken på hovedkontoret skal acceptere den trafik, filialruten nu vælger. En kontor-til-kontor-vælger begrænset til hovedkontorets private LAN er ikke tilladelse til at bære vilkårlige offentlige destinationer, så politikken har brug for filialkilden og det destinationsområde, du faktisk tilsigter. Hovedkontoret videresender derefter den ankommende trafik til sin internetuplink efter sine egne adgangsregler, og SonicWalls eksempel på central udgang omfatter kildeoversættelse for fjernnetværket ved den centrale WAN. Uden den oversættelse ser den fjerne side en privat filialadresse og har ingen rute tilbage til den.

Svarene er den anden halvdel af kontrakten. De skal vende tilbage gennem tunnelen eller gennem den tilstandsfyldte oversættelse, der er oprettet til dem, og trafik til private websteder kan kræve en anden NAT-behandling end offentlig udgang. Hold de regler adskillelige, fordi én bred oversættelsesregel, der skjuler hver intern kilde, gør senere logning og fejlfinding meget sværere at læse.

Beslut, hvad gruppen gør, når tunnelen falder

Hvis den centrale udgang er et krav og ikke en præference, er tilbagefald til den lokale WAN en overholdelsesfejl, selv om brugerne forbliver online. SonicOS dokumenterer en drop-tunnel-interface-rute som den understøttede måde at forhindre udvalgt trafik i at tage en utilsigtet alternativ vej.

Tilpas rutens omfang og prioritet til den installerede version, og test den ved at tage tunnelen ned i stedet for at stole på etiketten. En gruppe, der aldrig må gå ud lokalt, bør fejle lukket, mens en gruppe, hvor tilgængelighed betyder mere, med rette kan falde tilbage; begge er beslutninger, og ingen af dem bør ske som standard.

Bekræft fra tre klienter, og rul derefter rent tilbage

Et ping til den centrale gateway tester det forkerte, fordi det udgår fra firewallen og ikke fra en valgt klient. Test i stedet fra enheder, og test tre af dem: en valgt enhed, en almindelig enhed, der skal forblive lokal, og en, der afhænger af 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 anmodning faktisk dukkede op. En valgt klient bør nå internettet gennem hovedkontorets udgang, og en almindelig klient bør stadig præsentere filialens egen adresse på den fjerne side; 203.0.113.10 er en dokumentationsadresse, der bruges som erstatning for den destination, du bekymrer dig om. Medtag DNS i samme gennemløb, fordi en klient, der spørger filialens resolver, kan frembringe et opslag med oprindelse i routeren med en anden kilde og derfor en anden rute.

Tilbagerulning er den gemte politikrækkefølge plus adressegruppen. Gendan den tidligere rækkefølge, fjern gruppen fra politikken, og test begge enhedsklasser igen. Opbevar den eksporterede konfiguration sammen med ændringsregistreringen, fordi den næste ingeniør skal vide, hvilken regel der var den brede, før nogen redigerede den.