Tor valmiina ennen VPN:ää: käynnistysportin oikea järjestys

tor-prosessin tarkkaileminen ja sitten VPN:n käynnistäminen on yleisin tapa rakentaa tämä pino väärin. Taustaprosessi ilmestyy kauan ennen kuin se pystyy kuljettamaan asiakasvirtaa, ja kiinteä odotus on riippuvuudeksi puettu arvaus. Portin on oltava tila, jonka seuraava komponentti todella tarvitsee. Käy alla olevat neljä vaihetta järjestyksessä läpi ja käsittele jokaista erillisenä ehtona, älä säädettävänä viiveenä.

Vaihe 1: valitse siirto, joka sinulla todella on

Aloita protokollasta, koska muu suunnittelu riippuu siitä. Torin SOCKS-rajapinta ei toteuta UDP ASSOCIATE -komentoa, joten kaiken sen kautta kulkevan on oltava TCP-virtaa. UDP:tä käyttävä OpenVPN-profiili ei toimi tätä reittiä, riippumatta siitä, miten valvoja on kirjoitettu. Vaihda profiili TCP:hen ja varmista, että etäpää hyväksyy sen, ennen kuin kosket käynnistyslogiikkaan.

Varmista sitten, että asiakkaasi ylipäätään tavoittaa SOCKS-välityspalvelimen. OpenVPN 2.6 dokumentoi socks-proxy-valinnan TCP-profiileille, ja eri asiakkaat tarjoavat erilaisen välityspalvelintuen. Käynnistin, joka jättää välityspalvelinvalinnan hiljaa huomiotta, yhdistää suoraan ja näyttää toimivan, mikä on pahempaa kuin epäonnistuminen.

Kirjoita valittu siirto runbookiin, koska jokainen myöhempi tarkistus riippuu siitä.

Vaihe 2: lue bootstrap-vaihe, älä prosessilistaa

Torin ohjausprotokolla vastaa GETINFO status/bootstrap-phase -kyselyyn tuoreimmalla bootstrap-tilalla, mukaan lukien edistymisprosentti ja yhteenvetotunniste. Vastaus on hyödyllinen juuri siksi, että ohjain voi liittyä mukaan vasta, kun taustaprosessi on jo lopettanut bootstrap-vaiheen. Valvoja, joka kuuntelee vain tapahtumia, jättää huomaamatta tapauksen, jossa Tor oli valmis ennen valvojan käynnistymistä.

Todenna ohjausyhteys kunnolla. Ohjausportti on hallinnollinen rajapinta, ja kuka tahansa sen kanssa voi puhua voi määrittää taustaprosessin uudelleen. Pidä se localhostissa, pidä eväste- tai salasanatodennus käytössä äläkä poista kumpaakaan käynnistysskriptin yksinkertaistamiseksi.

Lue vaihe kerran käynnistyksessä ja tilaa sitten edistymistapahtumat live-näkymää varten.

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

Vastaus, jonka edistyminen on 100 ja tunniste done, tarkoittaa, että taustaprosessi on lopettanut oman käynnistymisensä. Se ei vielä tarkoita, että kohteeseesi olisi käyttökelpoinen piiri.

Vaihe 3: odota asiakkaan piiritapahtumaa

Torin tapahtumaprotokolla määrittelee CIRCUIT_ESTABLISHED-tapahtuman, joka kertoo, että asiakkaalla on piiri, jota se voi käyttää. Se on valmiussignaali, jota kantajaportti haluaa, koska se on lähempänä tarvitsemaasi kykyä kuin prosenttiluku. Tilaa tapahtuma ja kirjaa siirtymä, jotta loki näyttää, milloin kantajasta tuli käyttökelpoinen, ei milloin prosessi ilmestyi.

Käsittele tapahtumaa lupana yrittää, ei takeena mistään tietystä kohteesta. Poistumiskäytäntö voi silti hylätä etäpään, ja VPN:n oma kättely voi silti epäonnistua syistä, joilla ei ole mitään tekemistä Torin kanssa.

Pidä kaksi ehtoa erillään koodissa. Yksi ready-niminen totuusarvo sulauttaa ne ja tekee seuraavasta tapauksesta lukukelvottoman.

Vaihe 4: portita VPN sen omaan kättelyyn

VPN:llä on oma valmiusehtonsa, ja vain se todistaa, että tunneli nousi. Odota, että asiakas ilmoittaa yhdistetystä tilasta, johon on osoitettu osoite, ja tarkista sitten, että välityspalvelinvaatimus pysyi voimassa. Uudelleenyrityssilmukka, joka pudottaa socks-proxy-valinnan yhden epäonnistumisen jälkeen, yhdistää suoraan ja kukistaa hiljaa koko suunnitelman.

Päätä, mitä tapahtuu, kun etäpää ei ole tavoitettavissa, ennen kuin sinun täytyy tietää se. Rajattu uudelleenyritys näkyvällä epäonnistumisella on helpompi ylläpitää kuin loputon silmukka, ja se antaa valvontajärjestelmälle jotain hälytettävää. Sama päätös koskee kantajaa: jos Tor käynnistyy uudelleen, VPN on purettava ja portitettava uudelleen sen sijaan, että se jätetään kuolleelle piirille.

Pidä lopuksi sovelluksen oma käytäntö voimassa, kun VPN on alhaalla. Oikein odottava valvoja ei tee mitään estääkseen asiaankuulumatonta prosessia lähettämästä liikennettä suoraan.

Tarkista neljä siirtymää, jotka sinun on selvittävä

Neljä tapausta kattavat suunnittelun: kylmäkäynnistys, jossa Tor nousee ensin, valvoja, joka liittyy jo valmiiseen Toriin, tavoittamaton VPN-etäpää ja kantajan menetys tunnelin ollessa ylhäällä. Jokaisella on eri odotettu siirtymä, ja jokainen tuottaa eri lokirivin, jos portti on kirjoitettu oikein.

Aja ne tarkoituksella, yksi kerrallaan, ja lue tilamuutokset prosessilistan sijaan.

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

Kun kantaja putoaa, VPN:n pitäisi seurata sitä alas yhden uudelleenyritysvälin kuluessa sen sijaan, että se jäisi roikkumaan vanhentuneelle tunnelille. Kun Tor palaa, portin pitäisi avautua uudelleen vasta piiritapahtuman jälkeen, ei prosessin käynnistymisen jälkeen. Kirjaa, mikä ehto puuttui kussakin epäonnistumisessa, niin seuraavan päivystäjän ei tarvitse rakentaa järjestystä uudelleen aikaleimoista.