OpenVPN iza stunnela: proslijedite omotač, a ne port 1194

Stavite TLS omotač ispred OpenVPN i implementacija dobija drugo prijemno mjesto, od kojih bi samo jedno ikada trebalo gledati u internet. Kada tunel radi sa iste mašine a ne uspijeva spolja, smjer je obično uperen u pogrešno od ta dva. Ono što se mora poravnati jeste lanac: javno pravilo stiže do omotača, a vlastita backend veza omotača stiže do pravog VPN soketa. Četiri skoka nose taj lanac i bilo koji od njih može završiti istragu prerano.

Dva soketa, dva vlasnika, jedan od njih javni

Omotač završava TLS za vanjsku vezu i predaje dešifrovan tok bajtova običnom OpenVPN TCP prijemniku. To su odvojeni soketi sa odvojenim konfiguracionim datotekama, pa uređivanje jednog ostavlja drugi netaknutim i još uvijek naizgled zdravim. To takođe znači da se dva mogu razilaziti kad se jedan promijeni bez drugog.

Rad sa same mašine zato dokazuje vrlo malo o javnom putu. Direktna veza na matični port preskače omotač, veza na omotač na njegovoj LAN adresi preskače prevođenje, a samo potpuna postavka na strani klijenta vježba ono što radi vanjski korisnik. Imena treba čitati pažljivo, jer localhost znači host na kojem se izvršava taj konkretni komponent, a ne host na kojem slučajno kucate. Držite tu razliku u svojim bilješkama, jer test zabilježen bez skoka koji je pokrio poziva na poređenje dvije različite stvari.

Gdje smjer zaista stiže

Lanac je lakše držati kao četiri skoka nego kao tri broja portova, jer isti broj može značiti različite stvari na svakom kraju. Čitajte tabelu red po red: svaki red je jedan soket koji mora prihvatiti vezu i zatim otvoriti sljedeću. Kada je red uperen u pogrešnog partnera, simptom u zadnjoj koloni je ono što korisnik prijavljuje.

Pravilo koje cilja na matični VPN port umjesto na omotač potpuno preskače TLS završetak, što je najčešća verzija ove greške: klijent otvara rukovanje sa prijemnikom koji očekuje OpenVPN uokvirenje, pa se veza može otvoriti i zatim stati. Potvrdite prevedeni port prema konfiguracionoj datoteci omotača, a ne prema sjećanju, jer je sljedeća osoba koja bude uređivala tu datoteku možda odabrala drugi broj. Dvije komande ispod pokazuju obje strane tog pitanja odjednom.

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

Adresa vezivanja koja vas odbija

Accept linija vezana na 127.0.0.1 odgovara samo samom hostu, pa se smjer koji stiže na LAN adresu ne može spojiti i klijent vidi odbijanje koje zvuči kao problem paketskog filtera. Pogledajte soket prije nego što dirnete firewall, jer soket je jeftiniji odgovor. Ili vežite omotač na interfejs na koji smjer cilja, ili ga zadržite na loopbacku i učinite da smjer stigne do loopbacka kroz nešto što zaista radi. To su dva dizajna i svaki treba svoje pravilo.

Miješanje njih je način na koji radni omotač postane nedostupan spolja dok svaka datoteka izgleda ispravno. Provjera ispod je jedna komanda i odgovara na pitanje na koje pregled firewall pravila ne može. Ako izlaz pokazuje loopback adresu dok smjer cilja na LAN adresu, ispravka pripada accept liniji, a ne paketskom filteru.

ss -lntp '( sport = :8443 )'

Šta je lokalni test zaista dokazao

Uspjeh zabilježen bez skoka koji je pokrio nije dokaz o drugim skokovima. Zabilježite koju je adresu test koristio i koji je proces odgovorio. Zatim ponovite izvan mreže, a ne sa telefona na istoj Wi-Fi mreži, jer se ponašanje ukosnice razlikuje među ruterima i veza koja nikada nije napustila LAN može zadovoljiti klijenta bez ikakvog učešća smjera. Samo taj drugi pokušaj vježba put koji stranac prelazi.

Kada pokušaj ne uspije, pratite jednu vezu kroz oba loga: prihvaćene i povezane linije omotača, zatim vlastiti dnevnik sesije VPN demona. Prva granica koja ništa ne bilježi je mjesto sljedeće promjene. Kada OpenVPN počne upoređivati opcije partnera, procijenite te poruke po pravilima te implementacije. Upozorenje o nekonzistentnosti link-mtu nije automatski fatalno, prikvačivanje link-mtu na 1500 ne dokazuje da je fragmentacija prestala, a pregovaranje šifre pripada unutrašnjoj OpenVPN konfiguraciji, a ne smjeru rutera.

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

Te sonde pokrivaju backend soket i log omotača, što odvaja odbijeni backend od odbijenog rukovanja. Pokrenite ih dok je jedan pokušaj u toku, a ne poslije. Vremenske oznake iz jednog pokušaja čine poređenje pouzdanim.

Dva identiteta, dva redoslijeda neuspjeha

Vanjski certifikat pripada omotaču, a unutrašnji identitet OpenVPN-u i mogu doći od različitih autoriteta. Isključivanje bilo koje provjere da bi put izgledao zdrav razmjenjuje stvarnu zaštitu za kozmetički rezultat. Zadržite obje provjere i otklanjajte ih po redu, jer slijed poruka imenuje sloj: problem sa certifikatom omotača pojavljuje se prije nego što se pregovara bilo koja VPN opcija, dok se kvar unutrašnjeg identiteta pojavljuje tek kad je tok uspostavljen.

stunnel priručnik precizno definiše accept, connect i klijentski režim, a ti odjeljci odgovaraju na pitanje o soketu brže od nagađanja. Kada još ne možete reći koji je sloj odgovorio, pročitajte certifikat koji javni port predstavlja komandom ispod. Certifikat omotača u izlazu znači da je smjer stigao do omotača, a tišina ili greška protokola znači da nije. Ta jedna razlika štedi više vremena od bilo koje druge provjere ovdje.

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