OpenVPN bak stunnel: send innpakninga vidare, ikkje port 1194

Set ei TLS-innpakning framfor OpenVPN, og utrullinga får ein andre lyttar, der berre éin nokon gong bør vende ut mot internett. Når tunnelen verkar frå same maskin og sviktar utanfrå, er videresendinga vanlegvis retta mot den gale av dei to. Det som må stemme, er ei kjede: den offentlege regelen når innpakninga, og innpakninga si eiga backend-tilkopling når den ekte VPN-sokkelen. Fire hopp ber denne kjedja, og kva som helst av dei kan avslutte undersøkinga tidleg.

To sokklar, to eigarar, éin av dei offentleg

Innpakninga avsluttar TLS for den ytre tilkoplinga og sender den dekrypterte bytestraumen vidare til ein vanleg OpenVPN TCP-lyttar. Dette er åtskilde sokklar med åtskilde konfigurasjonsfiler, så redigering av den eine lèt den andre vere urørt og framleis tilsynelatande sunn. Det tyder òg at dei to kan gli frå kvarandre kvar gong den eine blir endra utan den andre.

Arbeid frå maskina sjølv provar derfor svært lite om den offentlege vegen. Ei direkte tilkopling til den opphavlege porten hoppar over innpakninga, ei tilkopling til innpakninga på LAN-adressa hoppar over omsetjinga, og berre det fullstendige oppsettet på klientsida trenar det ein utanforståande gjer. Namn må òg lesast nøye, fordi localhost tyder verten som køyrer akkurat den komponenten, og ikkje verten du tilfeldigvis skriv på. Hald den skilnaden i notata dine, fordi ein test registrert utan hoppet han dekte, inviterer til ein samanlikning mellom to ulike ting.

Kvar videresendinga faktisk landar

Kjedja er lettare å halde som fire hopp enn som tre portnummer, fordi same nummer kan tyde ulike ting i kvar ende. Les tabellen rad for rad: kvar rad er éin sokkel som må godta ei tilkopling og deretter opne den neste. Når ei rad er retta mot feil motpart, er symptomet i den siste kolonnen det brukaren rapporterer.

Ein regel som peikar på den opphavlege VPN-porten i staden for innpakninga, hoppar heilt over TLS-avslutninga, og det er den vanlegaste forma for denne feilen: klienten opnar eit handtrykk med ein lyttar som ventar OpenVPN-innramming, så tilkoplinga kan opne og deretter stoppe. Stadfest den omsette porten mot konfigurasjonsfila til innpakninga i staden for mot minnet, fordi neste person som redigerer den fila kanskje har valt eit anna nummer. Dei to kommandoane nedanfor viser begge sider av spørsmålet samstundes.

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

Bindadressa som avviser deg

Ei accept-linje bunden til 127.0.0.1 svarar berre verten sjølv, så ei videresending som kjem inn på LAN-adressa, kan ikkje kople til, og klienten ser ei avvising som høyrest ut som eit pakkefilterproblem. Sjå på sokkelen før du rører brannmuren, fordi sokkelen er det billegare svaret. Anten bind innpakninga til grensesnittet videresendinga peikar på, eller hald ho på loopback og sørg for at videresendinga når loopback gjennom noko som verkeleg fungerer. Det er to design, og kvart av dei treng si eiga regel.

Å blande dei er korleis ei fungerande innpakning endar med å vere utilgjengeleg utanfrå medan kvar fil ser riktig ut. Kontrollen nedanfor er éin kommando, og han svarar på eit spørsmål som ein gjennomgang av brannmurreglane ikkje kan. Viss utskrifta viser ei loopback-adresse medan videresendinga peikar på LAN-adressa, høyrer rettinga i accept-linja og ikkje i pakkefilteret.

ss -lntp '( sport = :8443 )'

Kva den lokale testen faktisk prova

Ein suksess registrert utan hoppet han dekte, er ikkje prov om dei andre hoppa. Noter kva adresse testen brukte, og kva prosess som svara. Gjenta deretter utanfrå nettverket i staden for frå ein telefon på same Wi-Fi, fordi hårnålsoppførsel varierer mellom rutarar, og ei tilkopling som aldri forlét LAN-et, kan gjere ein klient nøgd utan at videresendinga er involvert i det heile. Berre det andre forsøket trenar vegen ein framand tek.

Når forsøket mislukkast, følg éi enkel tilkopling gjennom begge loggande: dei aksepterte og tilkopla linjene til innpakninga, deretter sesjonsloggen til VPN-demonen sjølv. Den første grensa som ikkje registrerer noko, er der neste endring høyrer heime. Når OpenVPN byrjar å samanlikne motparten sine val, vurder dei meldingane etter reglane til den implementasjonen. Ei åtvaring om link-mtu-inkonsistens er ikkje automatisk fatal, å feste link-mtu til 1500 provar ikkje at fragmenteringa har stoppa, og chiffersamtalen høyrer til den indre OpenVPN-konfigurasjonen og ikkje til videresendinga til rutaren.

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

Desse probane dekkjer backend-sokkelen og loggen til innpakninga, noko som skil ein avvist backend frå eit avvist handtrykk. Køyr dei medan eitt enkelt forsøk pågår, og ikkje etterpå. Tidsstempla frå eitt forsøk er det som gjer samanlikninga påliteleg.

To identitetar, to feilrekkjefølgjer

Det ytre sertifikatet høyrer til innpakninga, og den indre identiteten høyrer til OpenVPN, og dei kan kome frå ulike styresmakter. Å slå av ein av dei to kontrollane for å få ein veg til å sjå sunn ut, byter ei reell vern mot eit kosmetisk resultat. Hald på begge verifiseringane og feilsøk dei i rekkjefølgje, fordi rekkjefølgja til meldingane namngjev laget: eit sertifikatproblem i innpakninga viser seg før noka VPN-innstilling blir forhandla, medan ein indre identitetsfeil først viser seg når straumen er etablert.

Den stunnel-handboka definerer accept, connect og klientmodus presist, og desse avsnitta svarar på sokkelspørsmålet raskare enn gjetting. Når du framleis ikkje kan seie kva lag som svara, les sertifikatet den offentlege porten presenterer, med kommandoen nedanfor. Eit innpakningssertifikat i utskrifta tyder at videresendinga nådde innpakninga, og stillheit eller ein protokollfeil tyder at ho ikkje gjorde det. Den eine skilnaden sparer meir tid enn noka anna kontroll her.

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