OpenVPN už stunnel: perduokite apvalkalą, o ne 1194 prievadą

Padėkite TLS apvalkalą prieš OpenVPN ir diegimas gauna antrą klausytoją, iš kurių tik vienas kada nors turėtų žiūrėti į internetą. Kai tunelis veikia iš tos pačios mašinos, o iš išorės nepavyksta, peradresavimas paprastai nukreiptas į netinkamą iš dviejų. Tai, kas turi sutapti, yra grandinė: viešoji taisyklė pasiekia apvalkalą, o paties apvalkalo backend ryšys pasiekia tikrąjį VPN lizdą. Keturi šuoliai neša šią grandinę, ir bet kuris jų gali užbaigti tyrimą anksčiau.

Du lizdai, du savininkai, vienas jų viešas

Apvalkalas užbaigia TLS išoriniam ryšiui ir perduoda iššifruotą baitų srautą paprastam OpenVPN TCP klausytojui. Tai atskiri lizdai su atskirais konfigūracijos failais, todėl vieno redagavimas palieka kitą nepaliestą ir vis dar iš pažiūros sveiką. Tai taip pat reiškia, kad du gali nutolti vienas nuo kito, kai vienas keičiamas be kito.

Darbas iš pačios mašinos todėl labai mažai įrodo apie viešąjį kelią. Tiesioginis ryšys su vietiniu prievadu praleidžia apvalkalą, ryšys su apvalkalu jo LAN adresu praleidžia vertimą, ir tik visa kliento pusės sąranga išbando tai, ką daro išorinis naudotojas. Vardus taip pat reikia skaityti atidžiai, nes localhost reiškia hostą, kuriame veikia būtent tas komponentas, o ne hostą, kuriame atsitiktinai rašote. Laikykite šį skirtumą savo užrašuose, nes testas, užfiksuotas nepažymėjus jo apimto šuolio, kviečia lyginti du skirtingus dalykus.

Kur peradresavimas iš tikrųjų nusileidžia

Grandinę lengviau išlaikyti kaip keturis šuolius nei kaip tris prievadų numerius, nes tas pats numeris kiekviename gale gali reikšti skirtingus dalykus. Skaitykite lentelę eilutė po eilutės: kiekviena eilutė yra vienas lizdas, kuris turi priimti ryšį ir tada atidaryti kitą. Kai eilutė nukreipta į netinkamą partnerį, paskutinio stulpelio simptomas yra tai, apie ką praneša naudotojas.

Taisyklė, nukreipta į vietinį VPN prievadą, o ne į apvalkalą, visiškai praleidžia TLS užbaigimą, ir tai yra labiausiai paplitusi šios klaidos forma: klientas atidaro rankos paspaudimą su klausytoju, kuris tikisi OpenVPN kadravimo, todėl ryšys gali atsidaryti ir tada sustoti. Patikrinkite išverstą prievadą pagal apvalkalo konfigūracijos failą, o ne pagal atmintį, nes kitas žmogus, redaguosiantis tą failą, galbūt pasirinko kitą numerį. Dvi komandos žemiau vienu metu parodo abi šio klausimo puses.

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

Susiejimo adresas, kuris jus atmeta

Accept eilutė, susieta su 127.0.0.1, atsako tik pačiam hostui, todėl peradresavimas, atvykstantis į LAN adresą, negali prisijungti ir klientas mato atmetimą, kuris skamba kaip paketų filtro problema. Pažiūrėkite į lizdą prieš liesdami užkardą, nes lizdas yra pigesnis atsakymas. Arba susiekite apvalkalą su sąsaja, į kurią nukreiptas peradresavimas, arba laikykite jį loopback ir padarykite, kad peradresavimas pasiektų loopback per kažką, kas tikrai veikia. Tai du projektai, ir kiekvienas turi savo taisyklę.

Jų maišymas yra tai, dėl ko veikiantis apvalkalas tampa nepasiekiamas iš išorės, nors kiekvienas failas atrodo teisingai. Žemiau esanti patikra yra viena komanda, ir ji atsako į klausimą, į kurį užkardos taisyklių apžvalga negali. Jei išvestis rodo loopback adresą, o peradresavimas nukreiptas į LAN adresą, pataisymas priklauso accept eilutei, o ne paketų filtrui.

ss -lntp '( sport = :8443 )'

Ką vietinis testas iš tikrųjų įrodė

Sėkmė, užfiksuota nepažymėjus jos apimto šuolio, nėra įrodymas apie kitus šuolius. Užsirašykite, kokį adresą naudojo testas ir kuris procesas atsakė. Tada pakartokite iš už tinklo, o ne iš telefono tame pačiame Wi-Fi, nes plaukų segtuko elgsena skiriasi tarp maršrutizatorių, ir ryšys, kuris niekada nepaliko LAN, gali patenkinti klientą, kai peradresavimas visiškai nedalyvauja. Tik tas antras bandymas praktikuoja kelią, kuriuo eina nepažįstamasis.

Kai bandymas nepavyksta, sekite vieną ryšį abiejuose žurnaluose: apvalkalo priimtose ir prisijungtose eilutėse, tada VPN demono sesijos žurnale. Pirmoji riba, kuri nieko nefiksuoja, yra vieta kitam pakeitimui. Kai OpenVPN pradeda lyginti partnerio parinktis, vertinkite tas žinutes pagal tos implementacijos taisykles. Įspėjimas apie link-mtu nenuoseklumą nėra automatiškai mirtinas, link-mtu prispaudimas prie 1500 neįrodo, kad suskaidymas sustojo, o šifro derybos priklauso vidinei OpenVPN konfigūracijai, o ne maršrutizatoriaus peradresavimui.

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

Tie zondai apima backend lizdą ir apvalkalo žurnalą, kas atskiria atmestą backend nuo atmesto rankos paspaudimo. Vykdykite juos, kol vyksta vienas bandymas, o ne po jo. Vieno bandymo laiko žymos daro palyginimą patikimą.

Dvi tapatybės, dvi gedimų eilės

Išorinis sertifikatas priklauso apvalkalui, o vidinė tapatybė priklauso OpenVPN, ir jie gali ateiti iš skirtingų institucijų. Bet kurios iš dviejų patikrų išjungimas, kad kelias atrodytų sveikas, maino tikrą apsaugą į kosmetinį rezultatą. Išsaugokite abi patikras ir derinkite jas iš eilės, nes žinučių seka įvardija sluoksnį: apvalkalo sertifikato problema pasirodo prieš derantis dėl bet kurios VPN parinkties, o vidinės tapatybės gedimas pasirodo tik po to, kai srautas nustatytas.

stunnel vadovas tiksliai apibrėžia accept, connect ir kliento režimą, ir tie skyriai atsako į lizdo klausimą greičiau nei spėlionės. Kai vis dar negalite pasakyti, kuris sluoksnis atsakė, perskaitykite sertifikatą, kurį pateikia viešasis prievadas, žemiau esančia komanda. Apvalkalo sertifikatas išvestyje reiškia, kad peradresavimas pasiekė apvalkalą, o tyla ar protokolo klaida reiškia, kad nepasiekė. Šis vienas skirtumas sutaupo daugiau laiko nei bet kuri kita patikra čia.

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