Egy fióktelepi alhálózat átirányítása a központi SonicWall internetes kimenetén
Válasszon fióktelepi forráscsoportot, fogadja el az alagút-szabályzatban, fordítsa a központi WAN-nál, majd teszteljen három klienst. Egy útvonal önmagában nem hoz létre átjárót.
A fióktelepi telefonoknak a központon keresztül kell kijutniuk, miközben a fióktelepi laptopok továbbra is a helyi WAN-t használják, és az útválasztási szabályzat önmagában nem fogja ezt megadni. Egy fióktelepi útvonal kiválaszthatja az alagutat, de az alagút-szabályzatnak el kell fogadnia a forgalmat, a központnak továbbítania és fordítania kell, és a válasznak ugyanazon az úton kell visszatérnie. Ha bármelyik hiányzik a háromból, a tünet azon ügyfelek egy részhalmaza lesz, akik pontosan akkor veszítik el az internetet, amikor az alagút aktív.
Kezdje a választóval, ne az útvonallal
Az útválasztási szabályzat forrás alapján illeszt, ezért a forrásnak minden más előtt stabilnak kell lennie. Helyezze a kiválasztott eszközöket egy adminisztrátor által karbantartott címcsoportba, vagy még jobb, egy dedikált szegmensre, amelynek tagsága az eszköz szerepét követi. Amikor a szokásos DHCP-váltás egy illeszkedő címet másik gépre mozgathat, a szabályzat csendben a rossz ügyfelet választja, és az első bejelentés általában lassú böngészésről szól, amely valójában egy kerülőút.
A csoportot a szolgált szabályzatról nevezze el, ne egy emeletről vagy osztályról, mert az útválasztási szabály mindkettőnél tovább él. Jegyezze fel, mely eszközök vannak benne, és ki adhat hozzá egyet.
Adja hozzá a fióktelepi szabályzatot, majd védje meg a sorrendjét
A fióktelepi SonicWallon az útvonal-szabályzat kiválasztja a forráscsoportot, megnevezi a szándékolt célokat és átjáróként állítja be az alagút-interfészt, pontosan erre való a támogatott alagút-interfész kialakítás. Tartsa a helyi és magáncélú szabályokat a széles internetszabály felett, mert az első egyezés nyer, és az alagútba tolt magán-előtag csak azért érkezik meg a központba, hogy eldobják. Őrizze meg a tűzfal saját útvonalát a VPN-partneréhez is, különben az alagút szállítása követni fogja azt a szabályzatot, amelytől függ. Mindez nem kényszeríti arra, hogy minden meglévő szabályzatalapú alagutat átalakítson; az alagút-interfész egy támogatott választás több közül.
A sorrend az a rész, amely véletlenül változik. Aki kivételt ad hozzá, annak a széles szabály fölé kell beszúrnia, és aki a széles szabályt szerkeszti, egyetlen mentéssel megfordíthatja az egész tervet. Írja le a szándékolt sorrendet a szabályzat mellé, és firmware-frissítések után ellenőrizze újra, mert az interfészek elnevezése és a szabályzatok megjelenítése valóban változik a verziók között.
Fejezze be az utat a központban
A központi alagút-szabályzatnak el kell fogadnia azt a forgalmat, amelyet a fióktelepi útvonal most kiválaszt. A központ magán-LAN-jára korlátozott irodák közötti választó nem engedély tetszőleges nyilvános célok szállítására, ezért a szabályzatnak szüksége van a fióktelepi forrásra és a valóban szándékolt cél-tartományra. A központ ezután saját hozzáférési szabályai szerint továbbítja a beérkező forgalmat internetes uplinkjére, és a SonicWall központi kimenet példája tartalmazza a távoli hálózat forrásfordítását a központi WAN-nál. E fordítás nélkül a távoli oldal egy magán fióktelepi címet lát, és nincs visszaútvonal hozzá.
A válaszok a szerződés másik fele. Vagy az alagúton, vagy a számukra létrehozott állapottartó fordításon keresztül kell visszatérniük, és a magánwebhelyek forgalma más NAT-kezelést igényelhet, mint a nyilvános kimenet. Tartsa ezeket a szabályokat megkülönböztethetően, mert egyetlen széles fordítási szabály, amely minden belső forrást elrejt, sokkal nehezebben olvashatóvá teszi a későbbi naplózást és hibakeresést.
Döntse el, mit tesz a csoport, amikor az alagút leesik
Ha a központi kimenet követelmény és nem preferencia, a helyi WAN-ra való visszaesés megfelelőségi hiba, akkor is, ha a felhasználók online maradnak. A SonicOS dokumentálja az alagút-interfész eldobásával járó útvonalat mint a támogatott módot arra, hogy a kiválasztott forgalom ne vegyen nem szándékolt alternatív útvonalat.
Igazítsa az útvonal hatókörét és prioritását a telepített kiadáshoz, és tesztelje az alagút leengedésével a címke helyett. Egy csoportnak, amelynek soha nem szabad helyben kijutnia, zártan kell meghibásodnia, míg egy csoport, ahol a rendelkezésre állás fontosabb, jogszerűen visszaeshet; mindkettő döntés, és egyik sem történhet alapértelmezés szerint.
Ellenőrizze három ügyféltől, majd állítsa vissza tisztán
A központi átjáróra küldött ping a rossz dolgot teszteli, mert a tűzfalból indul ki, nem egy kiválasztott ügyfélből. Teszteljen inkább eszközökről, és teszteljen hármat közülük: egy kiválasztott eszközt, egy közönséges eszközt, amelynek helyben kell maradnia, és egyet, amely helyi szolgáltatásoktól függ.
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
Hasonlítsa össze, hol bukkant fel valójában a nyilvános kérés. Egy kiválasztott ügyfélnek a központ kimenetén keresztül kell elérnie az internetet, és egy közönséges ügyfélnek a távoli oldalon továbbra is a fióktelep saját címét kell mutatnia; a 203.0.113.10 egy dokumentációs cím, amelyet az Ön számára fontos cél helyettesítőjeként használnak. Vegye bele a DNS-t ugyanabba a menetbe, mert a fióktelepi feloldót kérdező ügyfél az útválasztóból származó lekérdezést hozhat létre más forrással és ezért más útvonallal.
A visszaállítás a mentett szabályzatsorrend plusz a címcsoport. Állítsa vissza az előző sorrendet, távolítsa el a csoportot a szabályzatból, és tesztelje újra mindkét eszközosztályt. Őrizze meg az exportált konfigurációt a változásrekorddal, mert a következő mérnöknek tudnia kell, melyik szabály volt a széles, mielőtt valaki szerkesztette.