OpenVPN och HTTPS på port 443: vem äger lyssnaren?

Två tjänster kan båda svara på port 443 utan att någonsin konkurrera, eftersom en lyssnare bestäms av transport, adress och port tillsammans, inte av numret ensamt. Sätt en webbserver och OpenVPN på en maskin, och den enda frågan som förtjänar ett svar först är vilken socket varje process ber kärnan om. Skriv ned den listan innan du redigerar en konfiguration, och de flesta fel om «adressen används redan» förklarar sig själva. Allt efter listan är ett val mellan en UDP-lyssnare, en delad TCP-socket eller en frontend som routar efter protokoll.

Börja med socketen varje process ber om

Ett bind lyckas eller misslyckas på den trippeln, så två daemoner kolliderar bara när alla tre delarna sammanfaller. Därför samexisterar en webbplats på TCP 443 obegränsat med en OpenVPN-lyssnare på UDP 443, och därför avslutar det också diskussionen att flytta en av dem till en andra lokal adress på samma värd. Läs de levande lyssnarna i stället för filerna som skulle ha skapat dem, eftersom en föråldrad include eller en glömd unit-fil överlever redigeringen du minns att du gjorde.

Kör ss -lntup som root och läs varje rad som nämner 443, inklusive IPv6-poster. En jokertecken-lyssnare för v6 accepterar vanligtvis också v4-trafik, och så håller en lyssnare du glömde porten upptagen efter att du ändrat filen du trodde var ansvarig. Om ett processnamn överraskar dig, begränsa utdata med ss -lntup 'sport = :443' innan du rör något.

Byt tunneln till UDP när nätet tillåter

En UDP-lyssnare kringgår kollisionen helt och är oftast den kortaste reparationen, eftersom ingen socket delas och ingen extra produkt kommer in på vägen. Det är inte gratis. Vissa klientnät släpper UDP 443 utan att skicka reset, så tunneln slutar etablera sig i stället för att misslyckas på bind, och användaren rapporterar att VPN är nere utan något fel att läsa. En UDP-lyssnare överlever också en omstart av webbagret, vilket räknas på en maskin vars webbplats ofta rullas ut på nytt. Testa från nätet där användarna sitter, eftersom ett skal på servern bara bevisar att servern når sig själv.

Ändra transporten i serverkonfigurationen och i klientprofilen samtidigt. En profil som fortfarande ber om TCP kommer att gå i återanslutningsloopar mot en lyssnare med bara UDP, och det ser ut som ett nätfel tills du jämför de två filerna.

Låt VPN-processen äga TCP 443 och vidarebefordra resten

Community OpenVPN i TCP-serverläge läser de första byten av en inkommande anslutning och vidarebefordrar allt som inte är dess eget protokoll till en HTTPS-backend, och det är vad direktivet port-share är till för. Backenden är en vanlig webbserver med TLS aktiverat, namngiven med värd och port i det direktivet i stället för med en URL.

port-share 10.0.0.5 8080

På en maskin där webbplatsen har en andra privat adress skickar den raden icke-VPN-trafik till 10.0.0.5:8080, så den virtuella HTTPS-värden måste vara bunden där och brandväggen måste tillåta det lokala hoppet. Webbservern måste avsluta TLS själv, eftersom byten som anländer är webbläsarens ursprungliga handskakning och ingenting däremellan har dekrypterat dem. Rikta direktivet mot en vanlig HTTP-lyssnare och webbläsaren får ett fel om ogiltig metod, som läses som en trasig webbplats snarare än en felplacerad backend. Direktivet finns bara i TCP-serverläge, och en UDP-lyssnare har ingen ström att inspektera.

Eftersom VPN-processen accepterar varje anslutning ser webbapplikationen den vidarebefordrade begäran komma från en av värdens egna adresser i stället för från besökaren. Allt som behöver den riktiga klientadressen beror på PROXY-protokollstöd i backenden eller på en frontend som lägger till det. Att flytta backenden till en annan lokal adress tar inte tillbaka besökarens adress; det ändrar bara vilken av värdens adresser webbplatsen registrerar. Skriv den begränsningen i driftsättningsanteckningarna innan en analysrapport väcker frågan.

En omvänd proxy är fel verktyg; en layer-four-router är det inte

En HTTP-omvänd proxy avslutar TLS för att kunna läsa begäranden, vilket betyder att den inte kan släppa igenom en OpenVPN-ström orörd. En layer-four-router som vidarebefordrar efter SNI eller efter inspektion av det första paketet kan stå framför båda, förutsatt att den inte avslutar den session som VPN är beroende av. De två enheterna ser likadana ut i ett diagram och beter sig helt olika vid socketen.

Kommersiell Access Server levereras med egna inställningar för portdelning, och de motsvarar inte en-till-en community-direktivet. Identifiera produkten och versionen innan du anpassar en guide skriven för den andra. En kopierad inställning som tyst ignoreras är värre än ingen inställning, eftersom lyssnarlistan fortfarande ser trovärdig ut efteråt.

Testa webbplatsen och tunneln som två separata vägar

Ladda webbplatsen och anslut tunneln, läs sedan lyssnarlistan igen för att se vilken process som äger 443 nu. En sida som laddas bevisar ingenting om VPN, och en tunnel som ansluter bevisar ingenting om webbplatsen, även om båda använder samma nummer. De tre kommandona nedan kontrollerar den delade socketen, webbvägen och VPN-tjänsten i den ordningen.

ss -lntup 'sport = :443'
curl -sI https://vpn.example.com/ | head -n 1
journalctl -u openvpn-server@server -n 20

Jämför klientadressen i backendens åtkomstlogg med den i VPN-loggen för samma ögonblick. Om webbplatsen registrerar varje besökare som värden själv fungerar vidarebefordran och adresshanteringen inte. Om båda loggarna är tysta har frontenden aldrig lämnat över anslutningen. Oavsett vilket avgör lyssnarlistan vem som accepterar socketen, och det är faktumet som måste bekräftas innan du ändrar en annan fil.

Låt den lyssnarkartan ligga vid konfigurationen så att nästa person som rör 443 vet vilken process som accepterar och vart det andra protokollet tog vägen. Bekräfta ägarskapet efter ändringen i stället för att lita på vad redigeringen skulle göra.