რას უმატებს bypass-dhcp სინამდვილეში OpenVPN-ის მარშრუტების გეგმას

redirect-gateway def1 bypass-dhcp-ის მქონე პროფილი აერთიანებს IPv4 ნაგულისხმევი მარშრუტის ჩანაცვლებას ერთ ვიწრო გამონაკლისთან. ადამიანები კითხულობენ ბოლო სიტყვას და ელიან მობილური კავშირების ზოგად გადაწყვეტას, შემდეგ კი ნახევარ დღეს ატარებენ იმ DHCP თეორიაში, რომელიც ამ დროშას არასდროს უჭერია მხარი. თითოეული ნაწილი ერთ საქმეს აკეთებს, და გამონაკლისი მის რეპუტაციაზე ბევრად პატარაა.

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

ორი დროშა, ორი დაუკავშირებელი საქმე

def1-ით კლიენტი ამატებს ორ IPv4 ნახევარ-ნაგულისხმევ მარშრუტს იმის ნაცვლად, რომ ჩაანაცვლოს უკვე არსებული ნაგულისხმევი მარშრუტი. 0.0.0.0/1 ფარავს მისამართების სივრცის ქვედა ნახევარს, ხოლო 128.0.0.0/1 ზედა ნახევარს, ამიტომ ერთად ისინი აღწევენ ყველა დანიშნულებას, სანამ თითოეული რჩება უფრო კონკრეტული, ვიდრე 0.0.0.0/0. ამიტომ თავდაპირველი ნაგულისხმევი მარშრუტი რჩება ცხრილში იმ ძიებათა გამარჯვების გარეშე, რაც ძველ კარიბჭეს ხელმისაწვდომად ინახავს ყველაფრისთვის, რასაც კლიენტი ცხადად მარშრუტიზებს. ის ასევე ტოვებს ცხრილში ორ გადამფარავ ნაგულისხმევ მარშრუტს, და ამიტომ მარშრუტების დამპი შეიძლება უფრო უცნაურად გამოიყურებოდეს, ვიდრე პროფილი მიანიშნებს.

bypass-dhcp ცალკეა და ნაგულისხმევ მარშრუტს საერთოდ არ ეხება. OpenVPN 2.6-ის სახელმძღვანელო აღწერს მას, როგორც პირდაპირი მარშრუტის დამატებას იმ DHCP სერვერთან, რომელიც ლოკალურ ქვექსელში არ არის, რათა იჯარის ტრაფიკი გვირაბის გარეთ გავიდეს, და აღნიშნავს, რომ ეს ქცევა დანერგილია Windows კლიენტებში და შეიძლება სხვაგან მიუწვდომელი იყოს.

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

რაზე ვრცელდება გამონაკლისი სინამდვილეში

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

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

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

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

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

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

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

გზის დარჩენილი ნაწილი ამ დროშაში არ არის

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

სახელების გარჩევას და IPv6-ს თითოეულს საკუთარი პოლიტიკა სჭირდება. IPv4-ის ჩანაცვლება არც რეზოლვერს მიმართავს გვირაბის მხარეს არსებული სერვერისკენ და არც IPv6 დაფარვას ქმნის, და კლიენტი, რომელიც მხოლოდ v4-ს გადამისამართებს, v6 გზას ხელუხლებლად ტოვებს.

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