OpenVPN ja HTTPS portissa 443: kuka omistaa kuuntelijan?
TCP ja UDP 443 ovat erillisiä socketeja. Yhden TCP-kuuntelijan jakaminen vaatii omistajan, ja OpenVPN:n portinjakaminen on kapea järjestely, ei välityspalvelukikka.
Kaksi palvelua voi molemmat vastata portissa 443 kilpailematta koskaan, koska kuuntelija määräytyy kuljetuksen, osoitteen ja portin yhteisperusteella, ei numeron perusteella yksin. Laita verkkopalvelin ja OpenVPN samaan koneeseen, ja ainoa ensin vastaamisen arvoinen kysymys on, minkä socken kukin prosessi pyytää ytimeltä. Kirjoita se lista muistiin ennen kuin muokkaat kokoonpanoa, ja useimmat ”osoite on jo käytössä” -virheet selittävät itsensä. Kaikki listan jälkeen on valinta UDP-kuuntelijan, jaetun TCP-socken tai protokollan mukaan reitittävän edustan välillä.
Aloita sockesta, jota kukin prosessi pyytää
Bind onnistuu tai epäonnistuu tuon kolmikon perusteella, joten kaksi daemonia törmäävät vain, kun kaikki kolme osaa osuvat yhteen. Siksi verkkosivusto TCP 443:ssa elää rinnakkain loputtomasti OpenVPN-kuuntelijan kanssa UDP 443:ssa, ja siksi toisen siirtäminen toiseen paikalliseen osoitteeseen samassa isännässä päättää myös väittelyn. Lue elävät kuuntelijat sen sijaan, että lukisit tiedostoja, joiden piti luoda ne, koska vanhentunut include tai unohdettu unit-tiedosto elää kauemmin kuin muokkaus, jonka muistat tehneesi.
| 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 |
Aja ss -lntup rootina ja lue jokainen rivi, joka mainitsee 443, myös IPv6-merkinnät. Yleiskuuntelija v6:lle hyväksyy yleensä myös v4-liikennettä, ja niin unohdettu kuuntelija pitää portin varattuna sen jälkeen, kun muutat tiedostoa, jota luulit vastuulliseksi. Jos prosessin nimi yllättää, kavenna tulostetta komennolla ss -lntup 'sport = :443' ennen kuin kosket mihinkään.
Vaihda tunneli UDP:hen, kun verkko sallii sen
UDP-kuuntelija väistää törmäyksen kokonaan ja on yleensä lyhin korjaus, koska sockea ei jaeta eikä polulle liity ylimääräistä tuotetta. Ilmaista se ei ole. Jotkin asiakasverkot pudottavat UDP 443:n lähettämättä resetiä, joten tunneli lakkaa muodostumasta sen sijaan, että bind epäonnistuisi, ja käyttäjä ilmoittaa VPN:n olevan alhaalla ilman luettavaa virhettä. UDP-kuuntelija kestää myös verkkokerroksen uudelleenkäynnistyksen, millä on merkitystä koneessa, jonka sivusto julkaistaan usein uudelleen. Testaa verkosta, jossa käyttäjät istuvat, koska palvelimen shell todistaa vain, että palvelin tavoittaa itsensä.
Muuta kuljetusta palvelimen kokoonpanossa ja asiakasprofiilissa yhdessä. Profiili, joka pyytää edelleen TCP:tä, kiertää uudelleenyhdistämiskierroksissa vain UDP-kuuntelijaa vastaan, ja se näyttää verkkohäiriöltä, kunnes vertaat kahta tiedostoa.
Anna VPN-prosessin omistaa TCP 443 ja välitä loput eteenpäin
Community OpenVPN TCP-palvelintilassa lukee saapuvan yhteyden ensimmäiset tavut ja välittää kaiken, mikä ei ole sen oma protokolla, HTTPS-taustaosaan, ja sitä varten direktiivi port-share on. Taustaosa on tavallinen verkkopalvelin, jossa TLS on käytössä, ja se nimetään kyseisessä direktiivissä isännällä ja portilla, ei URL:lla.
port-share 10.0.0.5 8080
Koneessa, jossa sivustolla on toinen yksityinen osoite, tuo rivi lähettää ei-VPN-liikenteen osoitteeseen 10.0.0.5:8080, joten HTTPS-näennäisisäntä on sidottava sinne ja palomuurin on sallittava paikallinen hyppy. Verkkopalvelimen on lopetettava TLS itse, koska saapuvat tavut ovat selaimen alkuperäinen kättely eikä mikään välissä ole purkanut niitä. Kohdista direktiivi tavalliseen HTTP-kuuntelijaan ja selain saa virheellisen menetelmän virheen, joka luetaan rikkinäisenä sivustona eikä väärin sijoitettuna taustaosana. Direktiivi on olemassa vain TCP-palvelintilassa, eikä UDP-kuuntelijalla ole virtaa tarkasteltavaksi.
Koska VPN-prosessi hyväksyy jokaisen yhteyden, verkkosovellus näkee välitetyn pyynnön saapuvan yhdestä isännän omasta osoitteesta kävijän sijaan. Kaikki, mikä tarvitsee todellisen asiakasosoitteen, riippuu PROXY-protokollan tuesta taustaosassa tai edustasta, joka lisää sen. Taustaosan siirtäminen toiseen paikalliseen osoitteeseen ei tuo kävijän osoitetta takaisin; se muuttaa vain sitä, minkä isännän osoitteista sivusto tallentaa. Kirjoita tuo rajoitus käyttöönottomuistiinpanoihin ennen kuin analytiikkaraportti nostaa kysymyksen esiin.
Käänteinen välityspalvelin on väärä työkalu; neljännen kerroksen reititin ei ole
HTTP-käänteinen välityspalvelin lopettaa TLS:n voidakseen lukea pyyntöjä, mikä tarkoittaa, että se ei voi päästää OpenVPN-virtaa läpi koskemattomana. Neljännen kerroksen reititin, joka välittää SNI:n tai ensimmäisen paketin tarkastuksen perusteella, voi seisoa molempien edessä, edellyttäen ettei se lopeta istuntoa, josta VPN on riippuvainen. Kaksi laitetta näyttävät kaaviossa samalta ja käyttäytyvät socken luona täysin eri tavalla.
Kaupallinen Access Server tuo mukanaan omat portinjakamisasetuksensa, eivätkä ne vastaa yksi yhteen community-direktiiviä. Tunnista tuote ja versio ennen kuin sovitat toiselle kirjoitettua opasta. Kopioitu asetus, joka jätetään hiljaa huomiotta, on huonompi kuin asetuksen puuttuminen, koska kuuntelijalista näyttää sen jälkeen yhä uskottavalta.
Testaa sivusto ja tunneli kahtena erillisenä polkuna
Lataa sivusto ja yhdistä tunneli, lue sitten kuuntelijalista uudelleen nähdäksesi, mikä prosessi nyt omistaa 443:n. Latautuva sivu ei todista mitään VPN:stä, eikä yhdistyvä tunneli todista mitään sivustosta, vaikka molemmat käyttävät samaa numeroa. Alla olevat kolme komentoa tarkistavat jaetun socken, verkkopolun ja VPN-palvelun tuossa järjestyksessä.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Vertaa asiakasosoitetta taustaosan käyttölokissa VPN-lokin vastaavaan samalla hetkellä. Jos sivusto tallentaa jokaisen kävijän isäntänä itseään, välitys toimii eikä osoitteenkäsittely toimi. Jos molemmat lokit vaikenevat, edusta ei koskaan luovuttanut yhteyttä. Kummassakin tapauksessa kuuntelijalista ratkaisee, kuka hyväksyy socken, ja se on tosiasia, joka on vahvistettava ennen kuin muutat toista tiedostoa.
Jätä tuo kuuntelijakartta kokoonpanon viereen, jotta seuraava 443:een koskeva tietää, mikä prosessi hyväksyy ja minne toinen protokolla meni. Vahvista omistus muutoksen jälkeen sen sijaan, että luottaisit siihen, mitä muokkauksen piti tehdä.