OpenVPN fungerer hjemme men ikke på ett nettverk: UDP eller TCP?
Ett nettverk blokkerer tunnelen og et annet gjør det ikke. Sammenlign UDP-filtrering, flomvern på switchen, en TCP 443-reservevei og en kollisjon i adresseplanen.
Den samme profilen kobler til hjemme og stopper på et hotell-, campus- eller filialnettverk. Innloggingen er ikke endret, så den interessante variabelen er veien: hva som skjer med pakkene før OpenVPN leser dem. Å sammenligne fire mulige årsaker i den rekkefølgen de kan testes i, er bedre enn å gjette på sertifikater. Hver av dem etterlater et ulikt spor, og det er sporet som skiller dem.
Hvilket trinn som sviktet avgjør hvilken sammenligning som betyr noe
Klientloggen registrerer allerede hvor langt du kom. En linje som sier at TLS-nøkkelforhandlingen ikke skjedde innen tidsgrensen, betyr at en første pakke gikk ut og ingenting brukbart kom tilbake, noe som peker på veien. En sertifikatavvisning ser helt annerledes ut: et svar kommer, og deretter navngir en bestemt verifiseringsfeil grunnen. Noter den siste linjen før gjentakelsesløkken, for det er verdien du sammenligner mellom nettverk.
Fang mens du prøver på nytt, ikke etterpå. På klienten viser tcpdump -ni any udp port 1194 om det i det hele tatt kommer noe svar tilbake. Gjenta det på WAN-grensesnittet til en server du styrer, noe som avdekker om disse pakkene i det hele tatt når den fjerne enden.
Ensidig trafikk er det nyttigste resultatet som finnes her, fordi det gjør en periodisk klage om til en retning å undersøke. Ta vare på fangstfilene, for neste melding om samme problem er lettere å lukke med bevis enn med en beskrivelse.
UDP-filtrering mot en lukket port
Mange tilgangsnettverk ser på vedvarende UDP som mistenkelig, og noen ISP-er er enige. En lukket port lager samme stillhet fra klientsiden. Forskjellen er selektivitet: et filter er ofte kresen på hvilke mål eller porter det slipper, mens en lukket port avviser alt som er rettet mot den porten.
En TCP-profil på port 443 er den vanlige løsningen, fordi den ligner en vanlig HTTPS-strøm og går gjennom de fleste captive-portaler og utgangsfiltre. To vilkår må gjelde. Serveren må lytte med proto tcp-server og klienten må samsvare med proto tcp-client, og operatøren må publisere det alternative endepunktet. Å skrive om en fungerende UDP-profil til å hevde TCP 443 kommer ingen vei når ingenting lytter på den andre siden.
En lukket port er et konfigurasjonsproblem, ikke et sensurproblem. En server bak en hjemmeruter trenger at UDP-porten blir videresendt, og brannmuren på ruteren må tillate det. Når porten aldri var tillatt, feiler hver klient i forhandlingen uansett innlogging, og feilen følger serveren i stedet for nettverket.
Eldre protokoller står dårlig i denne sammenligningen. PPTP trenger TCP 1723 pluss GRE, og GRE er IP-protokoll 47, ikke en port, så vanlig portvideresending uttrykker det ikke.
Når det er switchen som slipper pakkene
En styrt switch kan slippe tunnelen med vilje. Noen HPE- og Aruba-modeller har en UDP-flomvernkontroll, av og til merket Prevent UDP Blat Attack, i den avanserte sikkerhetsdelen. Når den kontrollen er aktiv, svarer en server bak switchen på ingenting og hver klient går i tidsavbrudd på samme måte. Å slå den av og lagre den kjørende konfigurasjonen er hele reparasjonen, men bare etter at du har fastslått at switchen faktisk er i veien.
Motbevis er det som skiller et switch-slipp fra en leverandørblokkering. Les grensesnitttellerne og flomvernloggen før du åpner en sak hos ISP-en. Forbrukerrutere med DoS- eller flomvern feiler i samme form, og det samme gjør enhver mellomvare med kort UDP-tomgangstid. En håndtrykk som aldri fullføres tyder på et slipp, mens en tunnel som dør etter noen minutters stillhet tyder på tidsgrensen.
Skriv opp hver enhet mellom klienten og serveren før du endrer en profil. En rettelse lagt på feil lag ser riktig ut til neste nettverk. Den listen forteller også den neste ingeniøren hvor han skal se uten å gjenta hele undersøkelsen.
Et adresseoverlapp som ser ut som en DNS-feil
Et tilgangsnett nummerert innenfor 10.0.0.0/8 kan overlappe tunnelpoolen, og resolvere bor vanligvis i den poolen. Når en laptop får en adresse som 10.184.178.50 med /8-maske på Wi-Fi, er hver 10.x-destinasjon lokal per definisjon. Pakker til 10.4.0.1 går da til LAN-et, tunnelen holder seg oppe, og navneoppslag feiler.
ip addr viser overlappet med et øyekast, og ip route get 10.4.0.1 viser hvor pakken egentlig ville bli levert. Fordi det synlige symptomet er en resolverfeil, overlever dette ofte flere runder med DNS-endringer.
Nummerer poolen på nytt eller hold det tilgangsnettet utenfor omfanget. Ingen klientinnstilling retter opp et overlapp.
Å velge mellom TCP-reservevei og veiretting
Velg TCP-reserveveien når du ikke styrer veien og brukerne trenger å jobbe i dag, og godta kostnadene: TCP inne i TCP oppfører seg dårlig på linjer med tap, og reserveveien trenger en lytter du driver. Velg veirettingen når blokkeringen ligger på infrastruktur du eier, fordi en brannmurregel er billigere enn en andre lytter. Uansett, gå gjennom lagene i rekkefølge: lenke, ytre transport, forhandling, indre ruting. Trinnet som sviktet i det nettverket er det eneste faktumet som betyr noe.
Registrer resultatet per nettverk og ikke per bruker. Neste melding om samme feil starter da på et kjent trinn i stedet for på en sertifikatteori. Den registreringen er også det som begrunner en permanent andre lytter, om en noen gang trengs.