რა უშლის OpenVPN-ის route-nopull სინამდვილეში სერვერს გაგზავნაში
route-nopull ყრის გაგზავნილ მარშრუტებსა და DHCP პარამეტრებს, არა ხელის ჩამორთმევას. შეარჩიეთ მას, pull-filter-სა და არაფერს შორის, შემდეგ თავად დაამატეთ მარშრუტები.
თქვენ ჩასვით route-nopull კლიენტის პროფილში, რომ გვირაბმა თქვენი ნაგულისხმევი მარშრუტი არ გადაყლაპოს, და ახლა ოფისის ქვექსელი მიუწვდომელია, სანამ კლიენტი კვლავ ამბობს, რომ დაკავშირებულია. ორივე დაკვირვება მართალია და არაფერი ჩავარდნილა. დროშა ეუბნება კლიენტს, გამოტოვოს სერვერის მიერ გაგზავნილი მარშრუტები და DHCP ჩანაწერები, რაც უფრო ვიწრო მითითებაა, ვიდრე ადამიანების უმეტესობა ელოდება მის დამატებისას. რაც რჩება, სამუშაო გვირაბია, რომელსაც აზრი არ აქვს იმაზე, თუ რომელმა დანიშნულებებმა უნდა გამოიყენონ იგი.
ეს უფსკრული არის მთელი გადაწყვეტილება, რომელზეც ეს სტატიაა. ან სერვერი აღწერს ქსელს, ან კლიენტი, და დროშა ამ საქმეს კლიენტს გადასცემს, თქვენთვის მისგან არაფერი გაკეთებულა.
რასთან გამორთავს დროშა დაკავშირებისას
მწველ OpenVPN კლიენტი ჩვეულებრივ ავთენტიფიკაციის შემდეგ სერვერიდან იღებს პაკეტს: მარშრუტებს, ნაგულისხმევი კარიბჭის გადამისამართებას, DNS სერვერებს და რამდენიმე რეგულირების დირექტივას. route-nopull მოქმედებისას კლიენტი კვლავ იღებს სესიას, კვლავ ამოწმებს სერტიფიკატებს, კვლავ აწარმოებს მოლაპარაკებას შიფრებზე და keepalive-ზე, და კვლავ ხსნის ინტერფეისს. რასაც ის ყრის, არის გაგზავნილი route ხაზებისა და გაგზავნილი dhcp-option ხაზების გამოყენება, DNS-ის ჩათვლით.
დაბნეულობა მოდის მკვდარი აპლიკაციის გვერდით მდებარე მწვანე ინდიკატორიდან. გვირაბი არსებობს, დანიშნულებების დაკავშირება ამ გვირაბთან — არა. კლიენტის სტატუსის პანელში არაფერი განასხვავებს „დაკავშირებულ და მარშრუტიზებულს“ „დაკავშირებულ და უმოქმედოსგან“, რადგან გვირაბის თვალსაზრისით ორივე ერთი და იგივე მდგომარეობაა.
რატომ შეიძლება ცოცხალმა გვირაბმა მაინც ვერაფერი დაამარშრუტოს
ინტერფეისი ჩნდება საკუთარი მისამართით და წერტილ-წერტილ კავშირზე ხშირად არაფერი უფრო კონკრეტული არ აქვს, ვიდრე ჰოსტის მარშრუტი პარტნიორისკენ. კერძო ქვექსელი ხელმისაწვდომი ხდება მხოლოდ მაშინ, როცა რომელიმე მარშრუტი სწორი პრეფიქსით მიუთითებს ამ ინტერფეისზე, და გაგზავნის გამორთვისას ეს მარშრუტი არასდროს მოდის. ჩამოტვირთული პროფილი ჩვეულებრივ ვერც დაეხმარება, რადგან ის დაიწერა იმ ვარაუდით, რომ სერვერი ზუსტად ამ ინფორმაციას მოგვცემდა. ამიტომ ინტერფეისი შეიძლება ჯანმრთელად გამოიყურებოდეს, სანამ ქვექსელი ბნელი რჩება.
ამრიგად, პროფილის წაკითხვა ძალიან ცოტას ამტკიცებს. წაიკითხეთ გაშვებული მდგომარეობა დაკავშირებულ მანქანაზე:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10მისამართი ქვექსელის მარშრუტის გარეშე მეორე ბრძანებაში ამ პრობლემის ხელმოწერაა. მესამე ბრძანება შემდეგ პასუხობს კითხვას, რომელიც მომხმარებლებს ნამდვილად ადარდებთ, რადგან ის აცნობებს ინტერფეისს, რომელსაც ბირთვი აირჩევდა კონკრეტული დანიშნულებისთვის და არა იმ სიას, რომელზეც იმედოვნებდით, რომ გამოიყენებდა. თუ ის პასუხობს თქვენი ფიზიკური კავშირით, გვირაბი საერთოდ არ არის გზაზე.
სახელების გადაწყვეტა ვარდება დაკავშირებული მიზეზით და არა ცალკე. გაგზავნილი dhcp-option DNS ჩანაწერები გამოტოვებულია იმავე დროშით, ამიტომ შიდა ჰოსტებზე მოთხოვნები მიდის იმ გადამწყვეტთან, რომელიც ლოკალურმა ქსელმა მოგვცა. ამ გადამწყვეტს ოფისისთვის ზონა არ აქვს, ამიტომ მოთხოვნა ვარდება ან აბრუნებს საჯარო პასუხს, და წარუმატებლობა სერვერის პრობლემად გამოიყურება, მაშინ როცა ეს კლიენტის კონფიგურაციის პრობლემაა. მისამართის სახელზე ადრე გამოცდა არის ის, რაც ორივეს ჰყოფს.
არჩევანი დროშასა და პრეფიქსის ფილტრს შორის
ორი ვარიანტი ერთი და იმავე ჩივილის სხვადასხვა ფორმას წყვეტს, და ცუდი არჩევანი ქმნის მდგომარეობას „დაკავშირებული, მაგრამ უსარგებლო“. ერთი მთლიანად ცვლის გაგზავნილ პოლიტიკას, მეორე კი პრეფიქსით ასწორებს მას. ცხრილი გაძლევთ მოკლე ვერსიას, და მის შემდეგ აბზაცი ფარავს იმ ნაწილს, რომელიც ადამიანებს აკვირვებს.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter სამი ზმნის მქონე პრეფიქსის შემადგენელია, ამიტომ მას შეუძლია ხაზების ოჯახის მიღება, მათი ჩუმად უგულებელყოფა ან კავშირის სრულად უარყოფა, როცა პრეფიქსი გამოჩნდება. სწორედ ბოლო ქცევაა ღირსეული ცოდნისა: უარყოფის წესი პოლიტიკურ უთანხმოებას აქცევს ჩავარდნილ ხელის ჩამორთმევად და არა მშვიდ გამოტოვებად. OpenVPN 2.6-ის სახელმძღვანელო ჩამოთვლის მიღებულ პრეფიქსებს და თითოეული ზმნის ზუსტ მნიშვნელობას.
გავრცელებული შუალედური გზაა მხოლოდ redirect-gateway-ის უარყოფა და ოფისის მარშრუტებისა და DNS-ის დანიშნულებისამებრ მოსვლის დაშვება. ეს ინახავს გაგზავნას მუშა მდგომარეობაში იმ ნაწილებისთვის, რომლებსაც სერვერი თქვენზე უკეთ ესმის, და ამავდროულად ხელს უშლის იმ ერთ ხაზს, რომელიც წაართმევდა თქვენს ნაგულისხმევ მარშრუტს.
მარშრუტებისა და გადამწყვეტის ხელით დამატება
თუ დროშას ტოვებთ, პროფილმა უნდა თქვას ის, რასაც სერვერი იტყოდა. კლიენტის მხარეს route დირექტივები გამოიყენება კავშირის დამყარების შემდეგ, ამიტომ ისინი მუშაობენ დროშასთან ერთად და არა მის მიერ დაბლოკილი. ჩადეთ ისინი პროფილში და არა ინტერაქტიულ ბრძანების ხაზში, თორემ შემდეგი ხელახალი დაკავშირება არ გაამრავლებს მუშა მდგომარეობას.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS ხაზი არასასიამოვნო მდგომარეობაშია: ეს კლიენტის მხარის დირექტივაა, მაგრამ ზოგიერთი კლიენტი მას მხოლოდ პლატფორმის DNS ინტეგრაციის გავლით იყენებს, რომელმაც შეიძლება გადააწეროს ის, როცა კავშირი იცვლება. systemd ჰოსტზე გადამწყვეტის უშუალოდ გვირაბის ინტერფეისზე დაყენება უფრო პროგნოზირებადია, ვიდრე იმედი, რომ კლიენტი პრიორიტეტულ შეჯიბრს მოიგებს:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comმარშრუტიზაციის დომენი იმდენად მნიშვნელოვანია, რამდენადაც მისამართი. მის გარეშე საჯარო სახელებზე მოთხოვნები შეიძლება შიდა გადამწყვეტთანაც გაიგზავნოს, და ნებისმიერი შიდა გადამწყვეტი, რომელიც რეკურსიაზე უარს ამბობს, დაამტვრევს დათვალიერებას, სანამ კერძო ზონა მუშაობს. მასთან მხოლოდ ამ სუფიქსის ქვეშ მყოფი სახელები მიემართება გვირაბის გადამწყვეტთან და დანარჩენი ყველაფერი ფიზიკურ კავშირს მიჰყვება.
შედეგის შემოწმება: მისამართი, სახელი და გარე გზა
სამი ტესტი ჰყოფს შესაძლო ჩავარდნებს. მიიღეთ კერძო მისამართი IP-ით, შემდეგ იგივე ჰოსტი სახელით, შემდეგ ჩვეულებრივი საჯარო საიტი. მომუშავე IP ჩავარდნილი სახელით მიუთითებს გადამწყვეტზე, ჩავარდნილი IP მომუშავე სახელით — მარშრუტიზაციაზე, ხოლო ორივეს ჩავარდნა ჩვეულებრივ ნიშნავს, რომ გვირაბი გზაზე არ არის.
შემდეგ შეხედეთ გარეთ და არა შიგნით. გვირაბის ბოლო წერტილის საკუთარი მარშრუტი უნდა გადაურჩეს ცვლილებას, და ნებისმიერი ბლოკირებადი ჩავარდნა უნდა შემოიფარგლოს გვირაბით ბოლო წერტილის დაჭერის გარეშე. კლიენტი, რომელიც გვირაბის ვარდნის შემდეგაც აგრძელებს დათვალიერებას, პოლიტიკის პრობლემაა და არა მარშრუტიზაციის, და ის არ გამოჩნდება ზემოთ მოცემული სამი ტესტიდან არცერთში.
ჩაწერეთ საბოლოო სია პროფილის დოკუმენტაციაში: მარშრუტები, გადამწყვეტი, დომენები და თითოეულის არსებობის მიზეზი. ხელახალი დაკავშირება, რომელიც იმავე ცხრილს ამრავლებს, ერთადერთი მტკიცებულებაა, რომ ადგილობრივი პოლიტიკა სრულია. თუ აპლიკაციები მაინც ვარდება, როცა გვირაბი აწეულია და სამივე ტესტი გავლილია, შემდეგი ადგილი, სადაც უნდა შეხედოთ, არის „დაკავშირებული, მაგრამ ოფლაინ“ პრობლემების კლასი და არა უკვე შემოწმებული სერტიფიკატები.