OpenVPN bag stunnel: videresend indpakningen, ikke port 1194

Sæt en TLS-indpakning foran OpenVPN, og udrulningen får en anden lytter, hvoraf kun én nogensinde bør vende ud mod internettet. Når tunnelen virker fra samme maskine og fejler udefra, er videresendelsen normalt rettet mod den forkerte af de to. Det, der skal passe sammen, er en kæde: den offentlige regel når indpakningen, og indpakningens egen backend-forbindelse når den rigtige VPN-socket. Fire hop bærer den kæde, og ethvert af dem kan afslutte undersøgelsen tidligt.

To sockets, to ejere, én af dem offentlig

Indpakningen afslutter TLS for den ydre forbindelse og sender den dekrypterede bytestrøm til en almindelig OpenVPN TCP-lytter. Det er adskilte sockets med adskilte konfigurationsfiler, så redigering af den ene lader den anden urørt og stadig tilsyneladende sund. Det betyder også, at de to kan glide fra hinanden, hver gang den ene ændres uden den anden.

At arbejde fra maskinen selv beviser derfor meget lidt om den offentlige vej. En direkte forbindelse til den native port springer indpakningen over, en forbindelse til indpakningen på dens LAN-adresse springer oversættelsen over, og kun den fulde klientside-opstilling træner det, en udefrakommende bruger gør. Navne skal også læses omhyggeligt, fordi localhost betyder den vært, der kører netop den komponent, og ikke den vært, du tilfældigvis skriver på. Hold den forskel i dine noter, fordi en test registreret uden det hop, den dækkede, indbyder til en sammenligning mellem to forskellige ting.

Hvor videresendelsen faktisk lander

Kæden er lettere at holde som fire hop end som tre portnumre, fordi det samme nummer kan betyde forskellige ting i hver ende. Læs tabellen række for række: hver række er en socket, der skal acceptere en forbindelse og derefter åbne den næste. Når en række er rettet mod den forkerte modpart, er symptomet i den sidste kolonne det, brugeren rapporterer.

En regel, der peger på den native VPN-port i stedet for indpakningen, springer TLS-afslutningen helt over, hvilket er den mest almindelige version af denne fejl: klienten åbner et håndtryk med en lytter, der forventer OpenVPN-indramning, så forbindelsen kan åbne og derefter gå i stå. Bekræft den oversatte port mod indpakningens konfigurationsfil i stedet for mod hukommelsen, fordi den næste person, der redigerer den fil, måske har valgt et andet nummer. De to kommandoer nedenfor viser begge sider af spørgsmålet på én gang.

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

Den bind-adresse, der afviser dig

En accept-linje bundet til 127.0.0.1 svarer kun værten selv, så en videresendelse, der ankommer på LAN-adressen, kan ikke forbinde, og klienten ser en afvisning, der lyder som et pakkefilterproblem. Se på socketten, før du rører firewallen, fordi socketten er det billigere svar. Bind enten indpakningen til det interface, videresendelsen peger på, eller hold den på loopback og få videresendelsen til at nå loopback gennem noget, der virkelig virker. Det er to designs, og hvert af dem har brug for sin egen regel.

At blande dem er måden, hvorpå en fungerende indpakning ender med at være utilgængelig udefra, mens hver fil ser korrekt ud. Kontrollen nedenfor er én kommando, og den besvarer et spørgsmål, som en gennemgang af firewallreglerne ikke kan. Hvis outputtet viser en loopback-adresse, mens videresendelsen peger på LAN-adressen, hører rettelsen i accept-linjen og ikke i pakkefilteret.

ss -lntp '( sport = :8443 )'

Hvad den lokale test faktisk beviste

En succes registreret uden det hop, den dækkede, er ikke bevis om de andre hop. Noter, hvilken adresse testen brugte, og hvilken proces der svarede. Gentag derefter udefra netværket i stedet for fra en telefon på samme Wi-Fi, fordi hårnålsadfærd varierer mellem routere, og en forbindelse, der aldrig forlod LAN'et, kan tilfredsstille en klient, uden at videresendelsen overhovedet er involveret. Kun det andet forsøg træner den vej, en fremmed tager.

Når forsøget fejler, følg en enkelt forbindelse gennem begge logfiler: indpakningens accepterede og forbundne linjer, derefter VPN-dæmonens egen sessionslog. Den første grænse, der ikke registrerer noget, er, hvor den næste ændring hører til. Når OpenVPN sammenligner modpartens indstillinger, bedøm de meddelelser efter den implementerings regler. En advarsel om link-mtu-uoverensstemmelse er ikke automatisk fatal, at fastlåse link-mtu til 1500 beviser ikke, at fragmentering er stoppet, og cifferforhandling hører til den indre OpenVPN-konfiguration og ikke til routerens videresendelse.

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

Disse sonderinger dækker backend-socketten og indpakningens log, hvilket adskiller en afvist backend fra et afvist håndtryk. Kør dem, mens et enkelt forsøg er i gang, og ikke bagefter. Tidsstempler fra et enkelt forsøg er det, der gør sammenligningen troværdig.

To identiteter, to fejlordener

Det ydre certifikat tilhører indpakningen, og den indre identitet tilhører OpenVPN, og de kan komme fra forskellige myndigheder. Deaktivering af en af kontrollerne for at få en vej til at se sund ud bytter en reel beskyttelse for et kosmetisk resultat. Behold begge verifikationer, og fejlret dem i rækkefølge, fordi meddelelsesrækkefølgen navngiver laget: et problem med indpakningens certifikat vises, før nogen VPN-indstilling forhandles, mens en indre identitetsfejl først vises, når strømmen er etableret.

Den stunnel-manual definerer accept, connect og klienttilstand præcist, og disse afsnit besvarer socketspørgsmålet hurtigere end gæt. Når du stadig ikke kan se, hvilket lag der svarede, læs det certifikat, den offentlige port præsenterer, med kommandoen nedenfor. Et indpakningscertifikat i outputtet betyder, at videresendelsen nåede indpakningen, og stilhed eller en protokolfejl betyder, at den ikke gjorde. Den ene forskel sparer mere tid end nogen anden kontrol her.

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