Tor klear foar de VPN: de startdoar goed oarderje
In draaiende tor-proses is gjin drager. Doarje de VPN op in dokumintearre kliïnt-klear-signaal, dan op syn eigen peer, en hâld de fallbacken apart.
In tor-proses besjen en dan de VPN starte is de meast foarkommende manier om dizze stapel ferkeard te bouwen. De daemon ferskynt lang foardat er in kliïntstream drage kin, en in fêste wachttiid is in gis ferklaaid as in ôfhinklikens. De doar moat de tastân wêze dy't de folgjende komponint echt nedich hat. Rin de fjouwer stappen hjirûnder yn folchoarder troch en behannelje elk as in aparte betingst ynstee fan in fertraging om by te stellen.
Stap 1: kies it transport dat jo eins hawwe
Begjin mei it protokol, want de rest fan it ûntwerp hinget dêrfan ôf. De SOCKS-ynterface fan Tor ymplemintearret gjin UDP ASSOCIATE, dus alles wat dêr oerhinne ferfierd wurdt moat in TCP-stream wêze. In OpenVPN-profyl dat UDP brûkt sil net oer dit paad wurkje, hoe't de tafersjochhâlder ek skreaun is. Skeakelje it profyl oer nei TCP en befêstigje dat de fiere peer it akseptearret foardat jo de startlogika oanreitsje.
Befêstigje dan dat jo kliïnt hielendal in SOCKS-proxy berikke kin. OpenVPN 2.6 dokumintearret in socks-proxy-opsje foar TCP-profylen, en ferskate kliïnten biede ferskate proxy-stipe. In starter dy't de proxy-opsje stilwei negearret, ferbynt direkt en liket te wurkjen, wat slimmer is as mislearje.
Skriuw it keazen transport yn it runbook, want elke lettere kontrôle hinget dêrfan ôf.
Stap 2: lês de bootstrap-faze, net de proseslist
It kontrôleprotokol fan Tor antwurdet op GETINFO status/bootstrap-phase mei de nijste bootstrap-tastân, ynklusyf in foarûtgongsprosint en in gearfettingslabel. Dat antwurd is krekt nuttich omdat in kontrôler har oanslute kin neidat de daemon it bootstrap al klear hat. In tafersjochhâlder dy't allinnich nei barrens harket, sil it gefal misse wêryn't Tor al klear wie foardat de tafersjochhâlder begûn.
Autentisearje de kontrôleferbining goed. In kontrôlepoarte is in bestjoerlike ynterface, en elkenien dy't der mei prate kin, kin de daemon opnij konfigurearje. Hâld it op localhost, hâld cookie- of wachtwurdautentikaasje oan, en ferwiderje gjin fan beide om in startskript ienfâldiger te meitsjen.
Lês de faze ien kear by it starten, en abonnearje dan op foarûtgongsbarrens foar de live werjefte.
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/torrcIn antwurd mei foarûtgong 100 en it label done betsjut dat de daemon syn eigen start klear hat. Dat betsjut noch net dat der in brûkbere sirkwy nei jo bestimming bestiet.
Stap 3: wachtsje op in kliïntsirkwy-barren
It barrenprotokol fan Tor definiearret CIRCUIT_ESTABLISHED, dat meldt dat de kliïnt in sirkwy hat dat er brûke kin. Dat is it klearrimensignaal dat in dragerdoar hawwe wol, want it is tichter by de kapasiteit dy't jo nedich hawwe as in persintaazje. Abonnearje op it barren en registrearje de oergong, sadat de log sjen lit wannear't de drager brûkber waard, net wannear't it proses ferskynde.
Behannelje it barren as tastimming om te besykjen, net as in garânsje oer in bepaalde bestimming. In útgongspolityk kin de fiere peer noch altiten wegerje, en de hânskuteling fan de VPN sels kin noch altiten mislearje om redenen dy't neat mei Tor te krijen hawwe.
Hâld de twa betingsten apart yn 'e koade. Ien booleaanske wearde mei de namme ready sil se gearfoegje en it folgjende foarfal ûnlêsber meitsje.
Stap 4: doarje de VPN op syn eigen hânskuteling
De VPN hat syn eigen klearrimbetingst, en dat is de iennige dy't bewiist dat de tunnel omheech kaam. Wachtsje oant de kliïnt in ferbûne tastân mei in tawiisde adres rapportearret, en kontrolearje dan dat de proxy-eask fan krêft bleau. In werhellingslus dy't de socks-proxy-opsje nei ien mislearring falle lit, ferbynt direkt en ferslacht stil it hiele ûntwerp.
Beslis wat der bart as de peer net berikber is foardat jo it witte moatte. In beheinde werhelling mei in sichtbere mislearring is makliker te betsjinjen as in einleaze lus, en it jout it monitorsysteem wat om op te alamearjen. Deselde beslissing jildt foar de drager: as Tor opnij start, moat de VPN ôfbrutsen en opnij doare wurde ynstee fan te bliuwen draaien op in dea sirkwy.
Hâld úteinlik it eigen belied fan 'e applikaasje yn stân wylst de VPN del is. In tafersjochhâlder dy't goed wachtet, docht neat om te foarkommen dat in net-relatearre proses ferkear direkt stjoert.
Kontrolearje de fjouwer oergongen dy't jo oerlibje moatte
Fjouwer gefallen dekke it ûntwerp: in kâlde start wêrby't Tor earst omheech komt, in tafersjochhâlder dy't him oanslút by in al klear Tor, in net beskikbere VPN-peer en ferlies fan 'e drager wylst de tunnel omheech is. Elk hat in oare ferwachte oergong, en elk produsearret in oare logrigel as de doar goed skreaun is.
Rin se mei opsetsin, ien foar ien, en lês de tastânsferoarings ynstee fan 'e proseslist.
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/ipAs de drager falt, moat de VPN him binnen ien werhellingsynterval folgje nei ûnderen ynstee fan te hingjen mei in ferâldere tunnel. As Tor weromkomt, moat de doar allinnich nei it sirkwy-barren wer iepengean, net nei de start fan it proses. Registrearje hokker betingst by elke mislearring ûntbruts, en de folgjende persoan op tsjinst hoecht de folchoarder net út tiidstimpels wer op te bouwen.