OpenVPN og HTTPS på port 443: kven eig lyttaren?

To tenester kan båe svare på port 443 utan å konkurrere, fordi ein lyttar blir nøkla på transport, adresse og port saman, ikkje på nummeret åleine. Set ein webserver og OpenVPN på éi maskin, og det einaste spørsmålet som er verdt å svare på først, er kva socket kvar prosess ber kjernen om. Skriv ned den lista før du redigerer ein konfigurasjon, og dei fleste feila med «adressa er alt i bruk» forklarer seg sjølv. Alt etter lista er eit val mellom ein UDP-lyttar, ein delt TCP-socket eller ein frontend som rutar etter protokoll.

Start med socketen kvar prosess ber om

Eit bind lukkast eller feilar på den trippelen, så to daemonar kolliderer berre når alle tre delane fell saman. Difor finst eit nettstad på TCP 443 utan grense saman med ein OpenVPN-lyttar på UDP 443, og difor avsluttar det òg diskusjonen å flytte ein av dei til ei anna lokal adresse på same vert. Les dei levande lyttarane i staden for filene som skulle ha oppretta dei, fordi eit utdatert include eller ei gløymd unit-fil overlever redigeringa du hugsar at du gjorde.

Køyr ss -lntup som root og les kvar linje som nemner 443, inkludert IPv6-oppføringar. Ein jokerteikn-lyttar for v6 godtek vanlegvis òg v4-trafikk, og slik held ein lyttar du gløymde porten oppteken etter at du endra fila du trudde var ansvarleg. Om eit prosessnamn overraskar deg, avgrens utdataa med ss -lntup 'sport = :443' før du rører noko.

Bytt tunnelen til UDP når nettet tillèt det

Ein UDP-lyttar går heilt utanom kollisjonen og er vanlegvis den kortaste reparasjonen, sidan ingen socket blir delt og ingen ekstra produkt kjem inn på vegen. Det er ikkje gratis. Nokre klientnett droppar UDP 443 utan å sende reset, så tunnelen sluttar å etablere seg i staden for å feile på bind, og brukaren rapporterer at VPN er nede utan nokon feil å lese. Ein UDP-lyttar overlever òg ein omstart av weblaget, noko som tel på ei maskin der nettstaden ofte blir rulla ut på nytt. Test frå nettet der brukarane sit, fordi eit skal på tenaren berre provar at tenaren når seg sjølv.

Endre transporten i tenarkonfigurasjonen og i klientprofilen samstundes. Ein profil som framleis ber om TCP vil gå i løkker med attoppkoplingar mot ein lyttar som berre har UDP, og det ser ut som ein nettfeil til du samanliknar dei to filene.

Lat VPN-prosessen eige TCP 443 og send resten vidare

Community OpenVPN i TCP-tenarmodus les dei første byta av ei innkomande tilkopling og sender alt som ikkje er dens eigen protokoll vidare til ein HTTPS-backend, og det er kva direktivet port-share er til. Backenden er ein vanleg webserver med TLS aktivert, namngjeven med vert og port i det direktivet i staden for med ein URL.

port-share 10.0.0.5 8080

På ei maskin der nettstaden har ei anna privat adresse, sender den linja ikkje-VPN-trafikk til 10.0.0.5:8080, så den virtuelle HTTPS-verten må vere bunden der og brannmuren må tillate det lokale hoppet. Webserveren må avslutte TLS sjølv, fordi byta som kjem er nettlesaren sitt opphavlege handtrykk og ingenting imellom har dekryptert dei. Rett direktivet mot ein vanleg HTTP-lyttar og nettlesaren får ein feil for ugyldig metode, som blir lesen som ein øydelagd nettstad snarare enn ein feilplassert backend. Direktivet finst berre i TCP-tenarmodus, og ein UDP-lyttar har ingen straum å inspisere.

Fordi VPN-prosessen godtek kvar tilkopling, ser webapplikasjonen den videresende førespurnaden kome frå ei av verten sine eigne adresser i staden for frå den besøkande. Alt som treng den verkelege klientadressa, er avhengig av PROXY-protokollstøtte i backenden eller av ein frontend som legg ho til. Å flytte backenden til ei anna lokal adresse bringer ikkje adressa til den besøkande tilbake; det endrar berre kva av verten sine adresser nettstaden registrerer. Skriv den avgrensinga i utrullingsnotata før ein analyserapport reiser spørsmålet.

Ein omvend proxy er feil verkty; ein layer-fire-rutar er det ikkje

Ein HTTP-omvend proxy avsluttar TLS for å kunne lese førespurnader, noko som tyder at han ikkje kan sleppe ein OpenVPN-straum gjennom urørt. Ein layer-fire-rutar som sender vidare etter SNI eller etter inspeksjon av den første pakken, kan stå føre båe, føresett at han ikkje avsluttar økta VPN er avhengig av. Dei to einingane ser like ut på eit diagram og oppfører seg heilt ulikt ved socketen.

Kommersiell Access Server kjem med eigne innstillingar for portdeling, og dei svarar ikkje ein-til-ein til community-direktivet. Identifiser produktet og versjonen før du tilpassar ein rettleiar skriven for den andre. Ei kopiert innstilling som blir stilt ignorert er verre enn inga innstilling, fordi lyttarlista framleis ser truverdig ut etterpå.

Test nettstaden og tunnelen som to skilde vegar

Last nettstaden og kople til tunnelen, og les deretter lyttarlista på nytt for å sjå kva prosess som eig 443 no. Ei side som lastar, provar ingenting om VPN, og ein tunnel som koplar til, provar ingenting om nettstaden, sjølv om båe brukar same nummer. Dei tre kommandoane nedanfor sjekkar den delte socketen, webvegen og VPN-tenesta i den rekkjefølgja.

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

Samanlikn klientadressa i tilgangsloggen til backenden med den i VPN-loggen for same augneblink. Om nettstaden registrerer kvar besøkande som verten sjølv, verkar videresendinga og adressehandteringa ikkje. Om båe loggane er tause, har frontenden aldri overlevert tilkoplinga. Uansett avgjer lyttarlista kven som godtek socketen, og det er faktumet som må stadfestast før du endrar ei anna fil.

Lat det lyttarkartet liggje ved konfigurasjonen, slik at neste person som rører 443 veit kva prosess som godtek og kvar den andre protokollen tok vegen. Stadfest eigarskapet etter endringa i staden for å stole på kva redigeringa skulle gjere.