OpenVPN redirect-gateway: რას აკეთებს თითოეული დროშა მარშრუტებთან

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

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

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

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

def1 იმარჯვებს სიზუსტით, თქვენს ნაგულისხმევს რომ არ შეეხოს

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

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

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

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

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

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

ip route get 198.51.100.20

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

IPv6 ტრაფიკი აგრძელებს საკუთარი ცხრილის გამოყენებას

IPv4-ის გადამისამართება IPv6-ს მარტო ტოვებს და ორივე ოჯახს სხვადასხვა დროშა ცვლის. ორმაგი დასტის ჰოსტზე, სადაც v6 ნაგულისხმევი მუშაობს, v4 ტრაფიკი შეიძლება მთლიანად გვირაბში იჯდეს, სანამ ყოველი v6-უნარიანი დანიშნულება ფიზიკური რგოლით გადის გარეთ. ჰოსტი, რომელიც ერთ ცხრილში სწორად გამოიყურება, მეორეში ჟონავს.

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

ip -6 route show default
ip -6 route get 2001:db8::10

დაამტკიცეთ, რომელ ინტერფეისს იყენებს აპლიკაცია

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

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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