Reititä yhden sivukonttorin aliverkko pääkonttorin SonicWall-internetlähdön kautta

Sivukonttorin puhelimien tulisi poistua pääkonttorin kautta, kun taas sivukonttorin kannettavat jatkavat paikallisen WANin käyttöä, eikä pelkkä reitityskäytäntö tuota sitä. Sivukonttorin reitti voi valita tunnelin, mutta tunnelikäytännön on hyväksyttävä liikenne, pääkonttorin on välitettävä ja käännettävä se, ja vastauksen on palattava samaa tietä. Jos yksikin näistä kolmesta puuttuu, oireena on joukko asiakkaita, jotka menettävät internetin juuri silloin, kun tunneli on käytössä.

Aloita valitsimesta, älä reitistä

Reitityskäytäntö täsmää lähteen perusteella, joten lähteen on oltava vakaa ennen muuta. Laita valitut laitteet osoiteryhmään, jota ylläpitäjä hoitaa, tai vielä paremmin omaan segmenttiin, jonka jäsenyys seuraa laitteen roolia. Kun tavallinen DHCP-vaihtelu voi siirtää täsmäävän osoitteen toiseen koneeseen, käytäntö valitsee äänettömästi väärän asiakkaan, ja ensimmäinen ilmoitus koskee yleensä hidasta selaamista, joka on todellisuudessa kiertotie.

Nimeä ryhmä sen palveleman käytännön mukaan, ei kerroksen tai osaston mukaan, koska reitityssääntö elää molempia pidempään. Kirjaa, mitkä laitteet siinä ovat ja kuka saa lisätä yhden.

Lisää sivukonttorin käytäntö ja puolusta sitten sen järjestystä

Sivukonttorin SonicWallissa reittikäytäntö valitsee lähderyhmän, nimeää aiotut kohteet ja asettaa tunneliliitännän yhdyskäytäväksi, mitä varten tuettu tunneliliitäntärakenne on olemassa. Pidä paikallisten ja yksityisten kohteiden säännöt laajan internetsäännön yläpuolella, koska ensimmäinen osuma voittaa, ja tunneliin työnnetty yksityinen etuliite saapuu pääkonttoriin vain pudotettavaksi. Säilytä myös palomuurin oma reitti sen VPN-vastapuoleen, muuten tunnelin kuljetus seuraa käytäntöä, josta se riippuu. Mikään tästä ei pakota muuntamaan jokaista olemassa olevaa käytäntöpohjaista tunnelia; tunneliliitäntä on yksi tuettu vaihtoehto useiden joukossa.

Järjestys on se osa, joka muuttuu vahingossa. Jokaisen poikkeuksen lisääjän on sijoitettava se laajan säännön yläpuolelle, ja jokainen laajaa sääntöä muokkaava voi kääntää koko rakenteen yhdellä tallennuksella. Kirjoita aiottu järjestys käytännön viereen ja tarkista se uudelleen laiteohjelmistopäivitysten jälkeen, koska liitäntöjen nimeäminen ja käytäntöjen esitys todella muuttuvat versioiden välillä.

Viimeistele polku pääkonttorissa

Pääkonttorin tunnelikäytännön on hyväksyttävä liikenne, jonka sivukonttorin reitti nyt valitsee. Pääkonttorin yksityiseen LANiin rajattu toimistojen välinen valitsin ei ole lupa kuljettaa mielivaltaisia julkisia kohteita, joten käytäntö tarvitsee sivukonttorin lähteen ja sen kohdealueen, jota todella tarkoitat. Pääkonttori välittää saapuvan liikenteen sitten internet-liityntälinkkiinsä omien käyttöoikeussääntöjensä mukaisesti, ja SonicWallin esimerkki keskuslähdöstä sisältää lähteen käännöksen etäverkolle keskisessä WANissa. Ilman tuota käännöstä kaukopuoli näkee yksityisen sivukonttorin osoitteen eikä sillä ole paluureittiä sinne.

Vastaukset ovat sopimuksen toinen puoli. Niiden on palattava tunnelin tai niitä varten luodun tilallisen käännöksen kautta, ja yksityisten sivustojen liikenne voi tarvita erilaista NAT-käsittelyä kuin julkinen lähtö. Pidä nämä säännöt erotettavina, koska yksi laaja käännössääntö, joka piilottaa jokaisen sisäisen lähteen, tekee myöhemmästä kirjaamisesta ja vianetsinnästä paljon vaikeammin luettavaa.

Päätä, mitä ryhmä tekee, kun tunneli putoaa

Jos keskuslähtö on vaatimus eikä mieltymys, paikalliseen WANiin palaaminen on vaatimustenmukaisuuden laiminlyönti, vaikka käyttäjät pysyisivät verkossa. SonicOS dokumentoi tunneliliitännän pudotusreitin tuetuksi tavaksi estää valittua liikennettä ottamasta tahatonta vaihtoehtoista polkua.

Sovita reitin laajuus ja prioriteetti asennettuun versioon ja testaa se pudottamalla tunneli sen sijaan, että luottaisit merkintään. Ryhmän, joka ei saa koskaan poistua paikallisesti, pitäisi epäonnistua suljetusti, kun taas ryhmä, jossa saatavuus on tärkeämpää, voi laillisesti palata; molemmat ovat päätöksiä, eikä kummankaan pitäisi tapahtua oletuksena.

Varmista kolmelta asiakkaalta ja palauta sitten siististi

Ping keskusyhdyskäytävään testaa väärää asiaa, koska se lähtee palomuurista eikä valitusta asiakkaasta. Testaa sen sijaan laitteista ja testaa kolme niistä: valittu laite, tavallinen laite, jonka pitäisi pysyä paikallisena, ja yksi, joka riippuu paikallisista palveluista.

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

Vertaile, mihin julkinen pyyntö todella nousi esiin. Valitun asiakkaan pitäisi päästä internetiin pääkonttorin lähdön kautta, ja tavallisen asiakkaan pitäisi yhä esittää sivukonttorin oma osoite kaukopuolella; 203.0.113.10 on dokumentaatio-osoite, jota käytetään sinulle tärkeän kohteen korvikkeena. Sisällytä DNS samaan kierrokseen, koska sivukonttorin resolverilta kysyvä asiakas voi tuottaa reitittimestä lähtevän kyselyn eri lähteellä ja siten eri reitillä.

Palautus on tallennettu käytäntöjärjestys plus osoiteryhmä. Palauta edellinen järjestys, poista ryhmä käytännöstä ja testaa molemmat laiteluokat uudelleen. Säilytä viety kokoonpano muutosmerkinnän kanssa, koska seuraavan insinöörin on tiedettävä, mikä sääntö oli laaja ennen kuin joku muokkasi sitä.