Tor მზად VPN-მდე: გაშვების ჭიშკრის სწორი რიგი

tor პროცესის თვალყურის დევნება და შემდეგ VPN-ის გაშვება ამ სტეკის არასწორად აწყობის ყველაზე გავრცელებული გზაა. დემონი ჩნდება გაცილებით ადრე, ვიდრე შეუძლია კლიენტის ნაკადის ტარება, ხოლო ფიქსირებული ლოდინი დამოკიდებულების ნიღაბში გამოწყობილი ვარაუდია. ჭიშკარი უნდა იყოს ის მდგომარეობა, რომელიც შემდეგ კომპონენტს ნამდვილად სჭირდება. გაიარეთ ქვემოთ მოცემული ოთხი ნაბიჯი თანმიმდევრობით და თითოეული განიხილეთ როგორც ცალკე პირობა და არა როგორც დასარეგულირებელი დაყოვნება.

ნაბიჯი 1: აირჩიეთ ის ტრანსპორტი, რომელიც ნამდვილად გაქვთ

დაიწყეთ პროტოკოლით, რადგან დიზაინის დარჩენილი ნაწილი მასზეა დამოკიდებული. Tor-ის SOCKS ინტერფეისი არ ახორციელებს UDP ASSOCIATE-ს, ამიტომ ყველაფერი, რაც მის გავლით გადაიცემა, TCP ნაკადი უნდა იყოს. OpenVPN-ის პროფილი, რომელიც UDP-ს იყენებს, ამ გზით არ იმუშავებს, როგორც არ უნდა იყოს დაიწერა ზედამხედველი. გადართეთ პროფილი TCP-ზე და დაადასტურეთ, რომ დისტანციური თანამოწყობილი მას იღებს, სანამ გაშვების ლოგიკას შეეხებით.

შემდეგ დაადასტურეთ, რომ თქვენს კლიენტს საერთოდ შეუძლია SOCKS პროქსის მიღწევა. OpenVPN 2.6 აღწერს socks-proxy პარამეტრს TCP პროფილებისთვის და სხვადასხვა კლიენტი სხვადასხვა პროქსის მხარდაჭერას გვთავაზობს. გამშვები, რომელიც ჩუმად უგულებელყოფს პროქსის პარამეტრს, პირდაპირ დაუკავშირდება და იმუშავებს როგორც ჩანს, რაც მარცხზე უარესია.

ჩაწერეთ არჩეული ტრანსპორტი runbook-ში, რადგან ყოველი შემდგომი შემოწმება მასზეა დამოკიდებული.

ნაბიჯი 2: წაიკითხეთ bootstrap ფაზა და არა პროცესების სია

Tor-ის მართვის პროტოკოლი GETINFO status/bootstrap-phase-ზე პასუხობს უახლესი bootstrap მდგომარეობით, პროგრესის პროცენტისა და შემაჯამებელი ტეგის ჩათვლით. ეს პასუხი სწორედ იმიტომ არის სასარგებლო, რომ კონტროლერს შეუძლია დაუკავშირდეს მას შემდეგ, რაც დემონმა bootstrap უკვე დაასრულა. ზედამხედველი, რომელიც მხოლოდ მოვლენებს უსმენს, გამოტოვებს იმ შემთხვევას, როცა Tor მზად იყო ზედამხედველის გაშვებამდე.

სწორად გაავტორიზეთ მართვის კავშირი. მართვის პორტი ადმინისტრაციული ინტერფეისია და ნებისმიერს, ვისაც შეუძლია მასთან საუბარი, შეუძლია დემონის ხელახლა კონფიგურაცია. შეინახეთ ის localhost-ზე, დატოვეთ ჩართული cookie-ით ან პაროლით ავტორიზაცია და არ წაშალოთ არც ერთი მათგანი სასტარტო სკრიპტის გასამარტივებლად.

წაიკითხეთ ფაზა ერთხელ გაშვებისას, შემდეგ გამოიწერეთ პროგრესის მოვლენები ცოცხალი ხედისთვის.

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

პასუხი 100 პროგრესით და done ტეგით ნიშნავს, რომ დემონმა საკუთარი გაშვება დაასრულა. ეს ჯერ არ ნიშნავს, რომ თქვენი დანიშნულებისკენ გამოსაყენებელი წრედი არსებობს.

ნაბიჯი 3: დაელოდეთ კლიენტის წრედის მოვლენას

Tor-ის მოვლენათა პროტოკოლი განსაზღვრავს CIRCUIT_ESTABLISHED-ს, რომელიც აცხადებს, რომ კლიენტს აქვს გამოსაყენებელი წრედი. ეს არის ის მზაობის სიგნალი, რომელსაც გადამზიდის ჭიშკარი ითხოვს, რადგან უფრო ახლოს არის სასურველ შესაძლებლობასთან, ვიდრე პროცენტი. გამოიწერეთ მოვლენა და დააფიქსირეთ გადასვლა, რომ ჟურნალმა აჩვენოს, როდის გახდა გადამზიდი გამოსაყენებელი და არა როდის გამოჩნდა პროცესი.

განიხილეთ მოვლენა როგორც ცდის ნებართვა და არა როგორც გარანტია რომელიმე კონკრეტული დანიშნულების შესახებ. გასვლის პოლიტიკას მაინც შეუძლია უარი თქვას დისტანციურ თანამოწყობილზე, ხოლო VPN-ის საკუთარ ხელის ჩამორთმევას მაინც შეუძლია ჩავარდეს Tor-თან არაფერ შუაში მყოფი მიზეზებით.

შეინახეთ ორი პირობა ცალ-ცალკე კოდში. ერთი ლოგიკური მნიშვნელობა სახელად ready გააერთიანებს მათ და შემდეგ ინციდენტს წაუკითხავს გახდის.

ნაბიჯი 4: დაუკავშირეთ VPN მის საკუთარ ხელის ჩამორთმევას

VPN-ს აქვს საკუთარი მზაობის პირობა და მხოლოდ ის ამტკიცებს, რომ გვირაბი ამოვიდა. დაელოდეთ, სანამ კლიენტი შეატყობინებს დაკავშირებულ მდგომარეობას მინიჭებული მისამართით, შემდეგ შეამოწმეთ, რომ პროქსის მოთხოვნა ძალაში დარჩა. ხელახალი ცდის ციკლი, რომელიც ერთი მარცხის შემდეგ ტოვებს socks-proxy პარამეტრს, პირდაპირ დაუკავშირდება და ჩუმად დაამარცხებს მთელ დიზაინს.

გადაწყვიტეთ, რა მოხდება, როცა თანამოწყობილი მიუწვდომელია, სანამ ამის ცოდნა დაგჭირდებათ. შეზღუდული ხელახალი ცდა ხილული მარცხით უფრო ადვილი საოპერაციოდაა, ვიდრე უსასრულო ციკლი, და მონიტორინგის სისტემას აძლევს რაღაცას გაფრთხილებისთვის. იგივე გადაწყვეტილება ეხება გადამზიდსაც: თუ Tor გადაიტვირთება, VPN უნდა დაიშალოს და ხელახლა გაიაროს ჭიშკარზე და არ დარჩეს მკვდარ წრედზე მომუშავე.

და ბოლოს, შეინახეთ აპლიკაციის საკუთარი პოლიტიკა ძალაში, სანამ VPN გამორთულია. სწორად მოლოდინი ზედამხედველი არაფერს აკეთებს, რომ ხელი შეუშალოს დაუკავშირებელ პროცესს ტრაფიკის პირდაპირ გაგზავნაში.

შეამოწმეთ ოთხი გადასვლა, რომლებიც უნდა გადაიტანოთ

ოთხი შემთხვევა მოიცავს დიზაინს: ცივი გაშვება, როცა Tor პირველი ამოდის, ზედამხედველი, რომელიც უკვე მზა Tor-ს უერთდება, მიუწვდომელი VPN თანამოწყობილი და გადამზიდის დაკარგვა გვირაბის ამოსული ყოფნისას. თითოეულს განსხვავებული მოსალოდნელი გადასვლა აქვს და თითოეული განსხვავებულ ჟურნალის სტრიქონს წარმოქმნის, თუ ჭიშკარი სწორადაა დაწერილი.

გაუშვით ისინი განზრახ, სათითაოდ, და წაიკითხეთ მდგომარეობის ცვლილებები და არა პროცესების სია.

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

როცა გადამზიდი ვარდება, VPN უნდა მიჰყვეს მას ქვემოთ ერთი ხელახალი ცდის ინტერვალში და არ დარჩეს მოძველებულ გვირაბთან. როცა Tor ბრუნდება, ჭიშკარი მხოლოდ წრედის მოვლენის შემდეგ უნდა გაიხსნას და არა პროცესის გაშვების შემდეგ. ჩაწერეთ, რომელი პირობა აკლდა ყოველ მარცხს და შემდეგ მორიგეს არ მოუწევს თანმიმდევრობის აღდგენა დროის ნიშნებიდან.