OpenVPN funktionéiert doheem, awer net an engem Netzwierk: UDP oder TCP?

Dee selwechte Profil verbënnt sech doheem a stockt an engem Hotel-, Campus- oder Filialnetzwierk. D'Authentifikatioun huet sech net geännert, also ass déi interessant Variabel de Wee: wat geschitt mat de Paketen, ier OpenVPN se liest. Véier méiglech Ursaachen an der Rei ze vergläichen, wéi se getest kënne ginn, ass besser wéi beim Zertifikat ze roden. Jiddwereen hannerléisst eng aner Spuer, an d'Spuer ass et, wat se trennt.

Wéi eng Etapp versot huet, seet, wéi ee Verglach wichteg ass

De Client-Log hält schonn fest, wéi wäit s du komm bass. Eng Zeil, déi seet, datt d'TLS-Schlësselverhandlung net bannent dem Timeout geschitt ass, heescht, datt en éischte Paket fortgaang ass an näischt Brauchbares zréckkomm ass, wat op de Wee weist. Eng Zertifikats-Ablehnung gesäit ganz anescht aus: eng Äntwert kënnt, duerno nennt e bestëmmte Verifikatiounsfehler den Grond. Notéier déi lescht Zeil virun der Retry-Schleif, well dat ass de Wäert, deen s du tëschent Netzwierker vergläichs.

Capture beim Widderhuelen an net duerno. Um Client weist tcpdump -ni any udp port 1194, ob iwwerhaapt eng Äntwert zréckkënnt. Widderhuel et op der WAN-Schnëttstell vun engem Server, deen s du kontrolléiers, wat weist, ob dës Paketen iwwerhaapt bis un de wäiten Enn kommen.

Eensäitegen Trafik ass hei dat nëtzlechst Resultat, well et eng intermittéierend Plainte an eng Richtung fir d'Enquête verwandelt. Hal d'Capture-Fichieren, well de nächste Rapport vum selwechte Problem léiwer mat Beweiser wéi mat enger Beschreiwung zougemaach gëtt.

UDP-Filterung géint en zouenen Port

Vill Access-Netzwierker gesinn duerchhalenden UDP als verdächteg un, an e puer ISP'en sinn der selwechter Meenung. En zouenen Port produzéiert déiselwecht Stille vun der Clientsäit. Den Ënnerscheed ass d'Selektivitéit: e Filter ass dacks heikel, wéi eng Destinatiounen oder Porte en eraushëlt, während en zouenen Port alles refuséiert, wat op dee Port geriicht ass.

E TCP-Profil op Port 443 ass de übleche Wierkrank, well et engem normale HTTPS-Floss gläicht an duerch déi meescht Captive-Portalen an Egress-Filter kënnt. Zwee Konditioune mussen erfëllt sinn. De Server muss mat proto tcp-server lauschteren an de Client muss mat proto tcp-client iwwereneenkommen, an den Bedreiwer muss deen alternativen Endpunkt publizéieren. En funktionéierende UDP-Profil ëmschreiwen, fir TCP 443 ze behaapten, bréngt näischt, wann um aneren Enn näischt lauschtert.

En zouenen Port ass e Konfiguratiounsproblem an net e Zensurproblem. E Server hannert engem Heemrouter brauch seng UDP-Portweiderleedung, an d'Router-Firewall muss se erlaben. Wann de Port ni erlaabt gouf, versoe all Client bei der Verhandlung onofhängeg vun den Authentifikatiounen, an de Feeler follegt dem Server an net dem Netzwierk.

Eeler Protokoller vergläiche sech op dëser Achs schlecht. PPTP brauch TCP 1723 plus GRE, a GRE ass IP-Protokoll 47 an net e Port, also kann eng normal Portweiderleedung et net ausdrécken.

Wann de Switch deen ass, deen d'Pakete fale léisst

En geréierten Switch kann den Tunnel bewosst fale loossen. E puer HPE- an Aruba-Modeller bidden eng UDP-Flood-Schutzkontroll un, heiansdo als Prevent UDP Blat Attack bezeechent, an hirem erweiderten Sécherheetsberäich. Soubal déi Kontroll aktiv ass, äntwert e Server hannert dem Switch op näischt an all Client leeft op déiselwecht Manéier an den Timeout. Se läschen an d'Lafend Konfiguratioun späicheren ass déi ganz Reparatur, awer eréischt nodeems s du séchergestallt hues, datt de Switch wierklech um Wee ass.

Géigebeweiser sinn et, wat e Switch-Fall vun engem Provider-Block trennt. Liest d'Schnëttstell-Zieler an de Flood-Schutz-Log, ier s en Ticket beim ISP opmaachs. Konsumentroutere mat DoS- oder Flood-Schutz versoe an der selwechter Form, an och all Middlebox mat engem kuerzen UDP-Idle-Timeout. En Handshake, deen ni fäerdeg gëtt, deit op e Fall hin, während en Tunnel, deen no Minutte vun der Rou stierft, op den Timeout deit.

Schreif all Apparat tëschent Client a Server op, ier s e Profil änderst. Eng Korrektur op der falscher Schicht gesäit richteg aus bis zum nächsten Netzwierk. Dës Lëscht seet och dem nächsten Ingenieur, wou en no kucke soll, ouni déi ganz Enquête ze widderhuelen.

Eng Adressiwwerlaap, déi wéi e DNS-Feeler ausgesäit

En Access-Netzwierk, dat bannent 10.0.0.0/8 nummeréiert ass, kann sech mam Tunnelpool iwwerlaapen, an de Resolver wunnt normalerweis bannent deem Pool. Wann e Laptop eng Adress wéi 10.184.178.50 mat enger /8-Mask op Wi-Fi kritt, ass all 10.x-Destinatioun per Definitioun lokal. Pakete fir 10.4.0.1 ginn dann an d'LAN, den Tunnel bleift uewen, an d'Nimmopliesung versot.

ip addr weist den Iwwerlaap op ee Bléck, an ip route get 10.4.0.1 weist, wou de Paket wierklech geliwwert géif ginn. Well de sichtbaren Symptom e Resolver-Feeler ass, iwwerlieft dësen dacks e puer Ronnen DNS-Ännerungen.

Nummeréier de Pool nei oder hal deen Access-Netzwierk ausserhalb vum Beräich. Keng Clientsäit-Astellung erhuelt sech vun engem Iwwerlaap.

Tëschent TCP-Fallback an engem Wee-Fix entscheeden

Wiel den TCP-Fallback, wann s de Wee net kontrolléiers an d'Benotzer haut musse schaffen, a akzeptéier seng Käschten: TCP bannent TCP behält sech schlecht op verluschtege Verbindungen, an de Fallback brauch e Listener, deen s du bedreiws. Wiel de Wee-Fix, wann de Block op Infrastruktur läit, déi dir gehéiert, well eng Firewall-Reeg méi bëlleg ass wéi en zweete Listener. Wéi och ëmmer, schaff d'Schichte mateneen duerch: Link, baussenzegen Transport, Verhandlung, bannenzeg Routing. D'Etapp, déi op deem Netzwierk versot huet, ass déi eenzeg Tatsaach, déi zielt.

Halt d'Resultat pro Netzwierk fest an net pro Benotzer. De nächste Rapport vum selwechte Feeler fänkt dann op enger bekannter Etapp un an net op enger Zertifikatstheorie. Dee Rekord ass et och, wat en permanente zweiten Listener gerechtfertegt, wann een iergendwann gebraucht gëtt.