Enkursigi unu filian subreton tra la SonicWall-reteliro de la ĉefsidejo
Elektu filian fontogrupon, akceptu ĝin en la tunela politiko, traduku ĉe la centra WAN, poste testu tri klientojn. Vojo sola ne kreas enirejon.
Filiaj telefonoj devus eliri tra la ĉefsidejo dum filiaj tekkomputiloj daŭre uzas la lokan WAN, kaj la enkursiga politiko sola ne liveros tion. Filia vojo povas elekti la tunelon, sed la tunela politiko devas akcepti la trafikon, la ĉefsidejo devas plusendi kaj traduki ĝin, kaj la respondo devas reveni laŭ la sama vojo. Manku iu ajn el tiuj tri kaj la simptomo estos subaro de klientoj, kiuj perdas interreton ĝuste dum la tunelo estas aktiva.
Komencu per la elektilo, ne per la vojo
Enkursiga politiko kongruas laŭ fonto, do la fonto devas esti stabila antaŭ ĉio alia. Metu la elektitajn aparatojn en adresgrupon, kiun administranto prizorgas, aŭ pli bone, en dediĉitan segmenton, kies membreco sekvas la rolon de la aparato. Kiam ordinara DHCP-ŝanĝiĝo povas movi kongruan adreson al alia maŝino, la politiko silente elektas la malĝustan klienton, kaj la unua raporto kutime temas pri malrapida retumado, kiu fakte estas ĉirkaŭvojo.
Nomu la grupon laŭ la politiko, kiun ĝi servas, ne laŭ etaĝo aŭ fako, ĉar la enkursiga regulo postvivos ambaŭ. Notu, kiuj aparatoj estas en ĝi kaj kiu rajtas aldoni unu.
Aldonu la filian politikon, poste defendu ĝian ordon
Ĉe la filia SonicWall enkursiga politiko elektas la fontogrupon, nomas la celatajn celojn kaj agordas la tunelan interfacon kiel enirejon, kio estas ĝuste por kio ekzistas la subtenata tunelinterfaca dezajno. Tenu regulojn por lokaj kaj privataj celoj super la larĝa interreta regulo, ĉar la unua kongruo gajnas, kaj privata prefikso puŝita en la tunelon alvenas al la ĉefsidejo nur por esti forĵetita. Konservu ankaŭ la propran vojon de la fajroŝirmilo al ĝia VPN-partnero, alie la tunela transporto sekvos la politikon, de kiu ĝi dependas. Nenio el tio devigas vin konverti ĉiun ekzistantan politikbazitan tunelon; tunela interfaco estas unu subtenata elekto inter pluraj.
La ordo estas la parto, kiu ŝanĝiĝas akcidente. Ĉiu, kiu aldonas escepton, devas enmeti ĝin super la larĝa regulo, kaj ĉiu, kiu redaktas la larĝan regulon, povas renversi la tutan dezajnon per unu konservo. Skribu la celatan ordon apud la politiko kaj rekontrolu ĝin post firmvara ĝisdatigo, ĉar interfaca nomado kaj politika bildigo ja ŝanĝiĝas inter eldonoj.
Finu la vojon ĉe la ĉefsidejo
La tunela politiko ĉe la ĉefsidejo devas akcepti la trafikon, kiun la filia vojo nun elektas. Interofica elektilo limigita al la privata LAN de la ĉefsidejo ne estas permeso porti arbitrajn publikajn celojn, do la politiko bezonas la filian fonton kaj la celan intervalon, kiun vi efektive intencas. La ĉefsidejo poste plusendas tiun alvenantan trafikon al sia interreta suprenligo laŭ siaj propraj alirreguloj, kaj la ekzemplo de centra eliro de SonicWall inkluzivas fontotradukon por la malproksima reto ĉe la centra WAN. Sen tiu traduko la malproksima flanko vidas privatan filian adreson kaj havas neniun vojon reen al ĝi.
Respondoj estas la alia duono de la kontrakto. Ili devas reveni tra la tunelo aŭ tra la stata traduko kreita por ili, kaj trafiko al privataj retejoj eble bezonas alian NAT-traktadon ol publika eliro. Tenu tiujn regulojn distingeblaj, ĉar unu larĝa traduka regulo, kiu kaŝas ĉiun internan fonton, faras postan registradon kaj problemserĉadon multe pli malfacile legeblaj.
Decidu, kion la grupo faras kiam la tunelo falas
Se la centra eliro estas postulo kaj ne prefero, reveno al la loka WAN estas konformeca malsukceso eĉ se uzantoj restas enrete. SonicOS dokumentas forĵetan tunelinterfacan vojon kiel la subtenatan manieron malhelpi al elektita trafiko preni neintencitan alternativan vojon.
Kongruigu la amplekson kaj prioritaton de tiu vojo sub la instalita eldono, kaj testu ĝin mallevante la tunelon anstataŭ fidi la etikedon. Grupo, kiu neniam rajtas eliri loke, devus malsukcesi fermite, dum grupo, kie disponebleco pli gravas, rajte povas retroiri; ambaŭ estas decidoj, kaj neniu devus okazi defaŭlte.
Kontrolu el tri klientoj, poste restarigu pure
Ping al la centra enirejo testas la malĝustan aferon, ĉar ĝi originas ĉe la fajroŝirmilo kaj ne ĉe elektita kliento. Testu el aparatoj anstataŭe, kaj testu tri el ili: elektitan aparaton, ordinaran aparaton, kiu devus resti loka, kaj unu, kiu dependas de lokaj servoj.
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
Komparu, kie la publika peto efektive aperis. Elektita kliento devus atingi la interreton tra la eliro de la ĉefsidejo, kaj ordinara kliento devus ankoraŭ prezenti la propran adreson de la filio ĉe la malproksima flanko; 203.0.113.10 estas dokumentada adreso uzata kiel anstataŭaĵo por la celo, pri kiu vi zorgas. Inkluzivu DNS en la sama paŝo, ĉar kliento, kiu demandas la filian solvilon, povas produkti serĉon originantan de la enkursigilo kun alia fonto kaj tial alia vojo.
Restarigo estas la konservita politika ordo plus la adresgrupo. Restarigu la antaŭan ordon, forigu la grupon el la politiko, kaj retestu ambaŭ klasojn de aparatoj. Konservu la eksportitan agordon kun la ŝanĝregistro, ĉar la sekva inĝeniero bezonas scii, kiu regulo estis la larĝa antaŭ ol iu redaktis ĝin.