OpenVPN sur 443 ankoraŭ blokata? Kontrolu, kion la reto inspektas

La tunelo konektiĝas el hejma linio kaj haltas en hotelo aŭ oficeja reto, kaj la movo de la servilo al pordo 443 ŝanĝis nenion. Tiu rezulto estas sufiĉe ofta por havi formon: la pordo estis la facila parto, kaj la resto de la decido apartenas al ĉio, kio staras inter la kliento kaj la servilo. Du demandoj solvas la plej multajn kazojn, kaj neniu el ili temas pri ĉifroj. Ĉu la reto akceptas TLS-manpremon al tiu adreso, kaj ĉu la kliento konservas itineron al sia propra volvaĵo dum la tunelo estas supre?

La manpremo malkaŝas pli ol la numero

Denaska VPN-aŭskultanto sur TCP 443 parolas sian propran protokolon ekde la unua pako. ClientHello havas kampon de versio, hazardan valoron kaj liston de etendoj, kaj aparato, kiu legas kelkcent bajtojn, povas distingi la diferencon sen malĉifri ion ajn. Pordaj numeroj estas malmultekostaj kontentigeblaj, kaj la formo de la protokolo estas tio, kion la filtrilo efektive kontrolas. Reguloj kutime estas skribataj ankaŭ laŭprotokole, do politiko, kiu inspektas TLS, diras nenion pri UDP.

Travidebla prokurilo, kiu insistigas validan TLS-sesion, faligas la konekton dum la agordo, ofte post kiam la TCP-manpremo kompletiĝis. Tiu detaleto gravas poste, ĉar ĝi signifas, ke la klienta registro haltas post kiam la ingo estas starigita.

Volvi la fluon kreas du fiaskpunktojn

TLS-volvaĵo kiel stunnel restarigas la atendatan formon: la kliento konektiĝas al loka aŭskultanto, la volvaĵo malfermas veran TLS-sesion al la servilo sur 443, kaj dua volvaĵo sur la servilo plusendas la malĉifritajn bajtojn al la VPN-demono. La ekstera sesio nun aspektas kiel iu ajn alia HTTPS-konekto. La VPN-demono sur la servilo devus aŭskulti nur sur loopback, ĉar nenio ekster la volvaĵo bezonas atingi ĝin.

Tri apartaj aferoj devas kongrui por tiu dezajno. La klienta profilo montras al la loka aŭskultanto, la servila atestilo kongruas kun la nomo, kiun la kliento kontrolas, kaj la plusendo ĉe la servila flanko celas la pordon, kiun la demono vere uzas. Eraru pri iu ajn el ili kaj la konekto mortas antaŭ ol atingi la VPN-tavolon. Tiam atestila malkongruo aperas kiel volvaĵa eraro anstataŭ VPN-eraro, kaj tial indas legi ambaŭ registrojn flanke unu de la alia.

La itinero al la volvaĵo estas la kaptilo

Post kiam la tunelo leviĝas, la defaŭlta itinero montras enen, kaj la ekstera TLS-sesio bezonas vojon, kiu ne eniras la tunelon, kiun ĝi portas. Ordinara VPN-kliento protektas la adreson, kiun ĝi vokas; volvita kliento vokas sian propran loopback, do la celloka adreso de la volvaĵo estas nevidebla por tiu protekto.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

La precizajn adresojn vi plenigas, kaj la itinero devas ekzisti dum la tuta vivo de la konekto, ne nur ĉe lanĉo. Malgranda volvaĵa skripto, kiu aldonas la itineron antaŭ la kliento kaj forigas ĝin poste, estas pli fidinda ol memorata komando.

Sur Android, la ekvivalento de tiu escepto estas agordo po aplikaĵo: ekskludu la volvaĵan aplikaĵon el la tunelo, por ke ĝia propra trafiko eliru per la poŝa konekto. Sen la ekskludo la volvaĵo estas enitinigita en la tunelon, kiun ĝi provas konstrui, kaj la rekonekta buklo aspektas kiel servila problemo.

Legu la tempor antaŭ ol ŝanĝi ion

Sesio, kiu mortas post la sama intervalo ĉiufoje, estas politika signo kaj ne kriptografia fiasko, kaj longdaŭraj fluaj limoj produktas ĝuste tiun ŝablonon. Konekto, kiu restariĝas tuj post la manpremo, sugestas prokurilon, kiu ne ŝatis la atestilan ĉenon.

Komparu la atestilan eldoniston de ordinara HTTPS-ejo el ambaŭ retoj. Se la eldonisto diferencas en la limigita reto, io finas TLS en la mezo, kaj neniu volvaĵo postvivos tiun interkapton senŝanĝe. La sama komparo diras al vi, ĉu la blokado celas vian servilan nomon aŭ ĉiun TLS-sesion ĉe tiu adreso.

Skribu la observitan konduton: kiom longe la sesio daŭris, ĉu la ingo malfermiĝis, ĉu la volvaĵo registris manpremon. Ĉiu el tiuj mallarĝigas la sekvan teston.

Testu unu variablon samtempe

Kontrolu UDP unue, ĉar iuj retoj tute faligas ĝin kaj UDP-fiasko diras nenion pri 443. Poste provu TCP 443 sen la volvaĵo, poste la volvaĵon sur 443. Legu la klientan registron ĉe ĉiu paŝo kaj haltu tuj kiam la konduto ŝanĝiĝas.

Ŝanĝu unu elementon po provo. Nova pordo, nova volvaĵo kaj nova ĉifro en la sama rondo lasas vin nekapabla diri, kiu el la tri gravis.