OpenVPN en HTTPS op poort 443: van wie is de listener?
TCP en UDP 443 zijn aparte sockets. Eén TCP-listener delen vereist een eigenaar, en poortdeling van OpenVPN is een nauwe regeling, geen proxytruc.
Twee diensten kunnen allebei antwoorden op poort 443 zonder ooit te concurreren, omdat een listener wordt bepaald door transport, adres en poort samen, niet door het nummer alleen. Zet een webserver en OpenVPN op één machine, en de enige vraag die eerst een antwoord verdient, is welke socket elk proces aan de kernel vraagt. Schrijf die lijst op voordat je een configuratie bewerkt, en de meeste fouten «adres al in gebruik» verklaren zichzelf. Alles na de lijst is een keuze tussen een UDP-listener, een gedeelde TCP-socket of een frontend die op protocol routeert.
Begin bij de socket die elk proces vraagt
Een bind slaagt of faalt op die triple, dus twee daemons botsen alleen als alle drie de delen samenvallen. Daarom bestaat een website op TCP 443 onbeperkt naast een OpenVPN-listener op UDP 443, en daarom beëindigt het ook de discussie om een van beide naar een tweede lokaal adres op dezelfde host te verplaatsen. Lees de levende listeners in plaats van de bestanden die ze hadden moeten aanmaken, want een verouderde include of een vergeten unit-bestand overleeft de bewerking die je je herinnert.
| 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 |
Voer ss -lntup uit als root en lees elke regel die 443 noemt, inclusief IPv6-vermeldingen. Een wildcard-listener voor v6 accepteert meestal ook v4-verkeer, en zo houdt een vergeten listener de poort bezet nadat je het bestand hebt gewijzigd dat je verantwoordelijk achtte. Als een procesnaam je verrast, beperk de uitvoer dan met ss -lntup 'sport = :443' voordat je iets aanraakt.
Schakel de tunnel naar UDP als het netwerk het toelaat
Een UDP-listener omzeilt de botsing volledig en is meestal de kortste reparatie, omdat er geen socket wordt gedeeld en er geen extra product in het pad komt. Gratis is dat niet. Sommige klantnetwerken laten UDP 443 vallen zonder een reset te sturen, zodat de tunnel ophoudt met opbouwen in plaats van te falen op bind, en de gebruiker meldt dat de VPN platligt zonder fout om te lezen. Een UDP-listener overleeft ook een herstart van de weblaag, wat telt op een machine waarvan de site vaak opnieuw wordt uitgerold. Test vanuit het netwerk waar de gebruikers zitten, want een shell op de server bewijst alleen dat de server zichzelf bereikt.
Wijzig het transport in de serverconfiguratie en in het clientprofiel tegelijk. Een profiel dat nog om TCP vraagt, blijft herverbindingen doorlopen tegen een listener met alleen UDP, en dat lijkt op een netwerkstoring tot je de twee bestanden vergelijkt.
Laat het VPN-proces TCP 443 bezitten en stuur de rest door
Community OpenVPN in TCP-servermodus leest de eerste bytes van een inkomende verbinding en stuurt alles wat niet zijn eigen protocol is door naar een HTTPS-backend, waarvoor de richtlijn port-share dient. De backend is een gewone webserver met TLS ingeschakeld, in die richtlijn genoemd met host en poort in plaats van met een URL.
port-share 10.0.0.5 8080
Op een machine waar de site een tweede privéadres heeft, stuurt die regel niet-VPN-verkeer naar 10.0.0.5:8080, dus de HTTPS-virtuele host moet daar gebonden zijn en de firewall moet de lokale sprong toestaan. De webserver moet TLS zelf beëindigen, omdat de binnenkomende bytes de oorspronkelijke handshake van de browser zijn en niets ertussen ze heeft ontsleuteld. Richt de richtlijn op een gewone HTTP-listener en de browser krijgt een fout voor een ongeldige methode, die leest als een kapotte site in plaats van een verkeerd geplaatste backend. De richtlijn bestaat alleen in TCP-servermodus, en een UDP-listener heeft geen stream om te inspecteren.
Omdat het VPN-proces elke verbinding accepteert, ziet de webapplicatie het doorgestuurde verzoek binnenkomen vanaf een van de eigen adressen van de host in plaats van vanaf de bezoeker. Alles wat het echte clientadres nodig heeft, hangt af van PROXY-protocolondersteuning in de backend of van een frontend die het toevoegt. De backend naar een ander lokaal adres verplaatsen brengt het adres van de bezoeker niet terug; het verandert alleen welke van de hostadressen de site vastlegt. Schrijf die beperking in de uitrolnotities voordat een analyserapport de vraag opwerpt.
Een reverse proxy is het verkeerde gereedschap; een layer-four-router niet
Een HTTP-reverse-proxy beëindigt TLS om verzoeken te kunnen lezen, wat betekent dat hij een OpenVPN-stream niet onaangetast kan doorlaten. Een layer-four-router die doorstuurt op SNI of op inspectie van het eerste pakket, kan voor beide staan, mits hij de sessie waarvan de VPN afhankelijk is niet beëindigt. De twee apparaten lijken op een diagram op elkaar en gedragen zich bij de socket volstrekt anders.
De commerciële Access Server levert eigen instellingen voor poortdeling, en die komen niet één-op-één overeen met de community-richtlijn. Identificeer product en versie voordat je een handleiding aanpast die voor de andere is geschreven. Een gekopieerde instelling die stil wordt genegeerd is erger dan geen instelling, omdat de listenerlijst er daarna nog steeds geloofwaardig uitziet.
Test de website en de tunnel als twee aparte paden
Laad de site en verbind de tunnel, lees daarna de listenerlijst opnieuw om te zien welk proces nu 443 bezit. Een pagina die laadt bewijst niets over de VPN, en een tunnel die verbindt bewijst niets over de site, ook al gebruiken beide hetzelfde nummer. De drie opdrachten hieronder controleren de gedeelde socket, het webpad en de VPN-dienst in die volgorde.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Vergelijk het clientadres in het toegangslog van de backend met dat in het VPN-log voor hetzelfde moment. Als de site elke bezoeker als de host zelf vastlegt, werkt het doorsturen en de adresafhandeling niet. Als beide logs zwijgen, heeft de frontend de verbinding nooit overgedragen. Hoe dan ook, de listenerlijst beslist wie de socket accepteert, en dat is het feit dat je moet bevestigen voordat je nog een bestand wijzigt.
Laat die listenerkaart naast de configuratie liggen, zodat de volgende persoon die 443 aanraakt weet welk proces accepteert en waar het andere protocol heen ging. Bevestig het eigendom na de wijziging in plaats van te vertrouwen op wat de bewerking moest doen.