Malfermi la VPN-pordon ne donas al klientoj aliron al la LAN

La tunelo ekfunkcias, la kliento aŭtentikiĝas, sed la LAN malantaŭ la enirejo restas nevidebla. La regulo, kiu devus tion ripari, permesas la VPN-pordon kaj funkcias ĝuste kiel skribite, ĉar tiu regulo regas pakaĵojn adresitajn al la enirejo mem. Klienta trafiko al gastigo malantaŭ la enirejo havas alian celon kaj alian ĉenon. Sukcesa ensaluto ne ŝanĝas, kiun el la du ĉenoj la kerno konsultas.

Du ĉenoj, du malsamaj celoj

La sorton de pakaĵo decidas kien ĝi iras, ne kiel ĝi alvenis. Trafiko al adreso sur la enirejo estas liverata loke kaj taksata laŭ enigaj reguloj. Trafiko, kiun la enirejo plusendas, estas taksata laŭ plusendaj reguloj. La sama tunela interfaco povas produkti ambaŭ specojn de pakaĵoj, do unu regulo ne povas kovri ambaŭ taskojn.

La tuta mito en unu frazo: permesi la aŭskultanton diras nenion pri permesi la reton malantaŭ ĝi. Temas pri du apartaj decidoj kun apartaj pruvoj, kaj interfaca nomo sur ambaŭ ne kunigas ilin.

Kion la regulo de la aŭskultanto vere permesas

Pakaĵoj de la aŭskultanto finiĝas en la VPN-procezo, kaj ĝuste tio ebligas starigi la tunelon. La administra paĝo de la enirejo kaj loka diagnoza respondo ankaŭ uzas la propran enigan vojon de la gastiganto, do provo al la enirejo sukcesas dum ĉio malantaŭ ĝi malsukcesas. Ambaŭ rezultoj estas ĝustaj kaj neniu temas pri la LAN.

Kiam la procezo malkapsuligas klientan trafikon por alia celo, la pakaĵo eniras la plusendan vojon kaj bezonas permeson tie. Sukcesa aŭtentikigo decidas, kiu estas la kliento; ĝi ne decidas, kien la kliento rajtas iri. La du demandoj havas malsamajn posedantojn, malsamajn protokolojn kaj malsamajn erarmesaĝojn.

Testu de kliento, neniam de la enirejo

Provo farita sur la enirejo sekvas la propran eligan vojon de la gastiganto kaj povas sukcesi dum la plusenda vojo estas fermita. Komencu la provon de la kliento kaj observu ambaŭ finojn de la fluo.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Se la peto aperas sur tun0 kaj nenio atingas la celon, la pakaĵo estas forĵetata post alveno, kio montras al plusendaj reguloj aŭ al la propra filtrado de la celo. Se nenio aperas sur tun0, la kliento eĉ ne sendas ĝin al la tunelo, kaj la problemo estas vojigo sur la kliento anstataŭ politiko sur la enirejo. Komparu tion kun peto, kiu eliras ĝuste kaj revenigas nenion, kio estas la kazo de la revena vojo.

Plusendado bezonas tri aferojn, ne unu

Plusendado en la kerno devas esti ŝaltita, filtrila regulo devas akcepti la fluon, kaj la celo devas esti atingebla kun vojo por la reveno de la respondo. Se mankas unu el la tri, la silento estas la sama el la vidpunkto de la kliento.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Legu la tri eligojn kune. Nulo en la unua igas la aliajn du negravaj, kaj implicita forĵeta politiko en la dua forĵetas la pakaĵojn de la kliento dum la propra trafiko de la enirejo daŭre funkcias. La tria eligo montras, kial la regulo de la aŭskultanto neniam estis la problemo.

Tenu la du regulajn arojn aparte en la dokumentaro

Skribu la regulon de la aŭskultanto kaj la regulon de la plusendata servo sur apartaj linioj, kun apartaj posedantoj kaj kialoj. Kiam la VPN-pordo ŝanĝiĝas aŭ nova servo publikiĝas, tiu apartigo malhelpas, ke unu ŝanĝo silente larĝigos la alian.

Anstataŭ trakti ĉiun aŭtentikigitan partneron kiel fidindan LAN-membron, uzu mallarĝajn regulojn por la klientaj gamoj kaj servoj, kiuj bezonas ilin. La notoj pri plusendado de StrongSwan priskribas la flankon de revena vojo kaj tradukado de la sama limo, kio denove estas tria decido.

Fine, tenu la tavolojn rektaj, kiam uzanto estas rifuzata. Se la peto atingas la gastiganton kaj la aplikaĵo rifuzas la konton, riparu la permeson de la aplikaĵo sur tiu tavolo; larĝigo de plusendado ne povas doni akreditaĵon por dosiera kunhavigo kaj larĝigos aliron por ĉiuj aliaj, kiuj sukcese konektiĝas.