VPN-klientoj kaj la loka reto: kiam uzi apartan zonon

Meti la tunelan interfacon en la zonon de la loka reto estas la plej mallonga vojo al funkcianta VPN, kaj ĝi kutime estas la malĝusta defaŭlto. Ĝi donas al la fora kliento la saman fidon kiel la drata loka reto, kion la tasko malofte postulas. Aparta zono kostas kelkajn regulojn kaj igas la limon videbla. La decido ne estas ĉu zonoj estas pli bonaj; ĝi estas kiuj tri kondiĉoj validas por via reto.

La nomo de la zono kriptas nenion kaj aŭtentigas neniun uzanton. Ĝi nur grupigas interfacojn por la politika modelo de la fajroŝirmilo.

Kion zoneco efektive regas

Zono grupigas interfacojn aŭ trafikon en la modelo de la fajroŝirmilo. Ĝiaj agordoj por eniro, eliro kaj plusendado tiam regas malsamajn rolojn. Eniro estas trafiko al la enkursigilo mem; plusendado estas trafiko tra ĝi al alia gastiganto. La zona dokumentaro de OpenWrt traktas eniron, eliron kaj plusendadon kiel apartajn agordojn ĝuste pro tiu kaŭzo.

Permeso de la VPN-zono al la loka zono ne estas aŭtomate inversa permeso. Plusendaj reguloj estas laŭdirektaj, kaj regulo, kiu permesas trafikon de kliento al servilo, ne permesas seancojn de servilo al kliento. Kliento, kiu povas malfermi konekton al servilo, ne estas kliento, al kiu la servilo povas malfermi konekton reen.

Tiu distingo estas la kaŭzo, kial aparta zono utilas: vi povas eksplicite deklari ĉiun direkton kaj ĉiun rolon. Skribu la direkton apud ĉiu regulo.

Decido unu: eniro, plusendado aŭ ambaŭ

Se foraj klientoj bezonas DNS de la enkursigilo, permesu eniron nur por tiu servo. Se ili bezonas atingi dosier-servilon, permesu plusendadon al tiu celo. Plej multaj VPN-dezajnoj bezonas ambaŭ, sed por malsamaj servoj.

Vasta enira aliro al ĉiu loka servo preskaŭ neniam necesas. Traktu administradon de la enkursigilo kiel apartan decidon de aplikaĵa aliro. Se la enkursigilo nur bezonas respondi pri DNS, skribu tiun ununuran permeson kaj lasu la reston fermita.

Decido du: kiujn rimedojn foraj klientoj bezonas

Listigu la klientajn gamojn, la celojn kaj la servojn, kiujn la VPN provizu, antaŭ ol skribi regulojn. Listo de celoj pli utilas ol fida etikedo, ĉar ĝi postvivas fajroŝirmilan migradon.

Tenu administrajn interfacojn apartaj de ordinara aplikaĵa aliro. Fora kliento, kiu povas atingi vikion, tial ne bezonas la administran paĝon de la enkursigilo aŭ la konzolon de la hipervizoro.

Se permesita celo povas plusendi plu, la zona limo haltas ĉe la fajroŝirmilo, ne ĉe tio, kion la celo faras poste.

Decido tri: kiel vi pruvos la limon

Post ĉiu ŝanĝo testu permesitan fluon kaj unu intence rifuzitan. Pruvi, ke unu retejo ŝarĝiĝas, ne malkaŝas neintencitan vastan permeson. Testu el la adresgamo de la VPN-kliento, ne el la loka reto, kaj inkluzivu la direkton, kiun vi atendas malsukcesi. Notu ambaŭ rezultojn apud la regulo.

Konservu la reakiran aliron de la pordego antaŭ ol ŝanĝi la politikon de la fora zono. Uzu la daŭran administritan agordon anstataŭ ŝanĝojn dum funkciado, alie la sekva restarto restarigos la malnovan fidon. Kopio de la antaŭa agordo, konservita ekster la aparato, estas la plej malmultekosta retroigo, kiun vi iam havos.

Kiam la reto kreskas, dokumentu econ kaj la celon de la reguloj. Nove alligita interfaco ne devas heredi privilegiojn nur ĉar iu donis al ĝi oportunan nomon de zono.