OpenVPN stunnelin takana: välitä kääre, älä porttia 1194

Aseta TLS-kääre OpenVPN eteen, niin käyttöönotto saa toisen kuuntelijan, joista vain toisen pitäisi koskaan näyttää internetiin. Kun tunneli toimii samalta koneelta ja epäonnistuu ulkopuolelta, välitys osoittaa yleensä kahdesta väärään. Sen, mikä täytyy sovittaa kohdalleen, on ketju: julkinen sääntö saavuttaa kääreen, ja kääreen oma taustayhteys saavuttaa varsinaisen VPN-pistokkeen. Neljä hyppyä kantaa tätä ketjua, ja mikä tahansa niistä voi päättää tutkinnan ennenaikaisesti.

Kaksi pistoketta, kaksi omistajaa, yksi niistä julkinen

Kääre päättää TLS-yhteyden ulompaa yhteyttä varten ja välittää puretun tavuvirran tavalliselle OpenVPN TCP -kuuntelijalle. Ne ovat erilliset pistokkeet erillisillä asetustiedostoilla, joten toisen muokkaaminen jättää toisen koskemattomaksi ja yhä näennäisesti terveeksi. Se tarkoittaa myös, että kaksi voivat ajautua erilleen, aina kun toista muutetaan ilman toista.

Työskentely koneelta itseltään todistaa siksi julkisesta polusta hyvin vähän. Suora yhteys natiiviporttiin ohittaa kääreen, yhteys kääreelle sen LAN-osoitteessa ohittaa käännöksen, ja vain täydellinen asiakaspuolen järjestely harjoittaa sitä, mitä ulkopuolinen käyttäjä tekee. Myös nimet on luettava huolella, koska localhost tarkoittaa isäntää, jolla juuri se komponentti ajetaan, eikä isäntää, jolla satut kirjoittamaan. Pidä tämä ero muistiinpanoissasi, koska testi, joka kirjattiin ilman kattamaansa hyppyä, kutsuu vertailemaan kahta eri asiaa.

Mihin välitys todella laskeutuu

Ketjua on helpompi pitää neljänä hyppynä kuin kolmena porttinumerona, koska sama numero voi tarkoittaa eri asiaa kummassakin päässä. Lue taulukkoa rivi riviltä: jokainen rivi on yksi pistoke, jonka täytyy hyväksyä yhteys ja sitten avata seuraava. Kun rivi osoittaa väärälle vastapuolelle, viimeisen sarakkeen oire on se, mitä käyttäjä raportoi.

Sääntö, joka kohdistuu natiiviporttiin kääreen sijaan, ohittaa TLS-päätyksen kokonaan, mikä on tämän virheen yleisin muoto: asiakas avaa kättelyn kuuntelijan kanssa, joka odottaa OpenVPN-kehystystä, joten yhteys voi avautua ja sitten juuttua. Varmista käännetty portti kääreen asetustiedostosta muistin sijaan, koska seuraava henkilö, joka muokkaa sitä tiedostoa, on ehkä valinnut eri numeron. Kaksi alla olevaa komentoa näyttävät kysymyksen molemmat puolet kerralla.

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

Sidontaosoite, joka kieltäytyy sinusta

Kohtaan 127.0.0.1 sidottu accept-rivi vastaa vain isäntään itseensä, joten LAN-osoitteeseen saapuva välitys ei voi yhdistää ja asiakas näkee hylkäyksen, joka kuulostaa pakettisuodattimen ongelmalta. Katso pistoketta ennen palomuuriin koskemista, koska pistoke on halvempi vastaus. Joko sido kääre käyttöliittymään, johon välitys kohdistuu, tai pidä se loopbackissa ja tee niin, että välitys saavuttaa loopbackin jonkin todella toimivan kautta. Nämä ovat kaksi suunnittelua, ja kumpikin tarvitsee oman sääntönsä.

Niiden sekoittaminen on syy siihen, miksi toimiva kääre muuttuu ulkopuolelta tavoittamattomaksi, kun jokainen tiedosto näyttää oikealta. Alla oleva tarkistus on yksi komento, ja se vastaa kysymykseen, johon palomuurisääntöjen tarkastelu ei pysty. Jos tuloste näyttää loopback-osoitteen, kun välitys kohdistuu LAN-osoitteeseen, korjaus kuuluu accept-riville eikä pakettisuodattimeen.

ss -lntp '( sport = :8443 )'

Mitä paikallinen testi todella todisti

Menestys, joka on kirjattu ilman sen kattamaa hyppyä, ei ole todiste muista hypyistä. Kirjaa, mitä osoitetta testi käytti ja mikä prosessi vastasi. Toista sitten verkon ulkopuolelta etkä saman Wi-Fi-verkon puhelimesta, koska hiuspinnin käyttäytyminen vaihtelee reitittimien välillä ja yhteys, joka ei koskaan lähtenyt LANista, voi tyydyttää asiakkaan ilman, että välitys on lainkaan mukana. Vain se toinen yritys harjoittaa polkua, jonka muukalainen kulkee.

Kun yritys epäonnistuu, seuraa yhtä yhteyttä molemmista lokeista: kääreen hyväksytyt ja yhdistetyt rivit, sitten VPN-demoniin oma istuntoloki. Ensimmäinen raja, joka ei kirjaa mitään, on seuraavan muutoksen paikka. Kun OpenVPN alkaa vertailla vastapuolen asetuksia, arvioi ne viestit kyseisen toteutuksen säännöillä. Varoitus link-mtu:n epäjohdonmukaisuudesta ei ole automaattisesti kohtalokas, link-mtu:n kiinnittäminen 1500:een ei todista, että pirstoutuminen on loppunut, ja salauksen neuvottelu kuuluu OpenVPN:n sisäiseen asetukseen eikä reitittimen välitykseen.

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

Nämä koettimet kattavat taustapistokkeen ja kääreen lokin, mikä erottaa hylätyn taustan hylätystä kättelystä. Aja ne yhden yrityksen ollessa käynnissä, ei jälkeenpäin. Yhden yrityksen aikaleimat tekevät vertailusta luotettavan.

Kaksi identiteettiä, kaksi vikasijaa

Ulompi varmenne kuuluu kääreelle ja sisempi identiteetti OpenVPN:lle, ja ne voivat tulla eri viranomaisilta. Kummankaan tarkistuksen poistaminen käytöstä polun terveeltä näyttämiseksi vaihtaa todellisen suojan kosmeettiseen tulokseen. Pidä molemmat varmennukset ja selvitä ne järjestyksessä, koska viestien järjestys nimeää kerroksen: kääreen varmenteen ongelma ilmenee ennen kuin mitään VPN-asetusta neuvotellaan, kun taas sisemmän identiteetin vika ilmenee vasta, kun virta on muodostettu.

stunnel-käsikirja määrittelee tarkasti acceptin, connectin ja asiakastilan, ja ne osiot vastaavat pistokekysymykseen nopeammin kuin arvailu. Kun et vieläkään osaa sanoa, mikä kerros vastasi, lue varmenne, jonka julkinen portti esittää, alla olevalla komennolla. Kääreen varmenne tulosteessa tarkoittaa, että välitys saavutti kääreen, ja hiljaisuus tai protokollavirhe tarkoittaa, ettei saavuttanut. Tämä yksi ero säästää enemmän aikaa kuin mikään muu tarkistus tässä.

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