OpenVPN og HTTPS på port 443: hvem ejer lytteren?

To tjenester kan begge svare på port 443 uden nogensinde at konkurrere, fordi en lytter nøgles på transport, adresse og port sammen og ikke på nummeret alene. Sæt en webserver og OpenVPN på én maskine, og det eneste spørgsmål, der er værd at besvare først, er, hvilken socket hver proces beder kernen om. Skriv den liste ned, før du redigerer en konfiguration, og de fleste fejl med »adresse allerede i brug« forklarer sig selv. Alt efter listen er et valg mellem en UDP-lytter, en delt TCP-socket eller en frontend, der ruter efter protokol.

Start med den socket, hver proces beder om

Et bind lykkes eller fejler på den trippel, så to daemoner støder kun sammen, når alle tre dele falder sammen. Derfor sameksisterer et websted på TCP 443 i det uendelige med en OpenVPN-lytter på UDP 443, og derfor afslutter det også diskussionen at flytte en af dem til en anden lokal adresse på samme vært. Læs de levende lyttere i stedet for de filer, der skulle have oprettet dem, fordi et forældet include eller en glemt unit-fil overlever den redigering, du husker at have lavet.

Kør ss -lntup som root, og læs hver række, der nævner 443, inklusive IPv6-poster. En wildcard-lytter til v6 accepterer normalt også v4-trafik, og det er sådan en lytter, du havde glemt, holder porten besat, efter du har ændret den fil, du troede var ansvarlig. Hvis et procesnavn overrasker dig, så indsnævr outputtet med ss -lntup 'sport = :443', før du rører noget.

Skift tunnelen til UDP, når netværket tillader det

En UDP-lytter omgår kollisionen helt og er normalt den korteste reparation, da ingen socket deles, og intet ekstra produkt kommer ind på vejen. Det er ikke gratis. Nogle klientnetværk dropper UDP 443 uden at sende et reset, så tunnelen holder op med at etablere sig i stedet for at fejle på bind, og brugeren rapporterer VPN som nede uden nogen fejl at læse. En UDP-lytter overlever også en genstart af weblaget, hvilket tæller på en maskine, hvor sitet ofte genudrulles. Test fra det netværk, hvor brugerne sidder, fordi en shell på serveren kun beviser, at serveren kan nå sig selv.

Skift transporten i serverkonfigurationen og i klientprofilen samtidig. En profil, der stadig beder om TCP, vil køre i ring med genopkoblinger mod en lytter, der kun har UDP, og det ligner en netværksfejl, indtil du sammenligner de to filer.

Lad VPN-processen eje TCP 443, og videresend resten

Community OpenVPN i TCP-servertilstand læser de første bytes af en indgående forbindelse og videresender alt, der ikke er dens egen protokol, til et HTTPS-backend, og det er, hvad port-share-direktivet er til. Backendet er en almindelig webserver med TLS aktiveret, navngivet ved vært og port i det direktiv i stedet for ved en URL.

port-share 10.0.0.5 8080

På en maskine, hvor sitet har en anden privat adresse, sender den linje ikke-VPN-trafik til 10.0.0.5:8080, så HTTPS-værten skal være bundet der, og firewalling skal tillade det lokale hop. Webserveren skal selv afslutte TLS, fordi de ankommende bytes er browserens oprindelige handshake, og intet imellem har dekrypteret dem. Ret direktivet mod en almindelig HTTP-lytter, og browseren får en ugyldig-metode-fejl, som læses som et ødelagt site snarere end et forkert placeret backend. Direktivet findes kun i TCP-servertilstand, og en UDP-lytter har ingen strøm at inspicere.

Fordi VPN-processen accepterer hver forbindelse, ser webapplikationen den videresendte anmodning ankomme fra en af værtens egne adresser i stedet for fra besøgende. Alt, der har brug for den rigtige klientadresse, afhænger af PROXY-protokolunderstøttelse i backendet eller af en frontend, der tilføjer den. At flytte backendet til en anden lokal adresse bringer ikke den besøgendes adresse tilbage; det ændrer kun, hvilken af værtens adresser sitet registrerer. Skriv den begrænsning i udrulningsnoterne, før en analyserapport rejser spørgsmålet.

En omvendt proxy er det forkerte værktøj; en layer-four-router er ikke

En HTTP-omvendt proxy afslutter TLS for at kunne læse anmodninger, hvilket betyder, at den ikke kan sende en OpenVPN-strøm igennem urørt. En layer-four-router, der videresender efter SNI eller efter inspektion af den første pakke, kan stå foran begge, forudsat at den ikke afslutter den session, VPN afhænger af. De to enheder ligner hinanden på et diagram og opfører sig helt forskelligt ved socketen.

Kommerciel Access Server leverer sine egne indstillinger for portdeling, og de svarer ikke en-til-en til community-direktivet. Identificér produktet og versionen, før du tilpasser en vejledning skrevet til den anden. En kopieret indstilling, der lydløst ignoreres, er værre end ingen indstilling, fordi lytterlisten stadig ser troværdig ud bagefter.

Test webstedet og tunnelen som to separate veje

Indlæs sitet, og forbind tunnelen, og læs derefter lytterlisten igen for at se, hvilken proces der nu ejer 443. En side, der indlæses, beviser intet om VPN, og en tunnel, der forbinder, beviser intet om sitet, selv om begge bruger det samme nummer. De tre kommandoer nedenfor kontrollerer den delte socket, webvejen og VPN-tjenesten i den rækkefølge.

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

Sammenlign klientadressen i backendets adgangslog med den i VPN-loggen for samme øjeblik. Hvis sitet registrerer hver besøgende som værten selv, virker videresendelsen, og adressehåndteringen gør ikke. Hvis begge logge er tavse, har frontenden aldrig overdraget forbindelsen. Uanset hvad afgør lytterlisten, hvem der accepterer socketen, og det er den kendsgerning, der skal bekræftes, før du ændrer endnu en fil.

Lad det lytterkort ligge ved konfigurationen, så den næste person, der rører 443, ved, hvilken proces der accepterer, og hvor den anden protokol blev sendt hen. Bekræft ejerskabet efter ændringen i stedet for at stole på, hvad redigeringen skulle gøre.