OpenVPN bak við stunnel: sendu umbúðirnar áfram, ekki port 1194

Setjið TLS-umbúðir fyrir framan OpenVPN og uppsetningin fær annan hlustanda, en aðeins einn þeirra ætti nokkurn tíma að snúa að internetinu. Þegar göngin virka frá sömu vél og mistakast utan frá, beinist áframsendingin venjulega að þeim ranga af tveimur. Það sem verður að stemma er keðja: opinbera reglan nær til umbúðanna, og eigin bakendatenging umbúðanna nær til raunverulega VPN-sokksins. Fjögur stökk bera þessa keðju, og hvaðeina þeirra getur endað rannsóknina snemma.

Tveir sokkar, tveir eigendur, einn þeirra opinber

Umbúðirnar ljúka TLS fyrir ytri tenginguna og senda afkóðaða bætastreyminu til venjulegs OpenVPN TCP-hlustanda. Þetta eru aðskildir sokkar með aðskildum stillingarskrám, þannig að breyting á öðrum lætur hinn ósnortinn og enn sýnilega heilan. Það þýðir líka að þeir geta rekið sig hvorn frá öðrum hvenær sem öðrum er breytt án hins.

Vinna frá vélinni sjálfri sannar því mjög litlu um opinberu leiðina. Bein tenging við innbyggða portið sleppir umbúðunum, tenging við umbúðirnar á LAN-heimilíði þeirra sleppir þýðingunni, og aðeins fullkomið fyrirkomulag á biðlarahlið æfir það sem utanaðkomandi notandi gerir. Nöfn verður líka að lesa vandlega, því localhost merkir hýsilinn sem keyrir þá tilteknu einingu, en ekki hýsilinn sem þú ert fyrir tilviljun að skrifa á. Haltu þessum greinarmun í athugasemdunum þínum, því próf sem skráð er án stökksins sem það náði yfir býður upp á samanburð tveggja ólíkra hluta.

Hvar áframsendingin lendir í raun

Auðveldara er að halda keðjunni sem fjórum stökkum en sem þremur portnúmerum, því sama númerið getur þýtt mismunandi hluti á hvorum enda. Lestu töfluna línu fyrir línu: hver lína er einn sokkur sem verður að taka við tengingu og opna svo þann næsta. Þegar lína beinist að röngum mótaðila, er einkennið í síðasta dálki það sem notandinn greinir frá.

Regla sem beinist að innbyggða VPN-portinu í stað umbúðanna sleppir TLS-lokuninni algjörlega, og það er algengasta mynd þessarar villu: biðlarinn opnar handaband við hlustanda sem væntir OpenVPN-ramma, svo tengingin getur opnast og stöðvast svo. Staðfestið þýdda portið gegn stillingarskrá umbúðanna en ekki minninu, því næsta manneskja sem breytir þeirri skrá hefur kannski valið annað númer. Tvær skipanirnar hér að neðan sýna báðar hliðar þeirrar spurningar í einu.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

Bindheimilíðið sem neitar þér

Accept-lína bundin við 127.0.0.1 svarar aðeins hýsilnum sjálfum, svo áframsending sem kemur á LAN-heimilíðið getur ekki tengst og biðlarinn sér höfnun sem hljómar eins og vandamál pakkasíu. Lítið á sokkinn áður en snert er við eldvegginn, því sokkurinn er ódýrara svarið. Annaðhvort bindið umbúðirnar við viðmótið sem áframsendingin beinist að, eða haldið þeim á loopback og gætið þess að áframsendingin nái loopback í gegnum eitthvað sem virkar í raun. Þetta eru tvær hönnunir, og hvora þeirra þarf sína eigin reglu.

Að blanda þeim er hvernig vinnandi umbúðir enda óaðgengilegar utan frá meðan hver skrá virðist rétt. Athugunin hér að neðan er ein skipun, og hún svarar spurningu sem endurskoðun eldveggjareglnanna getur ekki. Ef úttakið sýnir loopback-heimilíð meðan áframsendingin beinist að LAN-heimilíðinu, þá á leiðréttingin heima í accept-línunni en ekki í pakkasíunni.

ss -lntp '( sport = :8443 )'

Hvað staðbundið próf sannaði í raun

Árangur sem skráður er án stökksins sem hann náði yfir er ekki sönnun um hin stökkin. Takið eftir hvaða heimilíð prófið notaði og hvaða ferli svaraði. Endurtakið svo utan netsins frekar en úr síma á sama Wi-Fi, því hárnálshegðun er mismunandi milli beina og tenging sem fór aldrei út af LAN-inu getur fullnægt biðlara án þess að áframsendingin eigi þátt yfirleitt. Aðeins sú önnur tilraun þjálfar þá leið sem ókunnugur fer.

Þegar tilraunin mistekst, fylgið einni tengingu í báðum annálunum: samþykktum og tengdum línum umbúðanna, svo setuannál VPN-púkans sjálfs. Fyrsta mörkin sem skrá ekkert er þar sem næsta breyting á heima. Þegar OpenVPN fer að bera saman valkosti mótaðilans, metið þau skilaboð eftir reglum þeirrar útfærslu. Viðvörun um ósamræmi í link-mtu er ekki sjálfkrafa banvæn, að festa link-mtu við 1500 sannar ekki að sundrung hafi stöðvast, og dulritunarviðræður tilheyra innri OpenVPN-stillingunni en ekki áframsendingu beinisins.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Þessar prófanir ná yfir bakendasokkinn og annál umbúðanna, sem aðgreinir hafnaðan bakenda frá hafnaðri handabandi. Keyrið þær meðan ein tilraun er í gangi en ekki eftir á. Tímastimplar frá einni tilraun eru það sem gerir samanburðinn áreiðanlegan.

Tvö auðkenni, tvær bilunarröð

Ytra vottorðið tilheyrir umbúðunum og innra auðkennið tilheyrir OpenVPN, og þau geta komið frá mismunandi yfirvöldum. Að slökkva á annarri hvorri athuguninni til að láta leið virðast heila skiptir raunverulegri vernd fyrir kosmetíska niðurstöðu. Haldið báðum staðfestingum og kembið þær í röð, því röð skilaboðanna nefnir lagið: vandamál með vottorð umbúðanna birtist áður en nokkur VPN-valkostur er saminn, en bilun innra auðkennis birtist aðeins eftir að streyminu hefur verið komið á.

stunnel handbókin skilgreinir accept, connect og biðlarastillingu nákvæmlega, og þessir kaflar svara sokkspurningunni hraðar en að giska. Þegar þið getið enn ekki sagt hvaða lag svaraði, lesið vottorðið sem opinbera portið sýnir með skipuninni hér að neðan. Vottorð umbúðanna í úttakinu þýðir að áframsendingin náði umbúðunum, og þögn eða samskiptavilla þýðir að hún gerði það ekki. Sá eini greinarmunur sparar meiri tíma en nokkur önnur athugun hér.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer