OpenVPN virker derhjemme men ikke på ét netværk: UDP eller TCP?

Den samme profil forbinder derhjemme og går i stå på et hotel-, campus- eller filialnetværk. Legitimationsoplysningerne er ikke ændret, så den interessante variabel er ruten: hvad der sker med pakkerne, før OpenVPN læser dem. At sammenligne fire mulige årsager i den rækkefølge, de kan testes i, slår at gætte på certifikater. Hver efterlader et forskelligt spor, og sporet er det, der adskiller dem.

Hvilket trin der fejlede, viser hvilken sammenligning der betyder noget

Klientloggen registrerer allerede, hvor langt du nåede. En linje om, at TLS-nøgleforhandlingen ikke fandt sted inden for tidsgrænsen, betyder, at en første pakke forlod og intet brugbart kom tilbage, hvilket peger på ruten. En certifikatafvisning ser helt anderledes ud: et svar ankommer, og derefter navngiver en specifik verifikationsfejl årsagen. Bemærk den sidste linje før genforsøgsløkken, for det er den værdi, du sammenligner på tværs af netværk.

Optag, mens du genforsøger, ikke bagefter. På klienten viser tcpdump -ni any udp port 1194, om der overhovedet kommer et svar tilbage. Gentag det på WAN-interfacet på en server, du kontrollerer, hvilket afslører, om disse pakker overhovedet når den fjerne ende.

Ensidig trafik er det mest nyttige resultat, der findes her, fordi det gør en periodisk klage til en retning at undersøge. Gem optagelsesfilerne, for den næste rapport om samme problem lukkes lettere med bevis end med en beskrivelse.

UDP-filtrering kontra en lukket port

Mange adgangsnetværk anser vedvarende UDP for mistænkeligt, og nogle udbydere er enige. En lukket port giver samme tavshed fra klientens side. Forskellen er selektivitet: et filter er tilbøjeligt til at være kræsen med, hvilke destinationer eller porte det dropper, mens en lukket port afviser alt rettet mod den ene port.

En TCP-profil på port 443 er den sædvanlige omvej, fordi den ligner et almindeligt HTTPS-flow og passerer de fleste captive-portaler og udgangsfiltre. To betingelser skal være opfyldt. Serveren skal lytte med proto tcp-server, og klienten skal matche med proto tcp-client, og operatøren skal offentliggøre det alternative endepunkt. At skrive en fungerende UDP-profil om til at påstå TCP 443 fører ingen vegne, når intet lytter i den anden ende.

En lukket port er et konfigurationsproblem snarere end et censurproblem. En server bag en hjemmerouter skal have videresendt sin UDP-port, og routerens firewall skal tillade det. Når porten aldrig blev tilladt, fejler hver klient ved forhandlingen uanset legitimationsoplysninger, og fejlen følger serveren i stedet for netværket.

Ældre protokoller klarer sig dårligt på denne akse. PPTP kræver TCP 1723 plus GRE, og GRE er IP-protokol 47 og ikke en port, så ingen almindelig portvideresendelse udtrykker det.

Når det er switchen, der dropper pakker

En administreret switch kan droppe tunnelen med vilje. Nogle HPE- og Aruba-modeller har en UDP-oversvømmelsesbeskyttelse, af og til mærket Prevent UDP Blat Attack, i deres avancerede sikkerhedssektion. Når den kontrol er aktiv, svarer en server bag switchen intet, og hver klient løber ud i det samme. At slå den fra og gemme den kørende konfiguration er hele reparationen, men først efter at du har fastslået, at switchen faktisk er på ruten.

Modbeviser er det, der adskiller et switch-drop fra en udbyderblokering. Læs interface-tællerne og oversvømmelsesbeskyttelsesloggen, før du åbner en sag hos udbyderen. Forbrugerroutere med DoS- eller oversvømmelsesbeskyttelse fejler på samme måde, og det gør enhver mellemboks med en kort UDP-inaktivitetsgrænse også. Et håndtryk, der aldrig fuldføres, tyder på et drop, mens en tunnel, der dør efter minutter i stilhed, tyder på tidsgrænsen.

Skriv hver enhed mellem klienten og serveren ned, før du ændrer en profil. En rettelse anvendt på det forkerte lag ser rigtig ud indtil det næste netværk. Listen fortæller også den næste ingeniør, hvor der skal kigges, uden at gentage hele undersøgelsen.

Et adresseoverlap, der ligner en DNS-fejl

Et adgangsnetværk nummereret inden for 10.0.0.0/8 kan overlappe tunnelpoolen, og resolveren bor normalt i den pool. Når en bærbar får en adresse som 10.184.178.50 med en /8-maske på Wi-Fi, er hver 10.x-destination lokal per definition. Pakker til 10.4.0.1 går så til LAN, tunnelen bliver oppe, og navneopløsningen fejler.

ip addr afslører overlappet ved et blik, og ip route get 10.4.0.1 viser, hvor pakken reelt ville blive leveret. Fordi det synlige symptom er en resolverfejl, overlever denne ofte flere runder med DNS-ændringer.

Omnummerér poolen, eller hold det adgangsnetværk uden for rækkevidde. Ingen klientindstilling retter op på et overlap.

At vælge mellem TCP-fallback og en ruterettelse

Vælg TCP-fallback, når du ikke styrer ruten, og brugerne skal arbejde i dag, og accepter omkostningerne: TCP inde i TCP opfører sig dårligt på tabsgivende links, og fallback kræver en lytter, du selv driver. Vælg ruterettelsen, når blokeringen sidder på infrastruktur, du ejer, fordi en firewallregel er billigere end en ekstra lytter. Under alle omstændigheder, gå gennem lagene i rækkefølge: link, ydre transport, forhandling, indre routing. Det trin, der fejlede på det netværk, er det eneste faktum, der betyder noget.

Registrér resultatet pr. netværk i stedet for pr. bruger. Den næste rapport om samme fejl starter så ved et kendt trin i stedet for ved en certifikatteori. Den registrering er også det, der retfærdiggør en permanent ekstra lytter, hvis en sådan nogensinde er nødvendig.