Tor gati para VPN-së: renditja e saktë e portës së nisjes

Vëzhgimi i një procesi tor dhe më pas nisja e VPN-së është mënyra më e zakonshme për ta ndërtuar gabimisht këtë stivë. Daemoni shfaqet shumë përpara se të mund të mbajë një rrjedhë klienti, dhe një pritje fikse është një hamendje e veshur si varësi. Porta duhet të jetë gjendja që komponenti tjetër ka vërtet nevojë. Kaloni nëpër katër hapat më poshtë me radhë dhe trajtojeni secilin si kusht të veçantë, jo si vonesë për t'u rregulluar.

Hapi 1: zgjidhni transportin që keni vërtet

Filloni me protokollin, sepse pjesa tjetër e dizajnit varet prej tij. Ndërfaqja SOCKS e Tor nuk zbaton UDP ASSOCIATE, prandaj çdo gjë që transportohet përmes saj duhet të jetë rrjedhë TCP. Një profil OpenVPN që përdor UDP nuk do të funksionojë në këtë rrugë, pavarësisht se si është shkruar mbikëqyrësi. Kalojeni profilin në TCP dhe konfirmoni se pala e largët e pranon, përpara se të prekni logjikën e nisjes.

Më pas konfirmoni se klienti juaj mund të arrijë fare një proxy SOCKS. OpenVPN 2.6 dokumenton një opsion socks-proxy për profilet TCP, dhe klientë të ndryshëm ofrojnë mbështetje të ndryshme për proxy. Një nisës që e injoron në heshtje opsionin e proxy do të lidhet drejtpërdrejt dhe do të duket se funksionon, gjë që është më e keqe se dështimi.

Shkruajeni transportin e zgjedhur në runbook, sepse çdo kontroll i mëvonshëm varet prej tij.

Hapi 2: lexoni fazën bootstrap, jo listën e proceseve

Protokolli i kontrollit të Tor i përgjigjet GETINFO status/bootstrap-phase me gjendjen më të re të bootstrap, përfshirë përqindjen e përparimit dhe një etiketë përmbledhëse. Ai përgjigje është i dobishëm pikërisht sepse një kontrollues mund të lidhet pasi daemoni të ketë përfunduar tashmë bootstrap. Një mbikëqyrës që dëgjon vetëm ngjarje do të humbasë rastin kur Tor ishte gati përpara se të fillonte mbikëqyrësi.

Vërtetoni si duhet lidhjen e kontrollit. Porta e kontrollit është një ndërfaqe administrative, dhe kushdo që mund të flasë me të mund të rikonfigurojë daemonin. Mbajeni në localhost, mbajeni aktivizuar vërtetimin me cookie ose fjalëkalim, dhe mos hiqni asnjërën prej tyre për ta bërë më të thjeshtë një skript nisjeje.

Lexojeni fazën një herë në nisje, më pas abonohuni në ngjarjet e përparimit për pamjen e drejtpërdrejtë.

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

Një përgjigje me përparim 100 dhe etiketën done do të thotë që daemoni ka përfunduar nisjen e vet. Nuk do të thotë ende se ekziston një qark i përdorshëm drejt destinacionit tuaj.

Hapi 3: prisni një ngjarje të qarkut të klientit

Protokolli i ngjarjeve të Tor përcakton CIRCUIT_ESTABLISHED, i cili raporton se klienti ka një qark që mund ta përdorë. Ky është sinjali i gatishmërisë që dëshiron një portë transporti, sepse është më afër aftësisë që ju nevojitet sesa një përqindje. Abonohuni në ngjarje dhe regjistroni tranzicionin, që regjistri të tregojë kur transporti u bë i përdorshëm dhe jo kur u shfaq procesi.

Trajtojeni ngjarjen si leje për të provuar, jo si garanci për një destinacion të caktuar. Një politikë daljeje mund të refuzojë akoma palën e largët, dhe shtrëngimi i duarve i vetë VPN-së mund të dështojë akoma për arsye që nuk kanë asnjë lidhje me Tor.

Mbajini dy kushtet të ndara në kod. Një vlerë e vetme boolean e quajtur ready do t'i bashkojë ato dhe do ta bëjë të palexueshëm incidentin tjetër.

Hapi 4: lidheni VPN-në me shtrëngimin e duarve të vet

VPN-ja ka kushtin e vet të gatishmërisë, dhe vetëm ai dëshmon se tuneli u ngrit. Prisni që klienti të raportojë një gjendje të lidhur me një adresë të caktuar, më pas kontrolloni se kërkesa për proxy mbeti në fuqi. Cikli i ripërpjekjeve që e hedh poshtë opsionin socks-proxy pas një dështimi do të lidhet drejtpërdrejt dhe do ta mposhtë në heshtje të gjithë dizajnin.

Vendosni çfarë ndodh kur pala e largët është e paarritshme, përpara se t'ju duhet ta dini. Një ripërpjekje e kufizuar me një dështim të dukshëm është më e lehtë për t'u operuar sesa një cikli i pafund, dhe i jep sistemit të monitorimit diçka për të alarmuar. I njëjti vendim vlen për transportin: nëse Tor riniset, VPN-ja duhet të çmontohet dhe të lidhet përsëri, jo të lihet të punojë në një qark të vdekur.

Së fundi, mbajeni politikën e vetë aplikacionit në fuqi ndërsa VPN-ja është poshtë. Një mbikëqyrës që pret saktë nuk bën asgjë për të penguar një proces të palidhur të dërgojë trafik drejtpërdrejt.

Kontrolloni katër tranzicionet që duhet t'i mbijetoni

Katër raste mbulojnë dizajnin: një nisje e ftohtë ku Tor ngrihet i pari, një mbikëqyrës që lidhet me një Tor tashmë të gatshëm, një palë VPN e padisponueshme, dhe humbja e transportit ndërsa tuneli është lart. Secili ka një tranzicion të ndryshëm të pritur, dhe secili prodhon një rresht regjistri të ndryshëm nëse porta është shkruar saktë.

Ekzekutojini me qëllim, një nga një, dhe lexoni ndryshimet e gjendjes, jo listën e proceseve.

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

Kur transporti bie, VPN-ja duhet ta ndjekë poshtë brenda një intervali ripërpjekjeje, në vend që të mbetet me një tunel të vjetruar. Kur Tor kthehet, porta duhet të rihapet vetëm pas ngjarjes së qarkut, jo pas nisjes së procesit. Regjistroni cili kusht mungonte në çdo dështim, dhe personi tjetër në detyrë nuk do të duhet ta rindërtojë renditjen nga vulat kohore.