OpenVPN bak stunnel: videresend innpakningen, ikke port 1194

Sett en TLS-innpakning foran OpenVPN, og utrullingen får en andre lytter, hvorav bare én noen gang bør vende ut mot internett. Når tunnelen virker fra samme maskin og svikter utenfra, er videresendingen vanligvis rettet mot den gale av de to. Det som må stemme, er en kjede: den offentlige regelen når innpakningen, og innpakningens egen backend-tilkobling når den ekte VPN-socketen. Fire hopp bærer denne kjeden, og hvilket som helst av dem kan avslutte undersøkelsen tidlig.

To sockets, to eiere, én av dem offentlig

Innpakningen avslutter TLS for den ytre tilkoblingen og sender den dekrypterte bytestrømmen videre til en vanlig OpenVPN TCP-lytter. Dette er adskilte sockets med adskilte konfigurasjonsfiler, så redigering av den ene lar den andre være urørt og fortsatt tilsynelatende sunn. Det betyr også at de to kan gli fra hverandre hver gang den ene endres uten den andre.

Arbeid fra maskinen selv beviser derfor svært lite om den offentlige veien. En direkte tilkobling til den opprinnelige porten hopper over innpakningen, en tilkobling til innpakningen på LAN-adressen hopper over oversettelsen, og bare det fullstendige oppsettet på klientsiden trener det en utenforstående gjør. Navn må også leses nøye, fordi localhost betyr verten som kjører akkurat den komponenten, og ikke verten du tilfeldigvis skriver på. Hold den forskjellen i notatene dine, fordi en test registrert uten hoppet den dekket, inviterer til en sammenligning mellom to forskjellige ting.

Hvor videresendingen faktisk lander

Kjeden er lettere å holde som fire hopp enn som tre portnumre, fordi samme nummer kan bety forskjellige ting i hver ende. Les tabellen rad for rad: hver rad er én socket som må godta en tilkobling og deretter åpne den neste. Når en rad er rettet mot feil motpart, er symptomet i den siste kolonnen det brukeren rapporterer.

En regel som peker på den opprinnelige VPN-porten i stedet for innpakningen, hopper helt over TLS-avslutningen, og det er den vanligste formen for denne feilen: klienten åpner et håndtrykk med en lytter som forventer OpenVPN-innramming, så tilkoblingen kan åpne og deretter stoppe. Bekreft den oversatte porten mot innpakningens konfigurasjonsfil i stedet for mot hukommelsen, fordi neste person som redigerer den filen kanskje har valgt et annet nummer. De to kommandoene nedenfor viser begge sider av spørsmålet samtidig.

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

Bind-adressen som avviser deg

En accept-linje bundet til 127.0.0.1 svarer bare verten selv, så en videresending som ankommer LAN-adressen, kan ikke koble til, og klienten ser en avvisning som høres ut som et pakkefilterproblem. Se på socketen før du rører brannmuren, fordi socketen er det billigere svaret. Enten bind innpakningen til grensesnittet videresendingen peker på, eller hold den på loopback og sørg for at videresendingen når loopback gjennom noe som virkelig fungerer. Det er to design, og hvert av dem trenger sin egen regel.

Å blande dem er hvordan en fungerende innpakning ender med å være utilgjengelig utenfra mens hver fil ser riktig ut. Kontrollen nedenfor er én kommando, og den svarer på et spørsmål som en gjennomgang av brannmurreglene ikke kan. Hvis utskriften viser en loopback-adresse mens videresendingen peker på LAN-adressen, hører rettelsen i accept-linjen og ikke i pakkefilteret.

ss -lntp '( sport = :8443 )'

Hva den lokale testen faktisk beviste

En suksess registrert uten hoppet den dekket, er ikke bevis om de andre hoppene. Noter hvilken adresse testen brukte, og hvilken prosess som svarte. Gjenta deretter utenfra nettverket i stedet for fra en telefon på samme Wi-Fi, fordi hårnålsoppførsel varierer mellom rutere, og en tilkobling som aldri forlot LAN-et, kan tilfredsstille en klient uten at videresendingen er involvert i det hele tatt. Bare det andre forsøket trener veien en fremmed tar.

Når forsøket mislykkes, følg én enkelt tilkobling gjennom begge loggene: innpakningens aksepterte og tilkoblede linjer, deretter VPN-demonens egen sesjonslogg. Den første grensen som ikke registrerer noe, er der neste endring hører hjemme. Når OpenVPN begynner å sammenligne motpartens alternativer, vurder disse meldingene etter den implementeringens regler. En advarsel om link-mtu-inkonsistens er ikke automatisk fatal, å feste link-mtu til 1500 beviser ikke at fragmenteringen har stoppet, og chiffersamtalen hører til den indre OpenVPN-konfigurasjonen og ikke til ruterens videresending.

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

Disse probene dekker backend-socketen og innpakningens logg, noe som skiller en avvist backend fra et avvist håndtrykk. Kjør dem mens ett enkelt forsøk pågår, og ikke etterpå. Tidsstempler fra ett forsøk er det som gjør sammenligningen pålitelig.

To identiteter, to feilrekkefølger

Det ytre sertifikatet tilhører innpakningen, og den indre identiteten tilhører OpenVPN, og de kan komme fra ulike myndigheter. Å slå av en av de to kontrollene for å få en vei til å se sunn ut, bytter en reell beskyttelse mot et kosmetisk resultat. Behold begge verifiseringene og feilsøk dem i rekkefølge, fordi meldingsrekkefølgen navngir laget: et sertifikatproblem i innpakningen vises før noen VPN-innstilling forhandles, mens en indre identitetsfeil først vises når strømmen er etablert.

Den stunnel-håndboken definerer accept, connect og klientmodus presist, og disse avsnittene svarer på socketspørsmålet raskere enn gjetting. Når du fortsatt ikke kan si hvilket lag som svarte, les sertifikatet den offentlige porten presenterer, med kommandoen nedenfor. Et innpakningssertifikat i utskriften betyr at videresendingen nådde innpakningen, og stillhet eller en protokollfeil betyr at den ikke gjorde det. Den ene forskjellen sparer mer tid enn noen annen kontroll her.

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