OpenVPN stunnel mögött: a burkolót továbbítsd, ne az 1194-es portot

Tegyen TLS-burkolót OpenVPN elé, és a telepítés második figyelőt kap, amelyek közül csak egynek szabadna valaha az internet felé néznie. Amikor az alagút ugyanarról a gépről működik és kívülről meghiúsul, a továbbítás általában a kettő közül a rosszra irányul. Amit össze kell hangolni, az egy lánc: a nyilvános szabály eléri a burkolót, és a burkoló saját háttérkapcsolata eléri a valódi VPN-csatlakozót. Négy ugrás hordozza ezt a láncot, és bármelyikük korán véget vethet a vizsgálatnak.

Két csatlakozó, két tulajdonos, az egyik nyilvános

A burkoló lezárja a TLS-t a külső kapcsolat számára, és továbbadja a visszafejtett bájtfolyamot egy egyszerű OpenVPN TCP-figyelőnek. Ezek külön csatlakozók külön konfigurációs fájlokkal, így az egyik szerkesztése a másikat érintetlenül és látszólag egészségesen hagyja. Ez azt is jelenti, hogy a kettő szétcsúszhat, amikor az egyiket a másik nélkül változtatják.

A gép saját magából induló munka ezért nagyon keveset bizonyít a nyilvános útvonalról. A natív portra indított közvetlen kapcsolat kihagyja a burkolót, a burkolóra a LAN-címén indított kapcsolat kihagyja a fordítást, és csak a teljes kliensoldali elrendezés gyakorolja azt, amit egy külső felhasználó tesz. A neveket is óvatosan kell olvasni, mert a localhost azt a gazdagépet jelenti, amely az adott összetevőt futtatja, nem pedig azt, amelyen épp gépel. Tartsa meg ezt a különbséget a jegyzeteiben, mert a lefedett ugrás nélkül rögzített teszt két különböző dolog összehasonlítására hív.

Hová érkezik valójában a továbbítás

A láncot négy ugrásként könnyebb megtartani, mint három portszámként, mert ugyanaz a szám mindkét végén mást jelenthet. Olvassa a táblázatot soronként: minden sor egy csatlakozó, amelynek kapcsolatot kell fogadnia, majd meg kell nyitnia a következőt. Amikor egy sor a rossz partnerre irányul, az utolsó oszlop tünete az, amit a felhasználó jelent.

Az a szabály, amely a burkoló helyett a natív VPN-portra irányul, teljesen kihagyja a TLS lezárását, és ez a hiba leggyakoribb változata: az ügyfél kézfogást nyit egy olyan figyelővel, amely OpenVPN-keretezést vár, így a kapcsolat megnyílhat, majd elakadhat. A lefordított portot a burkoló konfigurációs fájljához mérje, ne az emlékezetéhez, mert a fájlt legközelebb szerkesztő személy esetleg más számot választott. Az alábbi két parancs egyszerre mutatja a kérdés mindkét oldalát.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

A kötési cím, amely elutasít

A 127.0.0.1 címhez kötött accept sor csak magát a gazdagépet szolgálja ki, így a LAN-címre érkező továbbítás nem tud kapcsolódni, és az ügyfél olyan elutasítást lát, amely csomagszűrő-problémának tűnik. Nézze meg a csatlakozót, mielőtt a tűzfalhoz nyúlna, mert a csatlakozó az olcsóbb válasz. Vagy a továbbítás által célzott interfészhez köti a burkolót, vagy loopbacken tartja, és eléri, hogy a továbbítás valóban működő úton jusson el a loopbackhez. Ez két terv, és mindegyiknek saját szabálya van.

A kettő keverése az, amitől egy működő burkoló kívülről elérhetetlenné válik, miközben minden fájl helyesnek látszik. Az alábbi ellenőrzés egyetlen parancs, és olyan kérdésre válaszol, amelyre a tűzfalszabályok áttekintése nem képes. Ha a kimenet loopback-címet mutat, miközben a továbbítás a LAN-címet célozza, a javítás az accept sorba tartozik, nem a csomagszűrőbe.

ss -lntp '( sport = :8443 )'

Mit bizonyított valójában a helyi teszt

Az az ugrás nélkül rögzített siker, amelyet lefedett, nem bizonyíték a többi ugrásról. Jegyezze fel, melyik címet használta a teszt, és melyik folyamat válaszolt. Utána ismételje meg a hálózaton kívülről, ne ugyanazon a Wi-Fi-n lévő telefonról, mert a hajtűviselkedés routerenként változik, és egy kapcsolat, amely soha nem hagyta el a LAN-t, kielégíthet egy ügyfelet anélkül, hogy a továbbítás egyáltalán részt venne benne. Csak az a második kísérlet gyakorolja azt az utat, amelyet egy idegen bejár.

Amikor a kísérlet meghiúsul, kövessen egyetlen kapcsolatot mindkét naplóban: a burkoló elfogadott és csatlakozott sorait, majd a VPN-démon saját munkamenet-naplóját. Az első határ, amely semmit nem rögzít, a következő változtatás helye. Amikor az OpenVPN elkezdi összehasonlítani a partner beállításait, ezeket az üzeneteket az adott implementáció szabályai szerint ítélje meg. A link-mtu következetlenségéről szóló figyelmeztetés nem automatikusan végzetes, a link-mtu 1500-ra rögzítése nem bizonyítja, hogy a töredezés megszűnt, és a titkosítás egyeztetése az OpenVPN belső konfigurációjához tartozik, nem a router továbbításához.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Ezek a szondák a háttércsatlakozót és a burkoló naplóját fedik le, ami elválasztja az elutasított hátteret az elutasított kézfogástól. Futtassa őket egyetlen kísérlet közben, és ne utána. Az egyetlen kísérletből származó időbélyegek teszik megbízhatóvá az összehasonlítást.

Két identitás, két hibasorrend

A külső tanúsítvány a burkolóé, a belső identitás pedig az OpenVPN-é, és különböző hatóságoktól származhatnak. Bármelyik ellenőrzés kikapcsolása, hogy az útvonal egészségesnek tűnjön, valódi védelmet cserél kozmetikai eredményre. Tartsa meg mindkét ellenőrzést, és sorrendben hárítsa el őket, mert az üzenetek sorrendje nevezi meg a réteget: a burkoló tanúsítványának problémája még azelőtt megjelenik, hogy bármilyen VPN-beállítást egyeztetnének, míg a belső identitás hibája csak a folyam létrejötte után jelenik meg.

A stunnel kézikönyv pontosan meghatározza az accept, connect és kliens módot, és ezek a fejezetek gyorsabban válaszolnak a csatlakozó kérdésére, mint a találgatás. Ha még mindig nem tudja megmondani, melyik réteg válaszolt, olvassa el a nyilvános port által bemutatott tanúsítványt az alábbi paranccsal. Ha a kimenetben burkolótanúsítvány van, a továbbítás elérte a burkolót, ha pedig csend vagy protokollhiba, akkor nem. Ez az egyetlen megkülönböztetés több időt takarít meg, mint bármely más ellenőrzés itt.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer