დაშიფრულია თუ არა HTTP ZeroTier-ზე? ნახეთ, სად მთავრდება ოვერლეი

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

შემოწმება 1: იპოვეთ მისამართი, რომელსაც ბრაუზერი იძახებს

შეადარეთ URL იმას, რაც მანქანას ნამდვილად აქვს. ip -brief addr show ჩამოთვლის zt ინტერფეისს და ოვერლეის მისამართს, რომელიც ქსელის კონტროლერმა მიანიჭა; თუ URL იყენებს ამ მისამართს, ბრაუზერის სოკეტი ოვერლეიში შედის.

როცა სახელი სამაგიეროდ LAN მისამართზე იხსნება, შესაძლოა ოვერლეი საერთოდ არ მონაწილეობდეს, რაც არ უნდა მიანიშნოს კლიენტის სტატუსის ინდიკატორმა. ip route get 10.147.20.5 ბეჭდავს ინტერფეისს და წყაროს მისამართს, რომელსაც ბირთვი აირჩევდა, ამიტომ იქ zt ინტერფეისი ნიშნავს, რომ პაკეტი ოვერლეიში შედის, ხოლო თქვენი ფიზიკური NIC-ის სახელი ნიშნავს, რომ არ შედის. სახელები კიდევ ერთ ფენას ამატებს: ოვერლეის მისამართზე მიმთითებელი ჩანაწერი სხვაგვარად იქცევა, ვიდრე LAN მისამართზე მიმთითებელი, და ძებნის სუფიქსმა ან hosts ფაილის ჩანაწერმა შეიძლება ჩუმად გადაწყვიტოს, რომელი მიიღებთ.

შემოწმება 2: დარწმუნდით, რომ ორივე ბოლო თანასწორია და არა გაშიფვრის რელე

ZeroTier თანასწორთა შორის შიფრავს, და სადაც პირდაპირი გზა არ არსებობს, პაკეტები ფესვის გავლით გადაეცემა, რომელიც მათ ჯერ კიდევ დაშიფრულად აგზავნის. zerotier-cli peers თითოეული თანასწორის გზას DIRECT ან RELAY-ად აღნიშნავს დაყოვნების რიცხვით. გადაცემული გზა ორმხრივ მგზავრობას ხარჯავს და არა კონფიდენციალურობას.

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

შემოწმება 3: დააკვირდით, სად ხდება მოთხოვნა წაკითხვადი

ჰოსტზე, რომელიც გგონიათ გვერდს ემსახურება, გვერდის გადატვირთვისას დაიჭირეთ ოვერლეის ინტერფეისი: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. ამ გამოსავალში წაკითხვადი მოთხოვნის ხაზი ამტკიცებს, რომ ტრაფიკი ამ ჰოსტამდე გაშიფრული მოვიდა და ეს არის ის საზღვარი, რომელსაც ეძებთ.

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

loopback-ის დაჭერა მაშინაც მნიშვნელოვანია, როცა წინ უკუპროქსი დგას, რადგან HTTPS-ის მიმღები და HTTP-ის გადამცემი პროქსი საზღვარს საკუთარ ბექენდზე გადაიტანს.

შემოწმება 4: დაითვალეთ ყოველი გადასვლა როუტერის ან ხიდის უკან

ოვერლეისა და LAN-ს შორის მარშრუტიზაციისთვის კონფიგურირებული წევრი ჩვეულებრივი დიზაინია და ის ადგილი, სადაც ამ დაშვებათა უმეტესობა იმტვრევა. ოვერლეი იცავს ბრაუზერიდან როუტერამდე მონაკვეთს და მის შემდეგ არაფერს. ხიდი იგივე ამბავს სხვა მექანიზმით ჰყვება: ოვერლეი და ფიზიკური სეგმენტი ერთ ტრანსლაციის დომენად იქცევა, ამიტომ ხიდით დაკავშირებული ლეპტოპიდან მოსული მოთხოვნა ჩვეულებრივ Ethernet-ს კვეთს, მიუხედავად იმისა, რომ ეს ლეპტოპი ZeroTier-ის ქსელში ზის.

თვალყური ადევნეთ და ნუ ივარაუდებთ. traceroute კლიენტიდან სერვისის მისამართამდე და მარშრუტიზაციის ცხრილი კარიბჭის წევრზე აჩვენებს, ბოლო გადასვლა zt-ია თუ eth.

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

შემოწმება 5: გადაწყვიტეთ, რა უნდა გააკეთოს აპლიკაციამ ჯერ კიდევ

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

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

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

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