OpenVPN za stunnelom: posredujte ovoj, ne vrata 1194

Postavite TLS ovoj pred OpenVPN in uvedba dobi drugega poslušalca, od katerih bi se moral le eden kdaj soočiti z internetom. Ko tunel deluje z istega stroja in spodleti od zunaj, je posredovanje običajno usmerjeno na napačnega od dveh. Kar se mora ujemati, je veriga: javno pravilo doseže ovoj, lastna backend povezava ovoja pa doseže pravi VPN vtič. Štirje skoki nosijo to verigo in kateri koli od njih lahko preiskavo konča zgodaj.

Dva vtiča, dva lastnika, eden javen

Ovoj zaključi TLS za zunanjo povezavo in prepusti dešifriran bajtni tok običajnemu poslušalcu OpenVPN TCP. To so ločeni vtiči z ločenimi konfiguracijskimi datotekami, zato urejanje enega pusti drugega nedotaknjenega in še vedno navidez zdravega. Pomeni tudi, da se lahko dva razideta, kadar se eden spremeni brez drugega.

Delo s samega stroja zato dokaže zelo malo o javni poti. Neposredna povezava na izvorna vrata ovoj preskoči, povezava na ovoj na njegovem naslovu LAN preskoči prevajanje, in samo celotna postavitev na strani odjemalca izvaja to, kar počne zunanji uporabnik. Tudi imena je treba brati previdno, ker localhost pomeni gostitelja, na katerem teče prav ta komponenta, in ne gostitelja, na katerem slučajno tipkate. To razliko hranite v svojih zapiskih, ker test, zabeležen brez skoka, ki ga je pokrival, vabi k primerjavi dveh različnih stvari.

Kam posredovanje dejansko pristane

Verigo je lažje držati kot štiri skoke kot kot tri številke vrat, ker lahko ista številka na vsakem koncu pomeni nekaj drugega. Berite tabelo vrstico za vrstico: vsaka vrstica je en vtič, ki mora sprejeti povezavo in nato odpreti naslednjo. Ko je vrstica usmerjena na napačnega partnerja, je simptom v zadnjem stolpcu tisto, kar poroča uporabnik.

Pravilo, ki cilja na izvorna vrata VPN namesto na ovoj, popolnoma preskoči zaključek TLS, in to je najpogostejša oblika te napake: odjemalec odpre rokovanje s poslušalcem, ki pričakuje okvirjanje OpenVPN, zato se povezava lahko odpre in nato obstane. Preverite prevedena vrata v konfiguracijski datoteki ovoja in ne v spominu, ker je naslednja oseba, ki bo urejala to datoteko, morda izbrala drugo številko. Spodnja dva ukaza hkrati pokažeta obe strani tega vprašanja.

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

Naslov vezave, ki vas zavrne

Vrstica accept, vezana na 127.0.0.1, odgovori samo gostitelju samemu, zato se posredovanje, ki prispe na naslov LAN, ne more povezati in odjemalec vidi zavrnitev, ki se sliši kot težava paketnega filtra. Poglejte vtič, preden se dotaknete požarnega zidu, ker je vtič cenejši odgovor. Ali povežite ovoj z vmesnikom, na katerega cilja posredovanje, ali ga pustite na loopbacku in poskrbite, da posredovanje doseže loopback prek nečesa, kar resnično deluje. To sta dva načrta in vsak potrebuje svoje pravilo.

Njuno mešanje je način, kako delujoč ovoj postane od zunaj nedosegljiv, medtem ko je vsaka datoteka videti pravilna. Spodnja kontrola je en ukaz in odgovori na vprašanje, na katero pregled pravil požarnega zidu ne more. Če izpis kaže naslov loopback, medtem ko posredovanje cilja na naslov LAN, popravek sodi v vrstico accept in ne v paketni filter.

ss -lntp '( sport = :8443 )'

Kaj je lokalni test v resnici dokazal

Uspeh, zabeležen brez skoka, ki ga je pokrival, ni dokaz o drugih skokih. Zapišite, kateri naslov je test uporabil in kateri proces je odgovoril. Nato to ponovite zunaj omrežja in ne s telefona v istem omrežju Wi-Fi, ker se vedenje lasnice razlikuje med usmerjevalniki in povezava, ki ni nikoli zapustila LAN, lahko zadovolji odjemalca, ne da bi bilo posredovanje sploh vključeno. Le ta drugi poskus vadi pot, ki jo ubere tujec.

Ko poskus spodleti, sledite eni sami povezavi v obeh dnevnikih: sprejetih in povezanih vrsticah ovoja, nato dnevniku seje demona VPN. Prva meja, ki ničesar ne zabeleži, je mesto naslednje spremembe. Ko OpenVPN začne primerjati možnosti partnerja, presojajte ta sporočila po pravilih te izvedbe. Opozorilo o neskladju link-mtu ni samodejno usodno, pripenjanje link-mtu na 1500 ne dokazuje, da se je razdrobljenost ustavila, pogajanje o šifri pa sodi v notranjo konfiguracijo OpenVPN in ne v posredovanje usmerjevalnika.

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

Te sonde pokrivajo backend vtič in dnevnik ovoja, kar loči zavrnjen backend od zavrnjenega rokovanja. Zaženite jih, medtem ko poteka en poskus, in ne pozneje. Časovni žigi iz enega poskusa so tisto, kar naredi primerjavo zanesljivo.

Dve identiteti, dva vrstna reda odpovedi

Zunanje potrdilo pripada ovoju, notranja identiteta pa OpenVPN, in lahko prihajata od različnih organov. Izklop katere koli od dveh preverjanj, da bi bila pot videti zdrava, zamenja resnično zaščito za kozmetični rezultat. Ohranite obe preverjanji in ju razhroščujte po vrsti, ker zaporedje sporočil poimenuje plast: težava s potrdilom ovoja se pojavi, preden se pogaja katera koli možnost VPN, medtem ko se odpoved notranje identitete pojavi šele, ko je tok vzpostavljen.

priročnik stunnel natančno opredeljuje accept, connect in način odjemalca, ti razdelki pa odgovorijo na vprašanje o vtiču hitreje kot ugibanje. Ko še vedno ne morete reči, katera plast je odgovorila, preberite potrdilo, ki ga predstavi javna vrata, z ukazom spodaj. Potrdilo ovoja v izpisu pomeni, da je posredovanje doseglo ovoj, tišina ali napaka protokola pa pomeni, da ga ni doseglo. Ta ena razlika prihrani več časa kot katera koli druga kontrola tukaj.

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