VPN გადავიდა: რატომ ურეკავს თქვენი OpenVPN კლიენტი ჯერ კიდევ ძველ IP-ს
ახალი DNS ჩანაწერი მხოლოდ ერთი ნაბიჯია. შეადარეთ გადამწყვეტის პასუხი, მისამართი, რომელსაც კლიენტი რეალურად ურეკავს და გადატვირთვის ვარიანტები, სანამ ხელახალ დაკავშირებას დაელოდებით.
პროვაიდერმა შეცვალა თქვენი საჯარო მისამართი, თქვენ განაახლეთ დინამიკური DNS ჩანაწერი და კლიენტი მაინც ვერ უკავშირდება. გარედან ჩანს, თითქოს ჩანაწერი არ გავრცელდა. უმეტეს შემთხვევაში ჩანაწერი რიგზეა და კლიენტი ურეკავს იმ მისამართს, რომელიც გადატანამდე გადაჭრა, რადგან მოქმედ გვირაბსა და შენახულ პროფილს თითოეულს საკუთარი წარმოდგენა აქვს, სად ცხოვრობს სერვერი. სამი ფენა უნდა შეთანხმდეს და ისინი სხვადასხვა გრაფიკით ახლდება.
შეხედეთ, რას ურეკავს პროფილი და არა რას ამბობს DNS
გახსენით კავშირი, რომელსაც რეალურად იყენებთ და წაიკითხეთ remote ხაზი. იქ არსებული რიცხვითი მისამართი არასდროს მიჰყვება ჰოსტის სახელის განახლებას, რამდენადაც სწორი გახდება ჩანაწერი.
შემდეგ შეამოწმეთ, არის თუ არა თქვენ მიერ რედაქტირებული პროფილი ის, რომელიც კლიენტმა ჩატვირთა. იმპორტირებული პროფილები ხშირია: ადმინისტრატორს შეიძლება თვეების წინ აეღო ასლი და შეენარჩუნებინა საკუთარი ვერსია, ამიტომ თქვენს ჩამოტვირთვების საქაღალდეში არსებული ფაილი და აპში არსებული ჩანაწერი შეიძლება განსხვავდებოდეს. შეადარეთ საბოლოო წერტილი თავად კლიენტის კავშირის დეტალებში, სანამ DNS-ის გამართვას დაიწყებთ.
ორი ფაილი, ერთი საბოლოო წერტილი — ეს არის ჩვეული აღმოჩენა აქ.
grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.netწაიკითხეთ კლიენტის შემდეგი კავშირის მცდელობა
გადატვირთეთ კავშირი დეტალური ჟურნალით და წაიკითხეთ ხაზი, სადაც დასახელებულია მისამართი, რომელსაც დაუკავშირდება. სწორედ ეს მნიშვნელობაა მთავარი და არა ის, რაც თქვენმა ბრაუზერმა გადაჭრა.
გადამწყვეტის ქეშს შეიძლება ჯერ კიდევ ჰქონდეს წინა პასუხი და ზოგიერთი ქსელი მას უფრო დიდხანს ინახავს, ვიდრე ჩანაწერის TTL მოითხოვს. ჰკითხეთ გადამწყვეტს, რომელსაც კლიენტი რეალურად იყენებს და არა საჯაროს, რომელიც სხვა ადგილიდან გამოსცადეთ.
თუ ჟურნალი აჩვენებს ახალ მისამართს და კავშირი მაინც ვერ დგება, პრობლემა გადაადგილდა: პაკეტი სადღაც მიდის და არავინ პასუხობს. ეს მსმენელის, ფაირვოლის ან პორტის გადამისამართების საკითხია და ის სერვერის მხარესაა და არა კლიენტის გადაწყვეტის გზაზე. გამოყავით ეს ორი მარცხი, რადგან მიუწვდომელი მსმენელის DNS პრობლემად მიჩნევა ორჯერ ატარებს თქვენ იმავე მარყუჟში.
იცოდეთ, რომელ გადატვირთვას აკეთებთ
ყველა გადატვირთვა არ ინახავს ერთსა და იმავე მდგომარეობას, ამიტომ მისამართის ცვლილება შეიძლება განსხვავებულად მოიქცეს იმის მიხედვით, როგორ გადამუშავდება პროცესი. სიგნალით გამოწვეული რბილი გადატვირთვა ინახავს წინა სესიის მეტ კონტექსტს, ხოლო სრული გაჩერება და გაშვება ისევ კონფიგურაციიდან იწყება. თუ ამოწმებთ, გადაჭრის თუ არა კლიენტი ხელახლა, გჭირდებათ კონფიგურაციიდან დაწყებული გზა.
მდგრადობის პარამეტრებსაც აქვს მნიშვნელობა, რადგან ისინი შექმნილია იმის შესანარჩუნებლად, რაც ავთენტიფიცირდა და არა ახალი მისამართების დევნისთვის.
ყველაზე სუფთა ტესტია ახალი გაშვება განკუთვნილი პროფილიდან, შემდეგ კი საბოლოო წერტილის მომხსენებელი ჟურნალის ხაზის დათვალიერება. რასაც ნაწილობრივ შენახული სესიიდან ისწავლით, ამ სესიის შესახებ განცხადებაა.
ოთხი ვარიანტი და მათი ცალკეული საქმეები
ჰოსტის სახელით remote არის პარამეტრი, რომელიც ხელახალ გადაწყვეტას საერთოდ შესაძლებელს ხდის; ამ ხაზზე ლიტერალური მისამართი გამორიცხავს მას. resolv-retry აკონტროლებს, რა მოხდება ძიების წარუმატებლობისას და 2.6 მას უკვე ნაგულისხმევად უსასრულოს ხდის. ამიტომ მისი დამატება არაფერს ცვლის და ის არასდროს გეგმავს პერიოდულ შემოწმებას სხვა პასუხისთვის. ვინც ამბობს, რომ ის ახალ მისამართებს იკვლევს, აღდგენა და სიახლე აურია.
persist-remote-ip უწყვეტობაზეა და არა სიახლეზე: ის ხელახლა იყენებს იმ საბოლოო წერტილს, რომელიც ბოლოს ავთენტიფიცირდა, მის მიერ მხარდაჭერილ რბილ გადატვირთვებზე. სანამ გადატანას ცდით, ეს თქვენი სურვილის საპირისპიროა. გამორთეთ ის ტესტისთვის, თუ თქვენი ნაგებობა ჩართავს მას და აღადგინეთ, როცა ახალი საბოლოო წერტილი დამტკიცდება. ჩართული დატოვებისას წარმატებულმა ხელახალმა დაკავშირებამ შეიძლება DNS-ის შესახებ არაფერი გითხრათ.
float იღებს ავთენტიფიცირებულ პარტნიორს, რომლის მისამართიც სესიის შუაში შეიცვალა და მხოლოდ იმ განლაგებებში, რომლებიც ამას მხარს უჭერენ. ის არ აახლებს DNS-ს და დამოუკიდებლად არ მიჰყვება პროვაიდერის ცვლილებას. მოეპყარით როგორც მოძრავი პარტნიორებისთვის გამძლეობის ფუნქციას და არა როგორც სერვერების დინამიკური მისამართების მექანიზმს.
დაადასტურეთ ახალი საბოლოო წერტილი, სანამ კლიენტს დაადანაშაულებთ
თქვენი ქსელის გარედან შეამოწმეთ, რომ ახალ მისამართს აქვს მსმენელი კონფიგურირებულ პორტზე და პროვაიდერის გადამისამართება მასზე მიუთითებს. სწორი A ჩანაწერი ღია პორტის გარეშე მანქანისთვის ქმნის ზუსტად იმ სიმპტომს, რომელსაც ადამიანები ქეშს მიაწერენ.
შემდეგ ხელახლა დაუკავშირდით და დაადასტურეთ ორი რამ: კლიენტი ავთენტიფიცირდა მოსალოდნელი სერვერის სერტიფიკატის წინააღმდეგ და სესია აღწევს თქვენ მიერ განზრახულ რესურსამდე. მისამართის ცვლილება არ ამცირებს იდენტობის მოთხოვნებს და არასწორ საბოლოო წერტილთან წარმატებული კავშირი უარესია, ვიდრე წარუმატებელი. OpenVPN 2.6-ის სახელმძღვანელო ჩამოთვლის ოთხივე ვარიანტს საკუთარი არეალით და ეს არის პროფილის გვერდით შესანახი სია.
შეინარჩუნეთ სერვერზე შესვლის ზოლგარე გზა, სანამ გადატვირთავთ გვირაბს, რომელიც თქვენს ადმინისტრაციულ წვდომას ატარებს. ეს ერთი სიფრთხილე აჩერებს ამ სცენარის მიერ წარმოქმნილი შემთხვევების უმეტესობას.