Bideratu adar azpisare bat egoitza nagusiko SonicWall-eko internet irteeratik

Adarreko telefonoek egoitza nagusitik atera beharko lukete, adarreko eramangarriek WAN lokala erabiltzen jarraitzen duten bitartean, eta bideratze-politikak bakarrik ez du hori lortuko. Adar bide batek tunela aukera dezake, baina tunelaren politikak trafikoa onartu behar du, egoitza nagusiak birbidali eta itzuli egin behar du, eta erantzunak bide beretik itzuli behar du. Hiru horietako edozein huts egiten baduzu, sintoma tunela martxan dagoen bitartean internet galtzen duten bezeroen azpimultzoa izango da.

Hasi hautatzailearekin, ez bidearekin

Bideratze-politikak iturburu baten arabera egiten du bat, beraz iturburuak egonkorra izan behar du beste ezer baino lehen. Jarri hautatutako gailuak administratzaile batek mantentzen duen helbide-talde batean edo, hobe, gailuaren rolari jarraitzen dion segmentu dedikatu batean. DHCP aldaketa arruntak bat datorren helbidea beste makina batera eraman dezakeenean, politikak isilki bezero okerra hautatzen du, eta lehen txostena normalean nabigazio geldoari buruzkoa izaten da, benetan ingurubidea dena.

Taldea zerbitzatzen duen politikaren arabera izendatu, ez solairu edo sail baten arabera, bideratze-arauak biak bizirik iraungo baititu. Idatzi zein gailu dauden bertan eta nork gehi dezakeen bat.

Gehitu adarreko politika, eta gero defendatu haren ordena

Adarreko SonicWall-en bide-politika batek iturburu-taldea hautatzen du, xede diren helmugak izendatzen ditu eta tunel-interfazea atebide gisa ezartzen du, horretarako baitago onartutako tunel-interfazearen diseinua. Mantendu helmuga lokal eta pribatuen arauak internet arau zabalaren gainetik, lehen bat-etortzeak irabazten baitu eta tunelera bultzatutako aurrizki pribatu bat egoitza nagusira iristen baita baztertua izateko soilik. Gorde firewallaren beraren bidea bere VPN parekidearekiko, bestela tunelaren garraioak depende duen politikari jarraituko dio. Horietako ezerk ez zaitu behartzen lehendik dagoen politika bidezko tunel guztiak bihurtzera; tunel-interfazea hainbat aukeren artean onartutako bat da.

Ordea da ustekabean aldatzen den zatia. Salbuespen bat gehitzen duenak arau zabalaren gainean txertatu behar du, eta arau zabala editatzen duenak diseinu osoa irauli dezake gordetze bakar batekin. Idatzi nahi den ordena politikaren ondoan eta berrikusi firmware eguneratzeen ondoren, interfazeen izendapena eta politiken errendatzea bertsioen artean aldatzen baitira.

Amaitu bidea egoitza nagusian

Egoitza nagusiko tunel-politikak adar bideak orain hautatzen duen trafikoa onartu behar du. Egoitza nagusiko LAN pribatura mugatutako bulego arteko hautatzaile bat ez da helburu publiko arbitrarioak eramateko baimena, beraz politikak adarreko iturburua eta benetan nahi dituzun helmugen barrutia behar ditu. Egoitza nagusiak gero iristen den trafiko hori bere sarbide-arauen arabera birbidaltzen du bere internet loturara, eta SonicWall-en irteera zentralaren adibideak urruneko sarearen iturburu-itzulpena barne hartzen du WAN zentralean. Itzulpen hori gabe urruneko aldeak adarreko helbide pribatu bat ikusten du eta ez du hara itzultzeko biderik.

Erantzunak kontratuaren beste erdia dira. Tuneletik edo haientzako sortu den egoera-itzulpenetik itzuli behar dute, eta gune pribatuen trafikoak NAT tratamendu desberdina behar izan dezake irteera publikoaren aldean. Mantendu arau horiek bereizgarri, barneko iturburu guztiak ezkutatzen dituen itzulpen-arau zabal batek geroagoko erregistroa eta arazoen konponketa askoz irakurtzeko zailagoak egiten baititu.

Erabaki zer egiten duen taldeak tuneleak behera egiten duenean

Irteera zentrala lehentasuna ez baizik baldintza bada, WAN lokalera itzultzea betetze-huts egitea da erabiltzaileak linean egon arren. SonicOSek tunel-interfazea uzten duen bide bat dokumentatzen du trafiko hautatuak nahi gabeko bide alternatibo bat hartzea eragozteko modu onartu gisa.

Bateratu bide horren irismena eta lehentasuna instalatutako bertsioarekin, eta probatu tunela jaitsiz etiketan fidatu beharrean. Inoiz lokalki atera behar ez duen talde batek itxita huts egin beharko luke, eskuragarritasunak gehiago axola duen talde batek legitoki atzera egin dezakeen bitartean; biak erabakiak dira, eta batek ere ez luke lehenespenez gertatu behar.

Egiaztatu hiru bezerorengandik, eta gero itzuli garbi

Zentraleko atebidera egindako ping-ak gauza okerra probatzen du, firewall-etik abiatzen baita, eta ez hautatutako bezero batetik. Proba ezazu gailuetatik, eta probatu horietako hiru: hautatutako gailu bat, lokal mantendu behar duen gailu arrunt bat, eta zerbitzu lokaletatik dependitzen duen bat.

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

Konparatu non agertu zen benetan eskaera publikoa. Hautatutako bezero batek internet-era iritsi beharko luke egoitza nagusiko irteeratik, eta bezero arrunt batek adarreko helbidea bera erakutsi beharko luke urruneko aldean; 203.0.113.10 dokumentaziorako helbide bat da, axola zaizun helmugaren ordezkari gisa erabiltzen dena. Sartu DNS proba berean, adarreko resolver-ari galdetzen dion bezero batek routerretik sortutako bilaketa bat sor baitezake iturburu desberdinarekin eta, beraz, bide desberdinarekin.

Itzultzea gordetako politika-ordena gehi helbide-taldea da. Berrezarri aurreko ordena, kendu taldea politikatik, eta probatu berriro bi gailu motak. Gorde esportatutako konfigurazioa aldaketaren erregistroarekin, hurrengo ingeniariek jakin behar baitute zein arau zen zabala norbaitiek editatu aurretik.