OpenVPN portissa 443 yhä estetty? Katso mitä verkko tarkastelee

Tunneli yhdistää kotilinjasta ja pysähtyy hotellin tai toimiston verkossa, eikä palvelimen siirtäminen porttiin 443 muuttanut mitään. Tulos on tarpeeksi yleinen, että sillä on muoto: portti oli helppo osa, ja loput päätöksestä kuuluu kaikelle, mikä istuu asiakkaan ja palvelimen välissä. Kaksi kysymystä ratkaisee useimmat tapaukset, eikä kumpikaan niistä koske salauksia. Hyväksyykö verkko TLS-kättelyn tuohon osoitteeseen, ja pitääkö asiakas reitin omaan kääreeseensä, kun tunneli on ylhäällä?

Kättely paljastaa enemmän kuin numero

Natiivi VPN-kuuntelija TCP 443:ssa puhuu omaa protokollaansa ensimmäisestä paketista lähtien. ClientHellossa on versiokenttä, satunnainen arvo ja laajennusluettelo, ja laite, joka lukee pari sataa tavua, näkee eron salaamatta mitään. Porttinumerot on halpaa tyydyttää, ja protokollan muoto on se, mitä suodatin oikeasti tarkistaa. Säännöt kirjoitetaan yleensä myös protokollakohtaisesti, joten TLS:ää tarkasteleva käytäntö ei kerro UDP:stä mitään.

Läpinäkyvä välityspalvelin, joka vaatii kelvollisen TLS-istunnon, pudottaa yhteyden asennuksen aikana, usein sen jälkeen kun TCP-kättely on valmistunut. Tämä yksityiskohta on tärkeä myöhemmin, koska se tarkoittaa, että asiakkaan loki pysähtyy, kun socket on muodostettu.

Virran kääriminen luo kaksi vikakohtaa

TLS-kääre, kuten stunnel, palauttaa odotetun muodon: asiakas yhdistää paikalliseen kuuntelijaan, kääre avaa oikean TLS-istunnon palvelimeen portissa 443, ja palvelimen toinen kääre välittää salauksen puretut tavut VPN-demonille. Ulompi istunto näyttää nyt kaikelta muulta HTTPS-yhteydeltä. Palvelimen VPN-demonin pitäisi kuunnella vain loopbackissa, koska mikään kääreen ulkopuolella ei tarvitse tavoittaa sitä.

Kolmen erillisen asian on sovittava yhteen tätä rakennetta varten. Asiakasprofiili osoittaa paikalliseen kuuntelijaan, palvelimen varmenne vastaa nimeä, jonka asiakas vahvistaa, ja palvelimen puolen välitys kohdistuu porttiin, jota demoni todella käyttää. Erehdy yhdessäkään niistä, ja yhteys kuolee ennen kuin VPN-kerros saavutetaan. Silloin varmenteen poikkeama näkyy kääreen virheenä eikä VPN-virheenä, ja siksi molemmat lokit kannattaa lukea rinnakkain.

Reitti kääreeseen on ansa

Kun tunneli nousee, oletusreitti osoittaa siihen, ja ulompi TLS-istunto tarvitsee polun, joka ei mene siihen tunneliin, jota se kuljettaa. Tavallinen VPN-asiakas suojaa osoitteen, jota se soittaa; kääritty asiakas soittaa omaan loopbackiinsa, joten kääreen kohdeosoite on näkymätön sille suojalle.

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

Tarkat osoitteet täytät itse, ja reitin on oltava olemassa yhteyden koko eliniän, ei vain käynnistyksessä. Pieni kääreskripti, joka lisää reitin ennen asiakasta ja poistaa sen jälkeen, on luotettavampi kuin muistettu komento.

Androidissa tuon poikkeuksen vastine on sovelluskohtainen asetus: jätä kääresovellus tunnelin ulkopuolelle, jotta sen oma liikenne lähtee matkapuhelinliittymän kautta. Ilman poikkeusta kääre ohjataan tunneliin, jota se yrittää rakentaa, ja uudelleenyhdistämisen silmukka näyttää palvelimen ongelmalta.

Lue ajoitus ennen kuin muutat mitään

Istunto, joka kuolee aina saman aikavälin jälkeen, on käytännön allekirjoitus eikä salauksellinen vika, ja pitkäikäiset virtausrajat tuottavat juuri sellaisen kuvion. Yhteys, joka nollataan heti kättelyn jälkeen, viittaa välityspalvelimeen, jolle varmenneketju ei kelvannut.

Vertaa tavallisen HTTPS-sivuston varmenteen myöntäjää molemmista verkoista. Jos myöntäjä on rajoitetussa verkossa eri, jokin päättää TLS:n keskellä, eikä mikään kääre selviä siitä sieppauksesta muuttumattomana. Sama vertailu kertoo, kohdistuuko esto palvelimesi nimeen vai jokaiseen TLS-istuntoon tuossa osoitteessa.

Kirjoita havaittu käyttäytyminen muistiin: kuinka kauan istunto kesti, avautuiko socket, kirjasiko kääre kättelyn. Jokainen niistä kaventaa seuraavaa testiä.

Testaa yhtä muuttujaa kerrallaan

Tarkista ensin UDP, koska jotkin verkot pudottavat sen kokonaan, eikä UDP-vika kerro 443:sta mitään. Kokeile sitten TCP 443:ta ilman käärettä, sitten käärettä portissa 443. Lue asiakkaan loki jokaisessa vaiheessa ja pysähdy heti, kun käyttäytyminen muuttuu.

Muuta yhtä osaa kokeilua kohden. Uusi portti, uusi kääre ja uusi salaus samassa ajossa jättävät sinut sanomatta, mikä kolmesta merkitsi.