OpenVPN funguje doma, ale v jedné síti ne: UDP, nebo TCP?

Stejný profil se doma připojí a v hotelové, kampusové nebo pobočkové síti zamrzne. Přihlašovací údaje se nezměnily, takže zajímavá proměnná je cesta: co se s pakety děje, než je OpenVPN přečte. Porovnat čtyři možné příčiny v pořadí, v jakém je lze otestovat, je lepší než hádat o certifikátech. Každá zanechává jinou stopu a právě stopa je odděluje.

Která fáze selhala, ukazuje, které srovnání je důležité

Protokol klienta už zaznamenává, jak daleko jste se dostali. Řádek, že vyjednávání klíče TLS nenastalo v rámci časového limitu, znamená, že první paket odešel a zpět nepřišlo nic použitelného, což ukazuje na cestu. Odmítnutí certifikátu vypadá úplně jinak: přijde odpověď a potom konkrétní chyba ověření pojmenuje důvod. Všimněte si posledního řádku před smyčkou opakování, protože to je hodnota, kterou mezi sítěmi porovnáváte.

Zachycujte během opakování, ne potom. Na klientovi tcpdump -ni any udp port 1194 ukazuje, zda se vůbec vrací nějaká odpověď. Zopakujte to na rozhraní WAN serveru, který ovládáte, což odhalí, zda se ty pakety vůbec dostanou na vzdálenou stranu.

Jednostranný provoz je tady nejužitečnější dostupný výsledek, protože mění občasnou stížnost na směr vyšetřování. Soubory zachycení si ponechte, protože další hlášení stejného problému se uzavírá snáze s důkazem než s popisem.

Filtrování UDP versus zavřený port

Mnoho přístupových sítí považuje vytrvalý UDP za podezřelý a někteří poskytovatelé s nimi souhlasí. Zavřený port vytváří stejné ticho ze strany klienta. Rozdíl je v selektivitě: filtr bývá vybíravý v tom, které cíle nebo porty zahazuje, zatímco zavřený port odmítá vše směřované na ten jeden port.

Profil TCP na portu 443 je obvyklé obejití, protože připomíná běžný tok HTTPS a projde většinou captive portálů a výstupních filtrů. Musí platit dvě podmínky. Server musí naslouchat s proto tcp-server a klient se musí shodovat s proto tcp-client a operátor musí ten alternativní koncový bod zveřejnit. Přepsat funkční profil UDP, aby tvrdil TCP 443, nikam nevede, když na druhém konci nikdo neposlouchá.

Zavřený port je problém konfigurace, ne cenzury. Server za domácím routerem potřebuje přesměrovaný port UDP a routerový firewall to musí povolit. Když port nikdy povolen nebyl, každý klient selže při vyjednávání bez ohledu na údaje, a selhání sleduje server, ne síť.

Starší protokoly na této ose obstojí špatně. PPTP potřebuje TCP 1723 plus GRE a GRE je IP protokol 47, ne port, takže to žádné běžné přesměrování portu nevyjádří.

Když pakety zahazuje přepínač

Spravovaný přepínač může tunel zahazovat záměrně. Některé modely HPE a Aruba nabízejí v sekci pokročilé bezpečnosti ovládání ochrany proti záplavě UDP, občas označené Prevent UDP Blat Attack. Jakmile je toto ovládání aktivní, server za přepínačem neodpovídá ničím a každý klient vyprší stejným způsobem. Vypnout ho a uložit běžící konfiguraci je celá oprava, ale až poté, co zjistíte, že přepínač je skutečně na cestě.

Protiargumenty jsou to, co odděluje zahazování přepínačem od blokování poskytovatelem. Přečtěte si čítače rozhraní a protokol ochrany proti záplavě, než otevřete tiket u poskytovatele. Spotřebitelské routery s ochranou DoS nebo proti záplavě selhávají stejně a jakýkoli prostředník s krátkým časem nečinnosti UDP také. Handshake, který se nikdy nedokončí, naznačuje zahazování, zatímco tunel, který zemře po minutách ticha, naznačuje časový limit.

Než změníte profil, zapište každé zařízení mezi klientem a serverem. Oprava nasazená ve špatné vrstvě vypadá správně až do další sítě. Ten seznam také říká dalšímu inženýrovi, kam se dívat, aniž by opakoval celé vyšetřování.

Překryv adres, který vypadá jako selhání DNS

Přístupová síť číslovaná uvnitř 10.0.0.0/8 se může překrývat s fondem tunelu a resolver obvykle žije uvnitř toho fondu. Když notebook dostane adresu jako 10.184.178.50 s maskou /8 na Wi-Fi, je každý cíl 10.x podle definice lokální. Pakety pro 10.4.0.1 pak jdou do LAN, tunel zůstává nahoře a překlad jmen selhává.

ip addr odhalí překryv na první pohled a ip route get 10.4.0.1 ukáže, kam by paket skutečně byl doručen. Protože viditelným příznakem je selhání resolveru, tento případ často přežije několik kol změn DNS.

Přečíslujte fond, nebo tu přístupovou síť držte mimo rozsah. Žádné nastavení na straně klienta překryv nevyřeší.

Rozhodnutí mezi záložním TCP a opravou cesty

Zvolte záložní TCP, když cestu neovládáte a uživatelé musí dnes pracovat, a přijměte jeho náklady: TCP v TCP se na ztrátových linkách chová špatně a záloha potřebuje listener, který provozujete. Zvolte opravu cesty, když blokování leží na infrastruktuře, kterou vlastníte, protože pravidlo firewallu je levnější než druhý listener. V každém případě projděte vrstvy v pořadí: link, vnější transport, vyjednávání, vnitřní směrování. Fáze, která v té síti selhala, je jediný fakt, na kterém záleží.

Výsledek zaznamenávejte po sítích, ne po uživatelích. Další hlášení stejného selhání pak začíná u známé fáze místo u teorie o certifikátu. Ten záznam také ospravedlňuje stálý druhý listener, pokud bude někdy potřeba.