OpenVPN malantaŭ stunnel: plusendu la ĉirkaŭaĵon, ne la pordon 1194

Metu TLS-ĉirkaŭaĵon antaŭ OpenVPN kaj la deplojo ricevas duan aŭskultanton, el kiuj nur unu iam ajn devus fronti la interreton. Kiam la tunelo funkcias de la sama maŝino kaj malsukcesas de ekstere, la plusendo kutime celas la malĝustan el la du. Tio, kio devas kongrui, estas ĉeno: la publika regulo atingas la ĉirkaŭaĵon, kaj la propra malantaŭa konekto de la ĉirkaŭaĵo atingas la veran VPN-ingon. Kvar saltoj portas tiun ĉenon, kaj iu ajn el ili povas fini la esploron frue.

Du ingoj, du posedantoj, unu el ili publika

La ĉirkaŭaĵo finas TLS por la ekstera konekto kaj transdonas la malĉifritan bajtan fluon al ordinara OpenVPN TCP-aŭskultanto. Tiuj estas apartaj ingoj kun apartaj agordaj dosieroj, do redakti unu lasas la alian netuŝita kaj ankoraŭ ŝajne sana. Ĝi ankaŭ signifas, ke la du povas malproksimiĝi unu de la alia ĉiam, kiam unu ŝanĝiĝas sen la alia.

Labori de la maŝino mem do pruvas tre malmulte pri la publika vojo. Rekta konekto al la indiĝena pordo preterlasas la ĉirkaŭaĵon, konekto al la ĉirkaŭaĵo sur ĝia LAN-adreso preterlasas la tradukon, kaj nur la kompleta aranĝo ĉe la klienta flanko ekzercas tion, kion faras ekstera uzanto. Ankaŭ nomojn oni legu atente, ĉar localhost signifas la gastiganton, kiu rulas ĝuste tiun komponanton, kaj ne la gastiganton, sur kiu vi hazarde tajpas. Konservu tiun distingon en viaj notoj, ĉar testoj registritaj sen la salto, kiun ili kovris, invitas komparon de du malsamaj aferoj.

Kien la plusendo vere surteriĝas

La ĉenon pli facilas teni kiel kvar saltojn ol kiel tri pordnumerojn, ĉar la sama numero povas signifi malsamajn aferojn ĉe ĉiu fino. Legu la tabelon vico post vico: ĉiu vico estas unu ingo, kiu devas akcepti konekton kaj poste malfermi la sekvan. Kiam vico celas la malĝustan kunulon, la simptomo en la lasta kolumno estas tio, kion la uzanto raportas.

Regulo, kiu celas la indiĝenan VPN-pordon anstataŭ la ĉirkaŭaĵon, preterlasas la finon de TLS tute, kio estas la plej ofta versio de ĉi tiu eraro: la kliento malfermas manpremon kun aŭskultanto, kiu atendas OpenVPN-kadrigon, do la konekto povas malfermiĝi kaj poste halti. Konfirmu la tradukitan pordon kontraŭ la agorda dosiero de la ĉirkaŭaĵo anstataŭ kontraŭ memoro, ĉar la sekva persono, kiu redaktos tiun dosieron, eble elektis alian numeron. La du komandoj sube montras ambaŭ flankojn de tiu demando samtempe.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

La liga adreso, kiu rifuzas vin

Accept-linio ligita al 127.0.0.1 respondas nur la gastiganton mem, do plusendo alvenanta sur la LAN-adreson ne povas konektiĝi kaj la kliento vidas rifuzon, kiu sonas kiel problema paketfiltrilo. Rigardu la ingon antaŭ ol tuŝi la fajroŝirmilon, ĉar la ingo estas la pli malmultekosta respondo. Aŭ ligi la ĉirkaŭaĵon al la interfaco, kiun la plusendo celas, aŭ teni ĝin sur loopback kaj igi la plusendon atingi loopback per io, kio vere funkcias. Tiuj estas du dezajnoj, kaj ĉiu bezonas sian propran regulon.

Miksi ilin estas kiel funkcianta ĉirkaŭaĵo iĝas neatingebla de ekstere dum ĉiu dosiero aspektas ĝuste. La suba kontrolo estas unu komando, kaj ĝi respondas demandon, kiun revizio de la fajroŝirmilaj reguloj ne povas. Se la eligo montras loopback-adreson dum la plusendo celas la LAN-adreson, la korekto apartenas al la accept-linio kaj ne al la paketfiltrilo.

ss -lntp '( sport = :8443 )'

Kion la loka testo vere pruvis

Sukceso registrita sen la salto, kiun ĝi kovris, ne estas pruvo pri la aliaj saltoj. Notu, kiun adreson la testo uzis kaj kiu procezo respondis. Poste ripetu de ekstere de la reto anstataŭ de telefono sur la sama Wi-Fi, ĉar harpingla konduto varias inter enkursigiloj kaj konekto, kiu neniam lasis la LAN-on, povas kontentigi klienton sen ke la plusendo entute partoprenu. Nur tiu dua provo ekzercas la vojon, kiun prenas fremdulo.

Kiam la provo malsukcesas, sekvu unu konekton tra ambaŭ protokoloj: la akceptitaj kaj konektitaj linioj de la ĉirkaŭaĵo, poste la propra sesia protokolo de la VPN-demono. La unua limo, kiu registras nenion, estas kie apartenas la sekva ŝanĝo. Post kiam OpenVPN komparas kunulajn opciojn, juĝu tiujn mesaĝojn laŭ la reguloj de tiu efektivigo. Averto pri link-mtu-nekongruo ne estas aŭtomate fatala, fiksi link-mtu je 1500 ne pruvas, ke fragmentiĝo ĉesis, kaj ĉifra intertraktado apartenas al la interna OpenVPN-agordo anstataŭ al la plusendo de la enkursigilo.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Tiuj sondoj kovras la malantaŭan ingon kaj la protokolon de la ĉirkaŭaĵo, kio apartigas rifuzitan malantaŭon de rifuzita manpremo. Rulu ilin dum unu provo estas en progreso, ne poste. Tempaj markoj el unu provo estas tio, kio faras la komparon fidinda.

Du identecoj, du malsukcesaj ordoj

La ekstera atestilo apartenas al la ĉirkaŭaĵo kaj la interna identeco apartenas al OpenVPN, kaj ili povas veni de malsamaj aŭtoritatoj. Malŝalti iun ajn el la du kontroloj por igi vojon aspekti sana interŝanĝas realan protekton kontraŭ kosmetika rezulto. Konservu ambaŭ kontrolojn kaj sencimigu ilin laŭ ordo, ĉar la sinsekvo de mesaĝoj nomas la tavolon: problemo pri atestilo de la ĉirkaŭaĵo aperas antaŭ ol iu ajn VPN-opcio intertraktiĝas, dum interna identeca fiasko aperas nur post kiam la fluo establiĝis.

La manlibro de stunnel difinas accept, connect kaj klientan reĝimon precize, kaj tiuj sekcioj respondas la ingan demandon pli rapide ol divenado. Kiam vi ankoraŭ ne povas diri, kiu tavolo respondis, legu la atestilon, kiun la publika pordo prezentas, per la komando sube. Ĉirkaŭaĵa atestilo en la eligo signifas, ke la plusendo atingis la ĉirkaŭaĵon, kaj silento aŭ protokola eraro signifas, ke ĝi ne atingis. Tiu sola distingo ŝparas pli da tempo ol iu ajn alia kontrolo ĉi tie.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer