OpenVPN fungerer heime men ikkje i eitt nett: UDP eller TCP?

Den same profilen koplar til heime og stoppar i eit hotell-, campus- eller filialnett. Innlogginga er ikkje endra, så den interessante variabelen er vegen: kva som skjer med pakkane før OpenVPN les dei. Å samanlikne fire moglege årsaker i den rekkjefølgja dei kan testast i, er betre enn å gjette på sertifikat. Kvar av dei etterlèt eit ulikt spor, og det er sporet som skil dei.

Kva steg som svikta avgjer kva samanlikning som tel

Klientloggen registrerer alt kor langt du kom. Ei line som seier at TLS-nøkkelforhandlinga ikkje skjedde innan tidsgrensa, tyder at ein første pakke gjekk ut og ingenting brukande kom attende, noko som peikar på vegen. Ei sertifikatavvising ser heilt annleis ut: eit svar kjem, og deretter namngir ein bestemt verifiseringsfeil grunnen. Noter den siste lina før attprøvingsløkka, for det er verdien du samanliknar mellom nett.

Fang medan du prøver på nytt, ikkje etterpå. På klienten viser tcpdump -ni any udp port 1194 om det kjem noko svar attende i det heile. Gjenta det på WAN-grensesnittet til ein server du styrer, noko som avdekkjer om desse pakkane når den fjerne enden i det heile.

Einsidig trafikk er det nyttigaste resultatet som finst her, fordi det gjer ei periodisk klage om til ei retning å granske. Ta vare på fangstfilane, for neste melding om same problemet er lettare å lukke med bevis enn med ei skildring.

UDP-filtrering mot ein stengd port

Mange tilgangsnett ser på varig UDP som mistenkjeleg, og nokre ISP-ar er samde. Ein stengd port lagar same stilla frå klientsida. Skilnaden er selektivitet: eit filter er ofte kresen på kva mål eller portar det slepp, medan ein stengd port avviser alt som er retta mot den porten.

Ein TCP-profil på port 443 er den vanlege løysinga, fordi han liknar ein vanleg HTTPS-straum og går gjennom dei fleste captive-portalar og utgangsfilter. To vilkår må gjelde. Serveren må lytta med proto tcp-server og klienten må samsvare med proto tcp-client, og operatøren må publisere den alternative endepunktet. Å skrive om ein fungerande UDP-profil til å hevde TCP 443 kjem ingen veg når ingenting lyttar på hi sida.

Ein stengd port er eit konfigurasjonsproblem, ikkje eit sensurproblem. Ein server bak ein heimeruttar treng at UDP-porten blir vidaresend, og brannmuren på rutaren må tillate det. Når porten aldri var tillaten, feilar kvar klient i forhandlinga uansett innlogging, og feilen følgjer serveren i staden for nettet.

Eldre protokollar står dårleg i denne samanlikninga. PPTP treng TCP 1723 pluss GRE, og GRE er IP-protokoll 47, ikkje ein port, så vanleg portvidaresending uttrykkjer det ikkje.

Når det er switchen som slepp pakkane

Ein styrt switch kan sleppe tunnelen med vilje. Nokre HPE- og Aruba-modellar har ein UDP-flaumvernkontroll, av og til merkt Prevent UDP Blat Attack, i den avanserte tryggingsdelen. Når den kontrollen er aktiv, svarar ein server bak switchen på ingenting og kvar klient går i tidsavbrot på same måte. Å slå han av og lagre den køyrande konfigurasjonen er heile reparasjonen, men berre etter at du har fastslått at switchen faktisk er i vegen.

Motbevis er det som skil eit switch-slepp frå ein leverandørblokk. Les grensesnittteljarane og flaumvernloggen før du opnar ein sak hos ISP-en. Forbrukarrutarar med DoS- eller flaumvern feilar i same form, og det same gjer kvar mellomboks med kort UDP-tomgangstid. Ei handtrykking som aldri blir fullført tyder på eit slepp, medan ein tunnel som døyr etter nokre minutt i stilla tyder på tidsgrensa.

Skriv opp kvar eining mellom klienten og serveren før du endrar ein profil. Ei retting lagt på feil lag ser rett ut til neste nett. Den lista fortel òg den neste ingeniøren kvar han skal sjå utan å gjenta heile granskinga.

Eit adresseoverlapp som ser ut som ein DNS-feil

Eit tilgangsnett nummerert innanfor 10.0.0.0/8 kan overlappe tunnelpoolen, og resolvaren bur vanlegvis i den poolen. Når ein laptop får ei adresse som 10.184.178.50 med /8-maske på Wi-Fi, er kvar 10.x-destinasjon lokal per definisjon. Pakkar til 10.4.0.1 går då til LAN-et, tunnelen held seg oppe, og namneoppløysing feilar.

ip addr syner overlappet med eit augnekast, og ip route get 10.4.0.1 syner kvar pakken verkeleg ville bli levert. Fordi det synlege symptomet er ein resolverfeil, overlever dette ofte fleire rundar med DNS-endringar.

Nummerer poolen på nytt eller hald det tilgangsnettet utanfor omfanget. Ingen klientinnstilling rettar opp eit overlapp.

Å velje mellom TCP-reserveveg og vegretting

Vel TCP-reservevegen når du ikkje styrer vegen og brukarane treng å arbeide i dag, og godta kostnadene: TCP inne i TCP oppfører seg dårleg på linjer med tap, og reservevegen treng ein lyttar du driv. Vel vegrettinga når blokkeringa ligg på infrastruktur du eig, fordi ein brannmurregel er billegare enn ein andre lyttar. Same kva, gå gjennom laga i rekkjefølgje: lenkje, ytre transport, forhandling, indre ruting. Steget som svikta i det nettet er det einaste faktumet som tel.

Registrer resultatet per nett og ikkje per brukar. Neste melding om same feilen byrjar då på eit kjent steg i staden for på ein sertifikatteori. Den registreringa er òg det som grunngir ein permanent andre lyttar, om ein nokon gong trengst.