OpenVPN og HTTPS på port 443: hvem eier lytteren?
TCP og UDP 443 er separate sockets. Å dele én TCP-lytter krever en eier, og OpenVPNs portdeling er en smal ordning, ikke et proxytriks.
To tjenester kan begge svare på port 443 uten å konkurrere, fordi en lytter nøkles på transport, adresse og port sammen, ikke på nummeret alene. Sett en webserver og OpenVPN på én maskin, og det eneste spørsmålet som er verdt å svare på først, er hvilken socket hver prosess ber kjernen om. Skriv ned den listen før du redigerer en konfigurasjon, og de fleste feil med «adressen er allerede i bruk» forklarer seg selv. Alt etter listen er et valg mellom en UDP-lytter, en delt TCP-socket eller en frontend som ruter etter protokoll.
Start med socketen hver prosess ber om
Et bind lykkes eller feiler på den trippelen, så to daemoner kolliderer bare når alle tre delene faller sammen. Derfor sameksisterer et nettsted på TCP 443 ubegrenset med en OpenVPN-lytter på UDP 443, og derfor avslutter det også diskusjonen å flytte en av dem til en annen lokal adresse på samme vert. Les de levende lytterne i stedet for filene som skulle ha opprettet dem, fordi et utdatert include eller en glemt unit-fil overlever redigeringen du husker at du gjorde.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Kjør ss -lntup som root og les hver linje som nevner 443, inkludert IPv6-oppføringer. En jokertegn-lytter for v6 godtar vanligvis også v4-trafikk, og slik holder en lytter du glemte porten opptatt etter at du endret filen du trodde var ansvarlig. Hvis et prosessnavn overrasker deg, begrens utdataene med ss -lntup 'sport = :443' før du berører noe.
Bytt tunnelen til UDP når nettverket tillater det
En UDP-lytter omgår kollisjonen helt og er vanligvis den korteste reparasjonen, siden ingen socket deles og ingen ekstra produkt kommer inn på veien. Det er ikke gratis. Noen klientnettverk dropper UDP 443 uten å sende reset, så tunnelen slutter å etablere seg i stedet for å feile på bind, og brukeren rapporterer at VPN er nede uten noen feil å lese. En UDP-lytter overlever også en omstart av weblaget, noe som teller på en maskin der nettstedet ofte rulles ut på nytt. Test fra nettverket der brukerne sitter, fordi et skall på serveren bare beviser at serveren når seg selv.
Endre transporten i serverkonfigurasjonen og i klientprofilen samtidig. En profil som fortsatt ber om TCP vil gå i løkker med gjenoppkoblinger mot en lytter som bare har UDP, og det ser ut som en nettverksfeil til du sammenligner de to filene.
La VPN-prosessen eie TCP 443 og videresend resten
Community OpenVPN i TCP-servermodus leser de første bytene av en innkommende tilkobling og videresender alt som ikke er dens egen protokoll til en HTTPS-backend, og det er hva direktivet port-share er til. Backenden er en vanlig webserver med TLS aktivert, navngitt med vert og port i det direktivet i stedet for med en URL.
port-share 10.0.0.5 8080
På en maskin der nettstedet har en annen privat adresse, sender den linjen ikke-VPN-trafikk til 10.0.0.5:8080, så den virtuelle HTTPS-verten må være bundet der og brannmuren må tillate det lokale hoppet. Webserveren må avslutte TLS selv, fordi bytene som ankommer er nettleserens opprinnelige håndtrykk og ingenting imellom har dekryptert dem. Rett direktivet mot en vanlig HTTP-lytter og nettleseren får en ugyldig-metode-feil, som leses som et ødelagt nettsted snarere enn en feilplassert backend. Direktivet finnes bare i TCP-servermodus, og en UDP-lytter har ingen strøm å inspisere.
Fordi VPN-prosessen godtar hver tilkobling, ser webapplikasjonen den videresendte forespørselen komme fra en av vertens egne adresser i stedet for fra besøkende. Alt som trenger den ekte klientadressen, avhenger av PROXY-protokollstøtte i backenden eller av en frontend som legger den til. Å flytte backenden til en annen lokal adresse bringer ikke den besøkendes adresse tilbake; det endrer bare hvilken av vertens adresser nettstedet registrerer. Skriv den begrensningen i utrullingsnotatene før en analyserapport reiser spørsmålet.
En omvendt proxy er feil verktøy; en layer-fire-ruter er det ikke
En HTTP-omvendt proxy avslutter TLS for å kunne lese forespørsler, noe som betyr at den ikke kan slippe en OpenVPN-strøm gjennom urørt. En layer-fire-ruter som videresender etter SNI eller etter inspeksjon av den første pakken, kan stå foran begge, forutsatt at den ikke avslutter økten VPN er avhengig av. De to enhetene ser like ut på et diagram og oppfører seg helt forskjellig ved socketen.
Kommersiell Access Server leveres med egne innstillinger for portdeling, og de svarer ikke en-til-en til community-direktivet. Identifiser produktet og versjonen før du tilpasser en veiledning skrevet for den andre. En kopiert innstilling som stilles ignorert er verre enn ingen innstilling, fordi lytterlisten fortsatt ser troverdig ut etterpå.
Test nettstedet og tunnelen som to separate veier
Last nettstedet og koble til tunnelen, og les deretter lytterlisten på nytt for å se hvilken prosess som eier 443 nå. En side som lastes, beviser ingenting om VPN, og en tunnel som kobles til, beviser ingenting om nettstedet, selv om begge bruker samme nummer. De tre kommandoene nedenfor sjekker den delte socketen, webveien og VPN-tjenesten i den rekkefølgen.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Sammenlign klientadressen i backendens tilgangslogg med den i VPN-loggen for samme øyeblikk. Hvis nettstedet registrerer hver besøkende som verten selv, virker videresendingen og adressehåndteringen ikke. Hvis begge loggene er tause, har frontenden aldri overlevert tilkoblingen. Uansett avgjør lytterlisten hvem som godtar socketen, og det er faktumet som må bekreftes før du endrer en annen fil.
La det lytterkartet ligge ved konfigurasjonen, slik at neste person som berører 443 vet hvilken prosess som godtar og hvor den andre protokollen tok veien. Bekreft eierskapet etter endringen i stedet for å stole på hva redigeringen skulle gjøre.