WireGuard-ის ხელის ჩამორთმევა მუშაობს, სერვისი — არა

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

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

ხელის ჩამორთმევა მხოლოდ გვირაბს ადასტურებს

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

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

წაიკითხეთ მოსმენა და მარშრუტი

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

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

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

გამოიყენეთ წესები ლოკალური შემავალისთვის, არა გადამისამართებისთვის

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

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

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

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

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

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

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