VPNdan oldin Tor tayyor: ishga tushirish darvozasini to'g'ri tartiblang

tor jarayonini kuzatib, keyin VPNni ishga tushirish bu stekni noto'g'ri qurishning eng keng tarqalgan usulidir. Deymon mijoz oqimini tashiy oladigan bo'lishidan ancha oldin paydo bo'ladi, qat'iy kutish esa bog'liqlik libosini kiygan taxmindir. Darvoza keyingi komponentga haqiqatan kerak bo'lgan holat bo'lishi kerak. Quyidagi to'rt qadamni tartib bilan bosib o'ting va har birini sozlanadigan kechikish emas, alohida shart deb qabul qiling.

1-qadam: haqiqatan mavjud transportni tanlang

Protokoldan boshlang, chunki dizaynning qolgan qismi unga bog'liq. Torning SOCKS interfeysi UDP ASSOCIATEni amalga oshirmaydi, shuning uchun u orqali uzatiladigan har qanday narsa TCP oqimi bo'lishi kerak. UDP ishlatadigan OpenVPN profili nazoratchi qanday yozilganidan qat'i nazar bu yo'ldan ishlamaydi. Profilni TCPga o'tkazing va ishga tushirish mantiqiga tegishdan oldin uzoq hamkor buni qabul qilishiga ishonch hosil qiling.

Keyin mijozingiz umuman SOCKS proksiga yeta olishini tekshiring. OpenVPN 2.6 TCP profillari uchun socks-proxy parametrini hujjatlashtiradi va turli mijozlar turli proksi qo'llab-quvvatlaydi. Proksi parametrini indamay e'tiborsiz qoldiradigan ishga tushirgich to'g'ridan-to'g'ri ulanadi va ishlayotgandek ko'rinadi, bu esa muvaffaqiyatsizlikdan ham yomonroq.

Tanlangan transportni runbookka yozing, chunki keyingi har bir tekshiruv unga bog'liq.

2-qadam: jarayonlar ro'yxatini emas, bootstrap bosqichini o'qing

Torning boshqaruv protokoli GETINFO status/bootstrap-phase so'roviga eng so'nggi bootstrap holati bilan javob beradi, jumladan progress foizi va xulosa tegi. Bu javob aynan shu sababli foydali: kontroller deymon bootstrapni allaqachon tugatgandan keyin ulanadi. Faqat hodisalarni tinglaydigan nazoratchi Tor nazoratchi boshlanishidan oldin tayyor bo'lgan holatni o'tkazib yuboradi.

Boshqaruv ulanishini to'g'ri autentifikatsiya qiling. Boshqaruv porti ma'muriy interfeys va u bilan gaplasha oladigan har kim deymonni qayta sozlashi mumkin. Uni localhostda saqlang, cookie yoki parol autentifikatsiyasini yoqilgan holda qoldiring va ishga tushirish skriptini soddalashtirish uchun ikkalasidan birini ham olib tashlamang.

Bosqichni ishga tushirishda bir marta o'qing, keyin jonli ko'rinish uchun progress hodisalariga obuna bo'ling.

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

Progressi 100 va done tegi bo'lgan javob deymon o'z ishga tushishini tugatganini bildiradi. Bu hali sizning manzilingizga ishlatsa bo'ladigan zanjir borligini bildirmaydi.

3-qadam: mijoz zanjiri hodisasini kuting

Torning hodisalar protokoli CIRCUIT_ESTABLISHEDni belgilaydi, u mijozda ishlatsa bo'ladigan zanjir borligini xabar qiladi. Bu tashuvchi darvozasi xohlaydigan tayyorlik signali, chunki u foizdan ko'ra kerakli qobiliyatga yaqinroq. Hodisaga obuna bo'ling va o'tishni qayd eting, shunda jurnal jarayon qachon paydo bo'lganini emas, tashuvchi qachon foydali bo'lganini ko'rsatadi.

Hodisani sinab ko'rish uchun ruxsat deb biling, aniq manzil haqida kafolat deb emas. Chiqish siyosati uzoq hamkorni baribir rad etishi mumkin, VPNning o'z qo'l berishi ham Tor bilan hech qanday aloqasi bo'lmagan sabablarga ko'ra baribir muvaffaqiyatsiz bo'lishi mumkin.

Kodda ikkala shartni alohida saqlang. ready nomli bitta mantiqiy qiymat ularni birlashtiradi va keyingi hodisani o'qib bo'lmaydigan qiladi.

4-qadam: VPNni o'z qo'l berishiga darvozalang

VPNning o'z tayyorlik sharti bor va tunnel ko'tarilganini faqat shu tasdiqlaydi. Mijoz belgilangan manzil bilan ulangan holat haqida xabar berguncha kuting, keyin proksi talabi kuchda qolganini tekshiring. Bitta muvaffaqiyatsizlikdan keyin socks-proxy parametridan voz kechadigan qayta urinish sikli to'g'ridan-to'g'ri ulanadi va butun dizaynni indamay yengadi.

Hamkor yetib bo'lmaydigan bo'lganda nima bo'lishini bilish kerak bo'lishidan oldin hal qiling. Ko'rinadigan muvaffaqiyatsizlik bilan cheklangan qayta urinish cheksiz siklga qaraganda osonroq boshqariladi va kuzatuv tizimiga ogohlantirish uchun narsa beradi. Xuddi shu qaror tashuvchiga ham tegishli: agar Tor qayta ishga tushsa, VPN o'lik zanjirda ishlashga qoldirilmasdan, demontaj qilinishi va qayta darvozalanishi kerak.

Nihoyat, VPN o'chirilgan vaqtda ilovaning o'z siyosatini kuchda saqlang. To'g'ri kutayotgan nazoratchi aloqasiz jarayonning to'g'ridan-to'g'ri trafik yuborishiga yo'l qo'ymaslik uchun hech narsa qilmaydi.

Siz o'tishingiz kerak bo'lgan to'rt o'tishni tekshiring

To'rt holat dizaynni qamrab oladi: Tor birinchi ko'tariladigan sovuq ishga tushish, allaqachon tayyor Tor'ga ulanadigan nazoratchi, mavjud bo'lmagan VPN hamkori va tunnel ko'tarilgan paytda tashuvchining yo'qolishi. Har birining kutilayotgan o'tishi boshqacha va darvoza to'g'ri yozilgan bo'lsa, har biri boshqa jurnal satrini hosil qiladi.

Ularni ataylab, birma-bir ishga tushiring va jarayonlar ro'yxati o'rniga holat o'zgarishlarini o'qing.

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

Tashuvchi yiqilganda, VPN eski tunnel bilan osilib qolmasdan, bitta qayta urinish oralig'ida u bilan birga pastga tushishi kerak. Tor qaytganda, darvoza jarayon boshlanganidan keyin emas, faqat zanjir hodisasidan keyin qayta ochilishi kerak. Har bir muvaffaqiyatsizlikda qaysi shart yetishmaganini qayd eting, keyingi navbatchi tartibni vaqt belgilaridan qayta qurishga majbur bo'lmaydi.