WireGuard-ის კლიენტი OpenVPN-ის კლიენტს ვერ აღწევს?

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

სიმპტომს ყოველ ჯერზე ერთი ნაწილი აკლია

ეს დიზაინი იყენებს WireGuard-ის აუზს 10.71.0.0/24 wg1-ზე და OpenVPN-ის აუზს 10.72.0.0/24 tun1-ზე, ორივე ერთ კარიბჭეზე სრულდება. საცდელი მოთხოვნა მიდის 10.71.0.5-იდან 10.72.0.30-ზე HTTPS-ზე. ქვემოთ ყოველი ნაბიჯი სწორედ ამ ერთ ნაკადს ეხება. ყოველ შემოწმებას განსხვავებული წარუმატებლობის ხელწერა აქვს, თუმცა მომხმარებელი მათ ერთნაირად განიცდის, და ჩვეულებრივ ერთდროულად სამიდან მხოლოდ ერთი აკლია.

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

გააფართოეთ შტოს დანიშნულების დაფარვა

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

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

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

შეინარჩუნეთ წყაროს საკუთრება კარიბჭეზე

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

AllowedIPs = 10.71.0.5/32

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

მიეცით OpenVPN-ის მხარეს დაბრუნების მარშრუტი

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

push "route 10.71.0.0 255.255.255.0"

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

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

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

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

ურთიერთი მარშრუტები ჩვეულებრივ ნიშნავს, რომ წყაროს თარგმნა არ არის საჭირო, რაც ინარჩუნებს WireGuard-ის მისამართს დანიშნულებაზე და ჟურნალებს წაკითხვადს ხდის. ნუ დაამატებთ ყოვლისმომცველ masquerading-ს იმიტომ, რომ ორი პროტოკოლი მონაწილეობს, და ნუ წაშლით არსებულ თარგმნის წესს იმის უცოდინრად, თუ რაა მასზე დამოკიდებული. შემდეგ გადაამოწმეთ ერთი ნაკადი თავიდან ბოლომდე, და გამოსცადეთ ერთი აკრძალული წყარო ან პორტიც: მუშა ხელის ჩამორთმევა თითოეულ მხარეს არც გადაკვეთილ მარშრუტს ამტკიცებს და არც იზოლაციას.