OpenVPN 443 prievade vis dar blokuojamas? Pažiūrėkite, ką tikrina tinklas
443 prievadas keičia numerį, o ne protokolo formą. Jei kelias tikrina arba užbaigia TLS, kiti bandymai yra apvalkalas ir teisingas prieglobos maršrutas.
Tunelis jungiasi iš namų linijos ir sustoja viešbučio ar biuro tinkle, o serverio perkėlimas į 443 prievadą nieko nepakeitė. Šis rezultatas pakankamai dažnas, kad turėtų formą: prievadas buvo lengvoji dalis, o likusi sprendimo dalis priklauso viskam, kas sėdi tarp kliento ir serverio. Du klausimai išsprendžia daugumą atvejų, ir nė vienas jų ne apie šifrus. Ar tinklas priima TLS rankos paspaudimą į tą adresą, ir ar klientas išlaiko maršrutą į savo paties apvalkalą, kol tunelis pakeltas?
Rankos paspaudimas išduoda daugiau nei numeris
Vietinis VPN klausytojas TCP 443 kalba savo protokolu nuo pirmo paketo. ClientHello turi versijos lauką, atsitiktinę reikšmę ir plėtinių sąrašą, o įrenginys, perskaitęs kelis šimtus baitų, gali atskirti skirtumą nieko neiššifruodamas. Prievadų numerius patenkinti pigiai, o filtro iš tikrųjų tikrinama protokolo forma. Taisyklės paprastai rašomos ir pagal protokolą, todėl politika, tikrinanti TLS, nieko nesako apie UDP.
Skaidrus tarpinis serveris, reikalaujantis galiojančios TLS sesijos, nutraukia ryšį sąrankos metu, dažnai po to, kai TCP rankos paspaudimas baigiamas. Ši detalė vėliau svarbi, nes reiškia, kad kliento žurnalas sustoja po to, kai sukuriama jungtis.
Srauto apvyniojimas sukuria du gedimo taškus
TLS apvalkalas, pavyzdžiui stunnel, atkuria lauktą formą: klientas jungiasi prie vietinio klausytojo, apvalkalas atidaro tikrą TLS sesiją su serveriu 443 prievade, o antras apvalkalas serveryje perduoda iššifruotus baitus VPN tarnybai. Išorinė sesija dabar atrodo kaip bet koks kitas HTTPS ryšys. VPN tarnyba serveryje turėtų klausytis tik loopback sąsajoje, nes niekam už apvalkalo ribų nereikia jos pasiekti.
Šiai konstrukcijai turi sutapti trys atskiri dalykai. Kliento profilis nurodo vietinį klausytoją, serverio sertifikatas atitinka vardą, kurį klientas tikrina, o persiuntimas serverio pusėje taiko į prievadą, kurį tarnyba tikrai naudoja. Suklydę bent viename, ryšys žūva dar nepasiekęs VPN sluoksnio. Tada sertifikato neatitikimas pasirodo kaip apvalkalo klaida, o ne VPN klaida, ir todėl verta skaityti abu žurnalus greta.
Maršrutas iki apvalkalo yra spąstai
Kai tunelis pakyla, numatytasis maršrutas nukreipiamas į jį, o išorinei TLS sesijai reikia kelio, kuris neina į tunelį, kurį ji neša. Paprastas VPN klientas saugo adresą, į kurį skambina; apvalkaluotas klientas skambina į savo loopback, todėl apvalkalo paskirties adresas yra nematomas šiai apsaugai.
sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20
Tikslius adresus įrašote patys, o maršrutas turi egzistuoti visą ryšio gyvavimo laiką, ne tik paleidimo metu. Mažas apvalkalo scenarijus, kuris prideda maršrutą prieš klientą ir pašalina jį po to, patikimesnis už įsimintą komandą.
Android sistemoje tos išimties atitikmuo yra kiekvienos programos nustatymas: išskirkite apvalkalo programą iš tunelio, kad jos pačios srautas išeitų per mobilųjį ryšį. Neišskyrus apvalkalas nukreipiamas į tunelį, kurį bando pastatyti, o pakartotinio prisijungimo ciklas atrodo kaip serverio problema.
Prieš ką nors keisdami, perskaitykite laiką
Sesija, kuri visada miršta po to paties intervalo, yra politikos parašas, o ne kriptografinė klaida, ir ilgalaikiai srauto limitai sukuria būtent tokį modelį. Ryšys, atstatomas iškart po rankos paspaudimo, rodo tarpinį serverį, kuriam nepatiko sertifikatų grandinė.
Palyginkite įprastos HTTPS svetainės sertifikato išdavėją iš abiejų tinklų. Jei ribotame tinkle išdavėjas kitas, kažkas užbaigia TLS viduryje, ir joks apvalkalas to perėmimo nepakels nepakitęs. Tas pats palyginimas pasakys, ar blokavimas taikomas jūsų serverio vardui, ar kiekvienai TLS sesijai tame adrese.
Užsirašykite pastebėtą elgseną: kiek truko sesija, ar atsidarė jungtis, ar apvalkalas įrašė rankos paspaudimą. Kiekvienas iš jų susiaurina kitą bandymą.
Bandykite po vieną kintamąjį
Pirmiausia patikrinkite UDP, nes kai kurie tinklai jo visai atsisako, o UDP klaida nieko nesako apie 443. Tada išbandykite TCP 443 be apvalkalo, po to apvalkalą 443 prievade. Skaitykite kliento žurnalą kiekviename žingsnyje ir sustokite, kai tik elgsena pasikeičia.
Keiskite po vieną elementą per bandymą. Naujas prievadas, naujas apvalkalas ir naujas šifras tame pačiame paleidime neleis pasakyti, kuris iš trijų buvo svarbus.