როგორ ავაშენოთ WireGuard-ის ტესტი ორი პირით, რომელიც ერთ გზას ამტკიცებს

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

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

გასაღებები, მისამართები და ერთადერთი endpoint

თითოეულ სისტემაზე შექმენით გასაღების წყვილი და მათ შორის გადაიტანეთ მხოლოდ საჯარო ნახევრები. wg genkey | tee privatekey | wg pubkey > publickey არის დოკუმენტირებული ერთხაზიანი ბრძანება და კერძო გასაღებს ტოვებს ფაილში, რომელსაც შემდეგ შეგიძლიათ დაიცვათ. აირჩიეთ გვირაბის მისამართები დიაპაზონიდან, რომელიც არ გვხვდება თქვენს არც ერთ სხვა კონფიგურაციაში, მაგალითად 10.99.0.1/24 და 10.99.0.2/24. ჩაწერეთ, რომელი მისამართი რომელ მანქანას ეკუთვნის, რადგან ყოველი შემდგომი შემოწმება ამ დაბმაზეა დამოკიდებული.

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

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

ველები, რომლებიც wg-ს ეკუთვნის და რომლებიც არა

ძირითადი ველების ნაკრები პატარაა: PrivateKey და ListenPort Interface-ის ქვეშ, PublicKey, AllowedIPs და Endpoint Peer-ის ქვეშ. Address და DNS wg-quick-ს ეკუთვნის და არა თავად wg-ს, და ეს განსხვავება კბენს იმ მომენტში, როცა იგივე კონფიგურაცია სხვა ხელსაწყოში გადადის.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

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

ხელის ჩამორთმევის კითხვა ხატულის ნაცვლად

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

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

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

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

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

საფუძვლის შენარჩუნება როგორც ნიმუში

შეინახეთ მოქმედი ტოპოლოგია და პროფილის წყარო იმ ადგილას, საიდანაც შეგიძლიათ აღდგენა, და შორს დაიჭირეთ ყოველი საქაღალდისგან, რომელიც საჯარო სერვისთან სინქრონდება. შემდეგ ერთდროულად ერთი ფუნქცია დაამატეთ და ყოველი მის შემდეგ გაიმეორეთ საწყისი მოთხოვნა: გადამისამართება, NAT, LAN მარშრუტი და მხოლოდ შემდეგ DNS. ყოველი დამატება, რომელიც ტესტს ამტვრევს, ახლა ამოსაცნობია, რადგან სხვა არაფერი მოძრაობს.

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