OpenVPN bakom stunnel: vidarebefordra omslaget, inte port 1194

Sätt ett TLS-omslag framför OpenVPN och driftsättningen får en andra lyssnare, varav bara en någonsin bör vända sig mot internet. När tunneln fungerar från samma maskin och misslyckas utifrån, riktas vidarebefordran oftast mot den felaktiga av de två. Det som måste stämma är en kedja: den offentliga regeln når omslaget, och omslagets egen backend-anslutning når den riktiga VPN-socketen. Fyra hopp bär den kedjan, och vilket som helst av dem kan avsluta undersökningen tidigt.

Två sockets, två ägare, en av dem offentlig

Omslaget avslutar TLS för den yttre anslutningen och skickar den dekrypterade byteströmmen vidare till en vanlig OpenVPN TCP-lyssnare. Det är separata sockets med separata konfigurationsfiler, så redigering av den ena lämnar den andra orörd och fortfarande till synes frisk. Det betyder också att de två kan glida ifrån varandra när den ena ändras utan den andra.

Arbete från maskinen själv bevisar därför mycket lite om den offentliga vägen. En direkt anslutning till den inbyggda porten hoppar över omslaget, en anslutning till omslaget på dess LAN-adress hoppar över översättningen, och bara den fullständiga uppställningen på klientsidan tränar det en utomstående gör. Namn måste också läsas noga, eftersom localhost betyder värden som kör just den komponenten, och inte värden du råkar skriva på. Håll den skillnaden i dina anteckningar, eftersom ett test som registreras utan hoppet det täckte bjuder in till en jämförelse mellan två olika saker.

Var vidarebefordran faktiskt landar

Kedjan är lättare att hålla som fyra hopp än som tre portnummer, eftersom samma nummer kan betyda olika saker i varje ände. Läs tabellen rad för rad: varje rad är en socket som måste ta emot en anslutning och sedan öppna nästa. När en rad riktas mot fel motpart är symtomet i den sista kolumnen det användaren rapporterar.

En regel som pekar på den inbyggda VPN-porten i stället för omslaget hoppar helt över TLS-avslutningen, och det är den vanligaste formen av detta fel: klienten öppnar ett handskakning med en lyssnare som förväntar sig OpenVPN-inramning, så anslutningen kan öppnas och sedan fastna. Bekräfta den översatta porten mot omslagets konfigurationsfil i stället för mot minnet, eftersom nästa person som redigerar filen kanske har valt ett annat nummer. De två kommandona nedan visar båda sidorna av frågan samtidigt.

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

Bindningsadressen som avvisar dig

En accept-rad bunden till 127.0.0.1 svarar bara värden själv, så en vidarebefordran som anländer på LAN-adressen kan inte ansluta och klienten ser en avvisning som låter som ett paketfilterproblem. Titta på socketen innan du rör brandväggen, eftersom socketen är det billigare svaret. Antingen bind omslaget till gränssnittet som vidarebefordran pekar på, eller håll det på loopback och se till att vidarebefordran når loopback genom något som verkligen fungerar. Det är två designer, och var och en behöver sin egen regel.

Att blanda dem är hur ett fungerande omslag blir oåtkomligt utifrån medan varje fil ser korrekt ut. Kontrollen nedan är ett enda kommando, och den svarar på en fråga som en genomgång av brandväggsreglerna inte kan. Om utdata visar en loopback-adress medan vidarebefordran pekar på LAN-adressen, hör rättelsen i accept-raden och inte i paketfiltret.

ss -lntp '( sport = :8443 )'

Vad det lokala testet faktiskt bevisade

Ett lyckat resultat som registreras utan hoppet det täckte är inte bevis om de andra hoppen. Notera vilken adress testet använde och vilken process som svarade. Upprepa sedan utifrån nätverket i stället för från en telefon på samma Wi-Fi, eftersom hårnålsbeteende varierar mellan routrar och en anslutning som aldrig lämnade LAN kan tillfredsställa en klient utan att vidarebefordran är inblandad alls. Bara det andra försöket tränar den väg en främling tar.

När försöket misslyckas, följ en enda anslutning genom båda loggarna: omslagets accepterade och anslutna rader, sedan VPN-demonens egen sessionslogg. Den första gränsen som inte registrerar något är där nästa ändring hör hemma. När OpenVPN börjar jämföra motpartens alternativ, bedöm de meddelandena enligt den implementationens regler. En varning om link-mtu-inkonsistens är inte automatiskt fatal, att fästa link-mtu vid 1500 bevisar inte att fragmenteringen har upphört, och chifferförhandlingen hör till den inre OpenVPN-konfigurationen och inte till routerns vidarebefordran.

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

De sonderna täcker backend-socketen och omslagets logg, vilket skiljer en avvisad backend från ett avvisat handskakning. Kör dem medan ett enda försök pågår och inte efteråt. Tidsstämplar från ett försök är det som gör jämförelsen tillförlitlig.

Två identiteter, två felordningar

Det yttre certifikatet tillhör omslaget och den inre identiteten tillhör OpenVPN, och de kan komma från olika myndigheter. Att stänga av en av de två kontrollerna för att få en väg att se frisk ut byter ett verkligt skydd mot ett kosmetiskt resultat. Behåll båda verifieringarna och felsök dem i ordning, eftersom meddelandenas ordning namnger lagret: ett certifikatproblem i omslaget visas innan någon VPN-inställning förhandlas, medan ett inre identitetsfel först visas när strömmen är etablerad.

stunnel-handboken definierar accept, connect och klientläget exakt, och dessa avsnitt svarar på socketfrågan snabbare än gissningar. När du fortfarande inte kan säga vilket lager som svarade, läs certifikatet som den offentliga porten presenterar med kommandot nedan. Ett omslagscertifikat i utdata betyder att vidarebefordran nådde omslaget, och tystnad eller ett protokollfel betyder att den inte gjorde det. Den enda skillnaden sparar mer tid än någon annan kontroll här.

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