OpenVPN funkcias hejme sed ne en unu reto: UDP aŭ TCP?

La sama profilo konektiĝas hejme kaj haltas en hotela, kampusa aŭ filia reto. La legitimiloj ne ŝanĝiĝis, do la interesa variablo estas la vojo: kio okazas al la pakaĵoj antaŭ ol OpenVPN legas ilin. Kompari kvar eblajn kaŭzojn laŭ la ordo en kiu oni povas testi ilin superas divenadon pri atestiloj. Ĉiu lasas alian spuron, kaj la spuro estas tio, kio apartigas ilin.

Kiun etapon malsukcesis montras, kiu komparo gravas

La klienta protokolo jam registras kiom malproksimen vi iris. Linio diranta, ke la TLS-ŝlosila intertraktado ne okazis ene de la tempolimo, signifas ke unua pakaĵo eliris kaj nenio uzebla revenis, kio montras al la vojo. Atestila malakcepto aspektas tute alie: respondo alvenas, poste specifa validiga eraro nomas la kialon. Notu la lastan linion antaŭ la ripeta buklo, ĉar tio estas la valoro, kiun vi komparas inter retoj.

Kaptu dum la ripeto, ne poste. Ĉe la kliento, tcpdump -ni any udp port 1194 montras ĉu iu ajn respondo revenas entute. Ripetu tion ĉe la WAN-interfaco de servilo, kiun vi kontrolas, kio malkaŝas ĉu tiuj pakaĵoj entute atingas la malproksiman finon.

Unuflanka trafiko estas la plej utila rezulto havebla ĉi tie, ĉar ĝi transformas intermitan plendon en direkton por esplori. Konservu la kaptajn dosierojn, ĉar la sekva raporto pri la sama problemo pli facile fermiĝas per pruvoj ol per priskribo.

UDP-filtrado kontraŭ fermita pordo

Multaj aliraj retoj rigardas daŭran UDP kiel suspektindan, kaj iuj provizantoj konsentas. Fermita pordo produktas la saman silenton de la klienta flanko. La diferenco estas selektemo: filtro emas esti postulema pri kiuj celoj aŭ pordoj ĝi forĵetas, dum fermita pordo rifuzas ĉion celantan tiun unu pordon.

TCP-profilo ĉe pordo 443 estas la kutima solvo, ĉar ĝi similas ordinaran HTTPS-fluon kaj trapasas plej multajn kaptitajn portalojn kaj elirajn filtrilojn. Du kondiĉoj devas validi. La servilo devas aŭskulti kun proto tcp-server kaj la kliento devas kongrui kun proto tcp-client, kaj la operatoro devas publikigi tiun alternativan finpunkton. Reskribi funkciantan UDP-profilon por aserti TCP 443 kondukas nenie, kiam ĉe la alia fino neniu aŭskultas.

Fermita pordo estas agorda problemo, ne cenzura problemo. Servilo malantaŭ hejma enkursigilo bezonas plusenditan UDP-pordon, kaj la fajroŝirmilo de la enkursigilo devas permesi ĝin. Kiam la pordo neniam estis permesita, ĉiu kliento malsukcesas ĉe la intertraktado sendepende de legitimiloj, kaj la fiasko sekvas la servilon anstataŭ la reton.

Pli malnovaj protokoloj kompariĝas malbone laŭ tiu ĉi akso. PPTP bezonas TCP 1723 plus GRE, kaj GRE estas IP-protokolo 47, ne pordo, do neniu ordinara pordplusendo esprimas ĝin.

Kiam la ŝaltilo estas tiu, kiu faligas pakaĵojn

Administrita ŝaltilo povas intence faligi la tunelon. Iuj modeloj HPE kaj Aruba prezentas regilon de protekto kontraŭ UDP-inundo, foje etikeditan Prevent UDP Blat Attack, en sia sekcio pri altnivela sekureco. Post kiam tiu regilo estas aktiva, servilo malantaŭ la ŝaltilo respondas nenion kaj ĉiu kliento tempolimas same. Malŝalti ĝin kaj konservi la kurantan agordon estas la tuta riparo, sed nur post kiam vi konstatas, ke la ŝaltilo efektive estas sur la vojo.

Kontraŭevidentaĵo estas tio, kio apartigas ŝaltilan faligon de provizanta blokado. Legu la interfacajn nombrilojn kaj la protokolon de inunda protekto antaŭ ol malfermi bileton ĉe la provizanto. Konsumantaj enkursigiloj kun DoS aŭ inunda protekto malsukcesas same, kaj same ĉiu meza skatolo kun mallonga UDP-senaktiva tempolimo. Manpremo, kiu neniam finiĝas, sugestas faligon, dum tunelo, kiu mortas post minutoj da silento, sugestas la tempolimon.

Notu ĉiun aparaton inter la kliento kaj la servilo antaŭ ol ŝanĝi profilon. Riparo aplikita ĉe la malĝusta tavolo aspektas ĝusta ĝis la sekva reto. Tiu listo ankaŭ diras al la sekva inĝeniero, kie rigardi sen ripeti la tutan esploron.

Adresa interkovro, kiu aspektas kiel DNS-fiasko

Alira reto numerita ene de 10.0.0.0/8 povas interkovri la tunelan basenon, kaj la solvilo kutime loĝas ene de tiu baseno. Kiam tekokomputilo ricevas adreson kiel 10.184.178.50 kun /8-masko en Wi-Fi, ĉiu 10.x-celo estas loka laŭ difino. Pakaĵoj por 10.4.0.1 tiam iras al la LAN, la tunelo restas supre, kaj nomsolvado malsukcesas.

ip addr malkaŝas la interkovron per unu rigardo, kaj ip route get 10.4.0.1 montras, kie la pakaĵo vere estus liverita. Ĉar la videbla simptomo estas solvila fiasko, ĉi tiu ofte postvivas plurajn raŭndojn de DNS-ŝanĝoj.

Renumeru la basenon aŭ tenu tiun aliran reton ekster la amplekso. Neniu klientflanka agordo resaniĝas de interkovro.

Decidi inter rezerva TCP kaj vojriparo

Elektu la rezervan TCP kiam vi ne kontrolas la vojon kaj uzantoj devas labori hodiaŭ, kaj akceptu ĝiajn kostojn: TCP ene de TCP kondutas malbone sur perdkonektitaj ligoj, kaj la rezervo bezonas aŭskultanton, kiun vi funkciigas. Elektu la vojriparon kiam la blokado kuŝas sur infrastrukturo, kiun vi posedas, ĉar fajroŝirmila regulo estas pli malmultekosta ol dua aŭskultanto. Ĉiukaze trairu la tavolojn laŭ ordo: ligo, ekstera transporto, intertraktado, interna enkursigado. La etapo, kiu malsukcesis en tiu reto, estas la sola fakto, kiu gravas.

Registru la rezulton laŭ reto, ne laŭ uzanto. La sekva raporto pri la sama fiasko tiam komenciĝas de konata etapo anstataŭ de atestila teorio. Tiu registro ankaŭ pravigas daŭran duan aŭskultanton, se iam necesos.