Ĉu OpenVPN LAN-aliro paneas? Kontrolu zonojn, itinerojn kaj revenan vojon

La tunelo raportas sukcesan konekton, la propra paĝo de la enkursigilo ŝarĝiĝas, kaj la diskomapo al maŝino malantaŭ ĝi ankoraŭ finiĝas per tempolimo. Nenio en tiu kombino estas kontraŭdira: la enkursigilo respondas kiel ĝi mem, kaj atingi ion malantaŭ ĝi estas alia decido farita aliloke. Trapasu la subajn kontrolojn laŭvice kaj haltu ĉe la unua malsukceso, ĉar ĉiu apogiĝas sur la antaŭa. Kiam ĉiuj kvar pasas, la paneo sidas super la tunelo, ne en ĝi.

Kiu filtrilo vidas paketon direktitan al la LAN

Paketo adresita al la enkursigilo estas konsumata loke; paketo adresita al gastiganto malantaŭ ĝi devas esti plusendita, kaj fajroŝirmiloj juĝas tiujn du kazojn aparte. Do permeso atingi la enkursigilon diras nenion pri permeso trapasi ĝin. Firmvaro, kiu kaŝas siajn regulajn arojn, tamen realigas ambaŭ, kutime kiel elektilo proponanta la LAN, la interreton aŭ ambaŭ. Se la elektilo forlasas la LAN, neniu posta kontrolo gravas.

OpenWrt faras tiun dividon inspektebla, kaj la distingo indas unu legadon. La zono, kiu finas la tunelon, bezonas plusendan regulon direktitan al la LAN-zono, dum enira regulo regas nur servojn sur la enkursigilo mem. Funkcianta administra paĝo apud mortinta LAN estas la ordinara rezulto de tiu mankanta plusenda regulo.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Rigardu la plusendan celon de la zono, kiu portas la tunelon: accept estas tio, kion la ŝtuparo bezonas, kaj reject klarigas ĉiun tempolimon sube. Du najbaraj agordoj produktas la saman simptomon, do ekskludu ilin dum vi estas ĉi tie. Sendrata izolado kaŝas dratajn gastigantojn de sendrataj klientoj, kaj enkursigilo, kiu traktas senokupajn LAN-gastigantojn kiel eksterretajn, povas forĵeti la respondojn eĉ post kiam plusendado funkcias.

Kial dividita tunelo bezonas la puŝitan prefikson

Kliento, kiu sendas ĉiun trafikon tra la tunelo, jam havas la LAN-prefikson per sia implicita itinero, do nenio aldoniĝas. Dividita tunelo estas la kazo, kiu postulas la prefikson eksplicite, ĉar nenio alia en la agordo mencias ĝin. Aldonu la direktivon al la servila agordo kaj reŝarĝu la servon.

push "route 192.168.50.0 255.255.255.0"

Profiloj enhavantaj route-nopull ignoras puŝitajn itinerojn, do la sama prefikso apartenas al la klienta dosiero anstataŭe. Ĉiuokaze konfirmu, ke la ero alvenis, anstataŭ supozi tion, ĉar silenta anstataŭigo aspektas idente al fajroŝirmila problemo.

ip route show | grep 192.168.50

Loka-al-loka kunulo petas pli ol puŝon. La servilo devas lerni, kiuj prefiksoj kuŝas malantaŭ tiu kunulo, kion faras linio iroute en ĝia client-config-dir-dosiero, kaj ĝia propra tabelo bezonas kongruan itinero en la tunelon.

La respondo bezonas adreson, kiun ĝi povas atingi

Plusendi la peton estas nur duono de interŝanĝo, ĉar la LAN-gastiganto devas respondi adreson en la tunela naĝejo. Malgrandaj enkursigiloj kutime aranĝas tion per traduko de la fonto sur la tunela zono, do la respondo estas adresita al la enkursigilo kaj bezonas neniun agordon aliloke. Forigu tiun tradukon kaj la gastiganto bezonas sian propran itinero al la naĝejo, kiun ĝi ricevas senpage kiam la enkursigilo estas ĝia implicita pordego. Gastiganto kun permane fiksita adreso kaj alia pordego respondas tra tiu pordego, kaj la kliento vidas seancon malfermiĝi kaj poste halti.

tcpdump -ni tun0 host 192.168.50.20

Rulu tion sur la enkursigilo dum la kliento ripetas sian peton, kaj legu la celon de la respondo anstataŭ de la peto mem. Respondo adresita al la naĝejo signifas, ke la reva vojo funkcias kaj la paneo estas pli interne. Neniu respondo tute signifas, ke la gastiganto neniam akceptis la paketon, kio resendas vin al la regula aro.

Ŝtuparo, kiu finiĝas en la ĝusta loko

Kvar kontroloj lokas la tavolon, kaj ĉiu estas unu komando anstataŭ juĝo. Rulu ilin laŭvice kaj haltu ĉe la unua malsukceso. La ordo gravas pli ol la komandoj, ĉar posta paŝo, kiu pasas, kaŝas la kaŭzon, kial antaŭa malsukcesis.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Nomoj apartenas al la fino de la ŝtuparo, neniam al la komenco. Kunhavigo, kiu respondas kiel 192.168.50.20 sed ne kiel nas.local, montras al nomrezolucio aŭ al serĉa sufikso, kaj fajroŝirmilaj ŝanĝoj povas ŝanĝi neniun el ili.

Notu la unuan malsukcesan paŝon, poste donu al servaj pordoj sian propran trairon, ĉar aŭskultanto kaj gastiganta permeso estas apartaj postuloj. Dosiera kunhavigo, fora labortablo kaj kameraaj fluoj bezonas ambaŭ, kaj gastiganta fajroŝirmilo, kiu fidas la LAN-subreton sed ne la tunelan naĝejon, forĵetas la klienton dum ping ankoraŭ sukcesas. Kiam ĉiuj kontroloj pasas kaj la aplikaĵo ankoraŭ malsukcesas, la paneo estas super la tunelo: servo ligita al unu interfaco, aŭ prokurilo agordita sur la kliento.