OpenVPN werk tuis maar nie op een netwerk nie: UDP of TCP?

Dieselfde profiel maak tuis verbinding en stok op 'n hotel-, kampus- of taknetwerk. Die geloofsbriewe het nie verander nie, so die interessante veranderlike is die pad: wat met die pakkies gebeur voordat OpenVPN dit lees. Om vier moontlike oorsake te vergelyk in die volgorde waarin hulle getoets kan word, is beter as om te raai by sertifikate. Elkeen laat 'n ander spoor, en die spoor is wat hulle onderskei.

Watter fase gefaal het, sê watter vergelyking saak maak

Die kliëntlogboek teken reeds aan hoe ver jy gekom het. 'n Reël wat sê TLS-sleutelonderhandeling het nie binne die tydperk plaasgevind nie, beteken 'n eerste pakkie het vertrek en niks bruikbaars het teruggekom, wat op die pad wys. 'n Sertifikaatverwerping lyk heeltemal anders: 'n antwoord kom aan, dan noem 'n spesifieke verifikasiemfout die rede. Let op die laaste reël voor die herprobeer-lus, want dit is die waarde wat jy oor netwerke vergelyk.

Neem op terwyl jy herprobeer, nie daarna nie. Op die kliënt wys tcpdump -ni any udp port 1194 of enige antwoord hoegenaamd terugkom. Herhaal dit op die WAN-koppelvlak van 'n bediener wat jy beheer, wat onthul of daardie pakkies die verre kant hoegenaamd bereik.

Eensydige verkeer is die nuttigste resultaat wat hier beskikbaar is, want dit verander 'n ongereelde klagte in 'n rigting om te ondersoek. Hou die opname-lêers, want die volgende berig oor dieselfde probleem is makliker om met bewyse af te sluit as met 'n beskrywing.

UDP-filtering teenoor 'n geslote poort

Baie toegangsnetwerke beskou aanhoudende UDP as verdag, en sommige ISP's stem saam. 'n Geslote poort veroorsaak dieselfde stilte van die kliënt se kant. Die verskil is selektiwiteit: 'n filter is geneig om kieskeurig te wees oor watter bestemmings of poorte dit laat val, terwyl 'n geslote poort alles weier wat op daardie een poort gemik is.

'n TCP-profiel op poort 443 is die gewone oplossing, want dit lyk soos 'n gewone HTTPS-vloei en kom deur die meeste captive-portale en uitgangsfilters. Twee voorwaardes moet geld. Die bediener moet met proto tcp-server luister en die kliënt moet met proto tcp-client ooreenstem, en die operateur moet daardie alternatiewe eindpunt publiseer. Om 'n werkende UDP-profiel te herskryf om TCP 443 voor te gee, bereik niks wanneer niks aan die ander kant luister nie.

'n Geslote poort is 'n konfigurasieprobleem eerder as 'n sensuurprobleem. 'n Bediener agter 'n tuisroeteerder het sy UDP-poort nodig om deurgestuur te word, en die roeteerder se vuurmuur moet dit toelaat. Wanneer die poort nooit toegelaat is nie, faal elke kliënt by onderhandeling ongeag geloofsbriewe, en die fout volg die bediener eerder as die netwerk.

Ouer protokolle vaar swak op hierdie as. PPTP benodig TCP 1723 plus GRE, en GRE is IP-protokol 47 eerder as 'n poort, so geen gewone poortdeurstroming druk dit uit nie.

Wanneer dit die skakelaar is wat pakkies laat val

'n Bestuurde skakelaar kan die tonnel doelbewus laat val. Sommige HPE- en Aruba-modelle het 'n beheer vir UDP-vloedbeskerming, soms gemerk Prevent UDP Blat Attack, in hul gevorderde sekuriteit-afdeling. Sodra daardie beheer aktief is, antwoord 'n bediener agter die skakelaar niks en elke kliënt hou op dieselfde manier op. Om dit te verwyder en die lopende konfigurasie te stoor, is die hele herstel, maar eers nadat jy vasgestel het dat die skakelaar werklik in die pad is.

Teenbewyse is wat 'n skakelaar-val onderskei van 'n verskaffer-blok. Lees die koppelvlak-tellers en die vloedbeskerming-log voor jy 'n kaartjie by die ISP oopmaak. Verbruikersroeteerders met DoS- of vloedbeskerming faal op dieselfde manier, en so ook enige middelboks met 'n kort UDP-onaktiwiteitstydperk. 'n Handdruk wat nooit voltooi nie wys op 'n val, terwyl 'n tonnel wat ná minute van stilte sterf op die tydperk wys.

Skryf elke toestel tussen die kliënt en die bediener neer voordat jy 'n profiel verander. 'n Regstelling wat op die verkeerde laag toegepas is, lyk korrek tot die volgende netwerk. Daardie lys sê ook vir die volgende ingenieur waar om te kyk sonder om die hele ondersoek te herhaal.

'n Adresoorvleueling wat soos 'n DNS-fout lyk

'n Toegangsnetwerk wat binne 10.0.0.0/8 genommer is, kan die tonnelpoel oorvleuel, en die resolveerder woon gewoonlik binne daardie poel. Wanneer 'n skootrekenaar 'n adres soos 10.184.178.50 met 'n /8-masker op Wi-Fi kry, is elke 10.x-bestemming per definisie plaaslik. Pakkies vir 10.4.0.1 gaan dan na die LAN, die tonnel bly op, en naamresolusie faal.

ip addr ontbloot die oorvleueling met een oogopslag, en ip route get 10.4.0.1 wys waar die pakkie werklik afgelewer sou word. Omdat die sigbare simptoom 'n resolveerder-fout is, oorleef hierdie een dikwels verskeie rondtes DNS-veranderings.

Hernommer die poel of hou daardie toegangsnetwerk buite die bestek. Geen kliëntkant-instelling herstel van 'n oorvleueling nie.

Om te besluit tussen 'n TCP-terugval en 'n padregstelling

Kies die TCP-terugval wanneer jy nie die pad beheer nie en gebruikers vandag moet werk, en aanvaar sy koste: TCP binne TCP gedra hom sleg op verliesryke skakels, en die terugval het 'n luisteraar nodig wat jy bedryf. Kies die padregstelling wanneer die blok op infrastruktuur sit wat jy besit, want 'n vuurmuurreël is goedkoper as 'n tweede luisteraar. Werk in elk geval deur die lae in orde: skakel, buitenste vervoer, onderhandeling, binnenste roetering. Die fase wat op daardie netwerk gefaal het, is die enigste feit wat saak maak.

Teken die resultaat per netwerk aan eerder as per gebruiker. Die volgende berig oor dieselfde fout begin dan by 'n bekende fase eerder as by 'n sertifikaatteorie. Daardie aantekening is ook wat 'n permanente tweede luisteraar regverdig, as een ooit nodig is.