OpenVPN töötab kodus, aga ühes võrgus mitte: UDP või TCP?

Sama profiil ühendub kodus ja jääb hotelli-, ülikoolilinnaku või filiaali võrgus seisma. Kasutajatunnused ei muutunud, seega huvitav muutuja on tee: mis juhtub pakettidega enne, kui OpenVPN need loeb. Nelja võimaliku põhjuse võrdlemine selles järjekorras, milles neid saab testida, on parem kui sertifikaatide üle oletada. Igaüks jätab erineva jälje ja just jälg eristab neid.

See, milline etapp ebaõnnestus, näitab, milline võrdlus loeb

Kliendi logi registreerib juba, kui kaugele jõudsid. Rida, mis ütleb, et TLS-võtme läbirääkimine ei toimunud aja jooksul, tähendab, et esimene pakett lahkus ja midagi kasutatavat ei tulnud tagasi, mis osutab teele. Sertifikaadi tagasilükkamine näeb hoopis teistsugune välja: vastus saabub, seejärel nimetab konkreetne kontrollimise viga põhjuse. Pange tähele viimast rida enne korduskatse tsüklit, sest just see väärtus on see, mida te võrkude vahel võrdlete.

Salvestage korduskatse ajal, mitte pärast. Kliendis näitab tcpdump -ni any udp port 1194, kas üldse mõni vastus tagasi tuleb. Korrake seda serveri WAN-liidesel, mida te kontrollite, mis näitab, kas need paketid üldse kaugeimasse otsa jõuavad.

Ühepoolne liiklus on siin saadaolev kõige kasulikum tulemus, sest see muudab hootise kaebuse uurimissuunaks. Hoidke salvestusfailid alles, sest järgmine sama probleemi raport on tõenditega lihtsam sulgeda kui kirjeldusega.

UDP filtreerimine vs suletud port

Paljud juurdepääsuvõrgud peavad püsivat UDP-d kahtlaseks ja mõned teenusepakkujad nõustuvad nendega. Suletud port tekitab kliendi poolelt sama vaikuse. Erinevus on valivuses: filter kipub olema valiv selles, milliseid sihtkohti või porte see maha viskab, samas kui suletud port keeldub kõigest, mis on suunatud sellele ühele pordile.

TCP-profiil pordil 443 on tavaline lahendus, sest see sarnaneb tavalise HTTPS-vooluga ja läbib enamiku captive-portaale ja väljundfiltreid. Kaks tingimust peavad kehtima. Server peab kuulama koos proto tcp-server ja klient peab sobima koos proto tcp-client ning operaator peab selle alternatiivse lõpp-punkti avaldama. Töötava UDP-profiili ümberkirjutamine, et väita TCP 443, ei vii kuhugi, kui teises otsas ei kuula keegi.

Suletud port on konfiguratsiooniprobleem, mitte tsensuuriprobleem. Koduruuteri taga olev server vajab oma UDP-pordi edasisaatmist ja ruuteri tulemüür peab selle lubama. Kui porti ei lubatud kunagi, ebaõnnestub iga klient läbirääkimisel sõltumata kasutajatunnustest ja tõrge järgib serverit, mitte võrku.

Vanemad protokollid on sellel teljel halvasti võrreldavad. PPTP vajab TCP 1723 pluss GRE-d ja GRE on IP-protokoll 47, mitte port, seega ei väljenda seda ükski tavaline pordi edasisaatmine.

Kui pakette viskab maha hoopis kommutaator

Hallatav kommutaator võib tunnelit meelega maha visata. Mõned HPE ja Aruba mudelid pakuvad oma täiustatud turvalisuse jaotises UDP üleujutuskaitse juhtelementi, mõnikord sildiga Prevent UDP Blat Attack. Kui see juhtelement on aktiivne, ei vasta kommutaatori taga olev server millelegi ja iga klient lõpeb aegumisega ühtemoodi. Selle väljalülitamine ja jooksva konfiguratsiooni salvestamine on kogu parandus, kuid alles pärast seda, kui olete kindlaks teinud, et kommutaator on tõesti teel.

Vastutõendid on see, mis eristab kommutaatori mahaviskamist teenusepakkuja blokeeringust. Lugege liidese loendureid ja üleujutuskaitse logi enne, kui avate teenusepakkujale pileti. Tarbijaruuterid DoS- või üleujutuskaitsega ebaõnnestuvad samamoodi ja sama teeb iga vahesein lühikese UDP jõudeaja piiranguga. Käepigistus, mis ei lõpe kunagi, viitab mahaviskamisele, samas kui tunnel, mis sureb pärast minuteid vaikust, viitab aegumisele.

Kirjutage üles iga seade kliendi ja serveri vahel enne profiili muutmist. Valel kihil rakendatud parandus näib õige kuni järgmise võrguni. See nimekiri ütleb ka järgmisele insenerile, kuhu vaadata, ilma kogu uurimist kordamata.

Aadresside kattumine, mis näeb välja nagu DNS-i tõrge

Juurdepääsuvõrk, mis on nummerdatud vahemikus 10.0.0.0/8, võib kattuda tunnelipooliga ja resolver elab tavaliselt selle pooli sees. Kui sülearvuti saab Wi-Fi-s /8 maskiga aadressi nagu 10.184.178.50, on iga 10.x sihtkoht definitsiooni järgi kohalik. Paketid 10.4.0.1 jaoks lähevad siis LAN-i, tunnel jääb püsti ja nimeresolutsioon ebaõnnestub.

ip addr paljastab kattumise ühe pilguga ja ip route get 10.4.0.1 näitab, kuhu pakett tegelikult toimetataks. Kuna nähtav sümptom on resolveri tõrge, jääb see sageli ellu mitmest DNS-i muudatuste voorust.

Nummerdage pool uuesti või hoidke see juurdepääsuvõrk skoobist väljas. Ükski kliendipoolne säte ei taastu kattumisest.

Otsus varu-TCP ja tee parandamise vahel

Valige varu-TCP, kui te ei kontrolli teed ja kasutajad peavad täna töötama, ning nõustuge selle kuludega: TCP TCP sees käitub kadudega linkidel halvasti ja varulahendus vajab kuulajat, mida te ise haldate. Valige tee parandamine, kui blokeering asub teie omanduses olevas taristus, sest tulemüüri reegel on odavam kui teine kuulaja. Igal juhul käige kihid järjest läbi: link, välimine transport, läbirääkimine, sisemine marsruutimine. Etapp, mis selles võrgus ebaõnnestus, on ainus oluline fakt.

Registreerige tulemus võrgu, mitte kasutaja kaupa. Sama tõrke järgmine raport algab siis teadaolevast etapist, mitte sertifikaaditeooriast. See kirje õigustab ka alalist teist kuulajat, kui seda kunagi vaja läheb.