OpenVPN og HTTPS á gátt 443: hver á hlustarann?

Tvær þjónustur geta báðar svarað á gátt 443 án þess að keppa nokkurn tíma, því hlustari er skilgreindur af flutningi, vistfangi og gátt saman, ekki af númerinu einu saman. Setjið vefþjón og OpenVPN á eina vél, og eina spurningin sem er þess virði að svara fyrst er hvaða sökkul hvert ferli biður kjarnann um. Skrifið þann lista niður áður en þið breytið stillingum, og flest villur um „vistfang þegar í notkun“ útskýra sig sjálfar. Allt eftir listann er val milli UDP-hlustara, sameiginlegs TCP-sökkls eða framenda sem beinir eftir samskiptareglum.

Byrjið á sökklinum sem hvert ferli biður um

Bind tekst eða mistekst á þessari þrenningu, svo tveir daemonar rekast aðeins á þegar allir þrír hlutarnir falla saman. Þess vegna lifir vefsíða á TCP 443 endalaust samhliða OpenVPN-hlustara á UDP 443, og þess vegna lýkur það líka umræðunni að færa annan þeirra á annað staðbundið vistfang á sama hýsli. Lesið lifandi hlustarana í stað skránna sem áttu að búa þá til, því úrelt include eða gleymd unit-skrá lifir lengur en breytingin sem þið munið eftir að hafa gert.

Keyrið ss -lntup sem root og lesið hverja línu sem nefnir 443, þar á meðal IPv6-færslur. Algildur hlustari fyrir v6 tekur yfirleitt líka við v4-umferð, og þannig heldur hlustari sem þið gleymdu gáttinni upptekinni eftir að þið breyttu skránni sem þið tölduð bera ábyrgð. Ef heiti ferlis kemur ykkur á óvart, þrengið úttakið með ss -lntup 'sport = :443' áður en þið snertið nokkuð.

Skiptið göngunum yfir í UDP þegar netið leyfir

UDP-hlustari kemst alveg hjá árekstrinum og er venjulega stysta viðgerðin, því engum sökkli er deilt og ekkert aukaafurð kemur inn á leiðina. En það er ekki ókeypis. Sum biðlaranet henda UDP 443 án þess að senda reset, svo göngin hætta að koma sér upp í stað þess að mistakast á bind, og notandinn tilkynnir að VPN sé niðri án villu til að lesa. UDP-hlustari lifir líka af endurræsingu veflagsins, sem skiptir máli á vél þar sem síðan er oft endurtekin. Prófið úr netinu þar sem notendurnir sitja, því skel á þjóninum sannar aðeins að þjóninn nái í sjálfan sig.

Breyttu flutningnum í stillingum þjónsins og í sniði biðlarans samtímis. Snið sem biður enn um TCP mun fara í hring endurtenginga gegn hlustara sem er aðeins UDP, og það lítur út eins og netbilun þar til þið berið saman skrárnar tvær.

Leyfið VPN-ferlinu að eiga TCP 443 og sendið afganginn áfram

Community OpenVPN í TCP-þjónsham les fyrstu bætin í innkomandi tengingu og sendir allt sem er ekki eigin samskiptareglur áfram til HTTPS-bakenda, og það er tilgangur tilskipunarinnar port-share. Bakendinn er venjulegur vefþjónn með TLS virkt, nefndur eftir hýsli og gátt í þeirri tilskipun frekar en eftir URL.

port-share 10.0.0.5 8080

Á vél þar sem síðan hefur annað einkavistfang sendir sú lína umferð sem ekki er VPN á 10.0.0.5:8080, svo HTTPS-sýndarhýslinn verður að vera bundinn þar og eldveggurinn verður að leyfa staðbundna stökkið. Vefþjónninn verður að ljúka TLS sjálfur, því bætin sem berast eru upprunaleg handaband vafrans og ekkert þar á milli hefur afkóðað þau. Beinið tilskipuninni að venjulegum HTTP-hlustara og vafrinn fær villu um ógilda aðferð, sem lesin er eins og brotin síða frekar en bakendi á röngum stað. Tilskipunin er aðeins til í TCP-þjónsham, og UDP-hlustari hefur enga strauma til að skoða.

Þar sem VPN-ferlið tekur við hverri tengingu sér vefforritið framsendu beiðnina koma frá einu af eigin vistföngum hýslsins í stað gestarins. Allt sem þarf raunverulegt vistfang biðlarans er háð stuðningi við PROXY-samskiptareglur í bakendanum eða framenda sem bætir þeim við. Að færa bakendann á annað staðbundið vistfang færir vistfang gestarins ekki til baka; það breytir aðeins hvaða vistfang hýslsins síðan skráir. Skrifið þá takmörkun í uppsetningarathugasemdir áður en greiningarskýrsla vekur spurninguna.

Öfugt proxy er rangt verkfæri; beinir á fjórða lagi er það ekki

HTTP öfugt proxy lýkur TLS til að geta lesið beiðnir, sem þýðir að það getur ekki látið OpenVPN-strauma fara ósnortinn í gegn. Beinir á fjórða lagi sem sendir áfram eftir SNI eða skoðun fyrsta pakkans getur staðið fyrir báðum, að því tilskildu að hann ljúki ekki lotunni sem VPN reiðir sig á. Tækin tvö líta eins út á skýringarmynd og hegða sér algjörlega öðruvísi við sökkulinn.

Auglýsinga-Access Server kemur með eigin stillingar fyrir gáttardeilingu, og þær varpast ekki einn-á-einn á tilskipun samfélagsins. Greinið vöruna og útgáfuna áður en þið aðlagið leiðarvísi sem skrifaður er fyrir hina. Afrituð stilling sem er hunsuð í hljóði er verri en engin stilling, því hlustaralistinn lítur enn trúverðugur út eftir á.

Prófið vefsíðuna og göngin sem tvær aðskildar leiðir

Hleðjið síðuna og tengið göngin, lesið svo hlustaralistann aftur til að sjá hvaða ferli á 443 núna. Síða sem hleðst sannar ekkert um VPN, og göng sem tengjast sanna ekkert um síðuna, þótt bæði noti sama númer. Þrjár skipanirnar hér að neðan athuga sameiginlega sökkulinn, vefleiðina og VPN-þjónustuna í þeirri röð.

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

Berið saman vistfang biðlarans í aðgangsskrá bakendans við það í VPN-skránni fyrir sama augnablik. Ef síðan skráir hvern gest sem hýsilinn sjálfan virkar framsendingin og vistfangsmeðferðin ekki. Ef báðar skrárnar þegja gaf framendinn tengingunni aldrei til baka. Hvort sem er, hlustaralistinn ræður því hver tekur við sökklinum, og það er staðreyndin sem þarf að staðfesta áður en þið breytið annarri skrá.

Látið þessa hlustarakort liggja við stillingarnar svo næsti maður sem snertir 443 viti hvaða ferli tekur við og hvert hinar samskiptareglurnar fóru. Staðfestið eignarhaldið eftir breytinguna í stað þess að treysta því sem breytingunni var ætlað að gera.