VPN სერვერის ახალ საჯარო IP-ზე გადატანა: რა უნდა შევამოწმოთ პირველად
ადგილზე ჩანაცვლება და პარალელური გადასვლა სხვადასხვა ადგილას ირღვევა. გადახედეთ კონფიგურაციებს, NAT-სა და სერტიფიკატებს, შემდეგ შეამოწმეთ, როგორ ხსნის სახელს თითოეული კლიენტი.
მისამართის ხელახალი მინიჭება ერთ წუთს იღებს. მომდევნო კვირა არის ადგილი, სადაც გადატანა ირღვევა, და იშვიათად იქ, სადაც პროვაიდერის კონსოლი მიუთითებს. ახალი საჯარო IP ოთხ ადგილას აისახება: სოკეტი, რომელზეც დემონი უსმენს, ნდობის საყრდენი, რომელსაც კლიენტები ამოწმებენ, ყოველი წესი, რომელიც ძველ მისამართს ასახელებს, და ის DNS ჩანაწერი, რომელიც მათ აკავშირებს. ორი გადატანა მართვის პანელიდან ერთნაირად გამოიყურება, მაგრამ სრულიად განსხვავებულად იქცევა: მისამართის ხელახლა მინიჭება იმ მანქანაზე, რომელსაც თქვენ მართავთ, ან მეორე endpoint-ის დადგმა და კლიენტების იქ გადატანა. ქვემოთ მოცემული შემოწმებები იაფ წარუმატებლობებს პირველ ადგილზე აყენებს, და თითოეული ნაწილი ამბობს, რომელ გადატანას ეხება.
ადგილზე ჩანაცვლება და პარალელური გადასვლა სხვადასხვა სამუშაოა
ადგილზე ჩანაცვლება ინახავს ჰოსტს, გასაღებებს, მარშრუტიზაციის ცხრილს და მომხმარებლების სიას; იცვლება მხოლოდ მისამართი. ამას აკეთებს მოძრავი IP-ის ხელახალი მინიჭება, და რამდენიმე პროვაიდერთან სტუმარი ამას საერთოდ ვერ ამჩნევს, რადგან თარგმანი ინსტანსის წინ ხდება. გადაკეთება ან პროვაიდერის მიერ ხელახალი მინიჭება უფრო მკაცრია: სტუმარი ცვლილებას ხედავს, და ყველაფერი, რაც ძველი მნიშვნელობა ქეშში ჰქონდა, ამას იმავე მომენტში იგებს.
პარალელური endpoint არის მეორე ჰოსტი, რომელიც იმავე სამუშაოს ასრულებს. ააწყვეთ ის, გამოსცადეთ ერთი პროფილით და დატოვეთ ძველი პასუხისმგებლად, სანამ ახალი თავს რეალურ გზაზე დაამტკიცებს. ფასი მდგომარეობაა. საერთო peer ჩანაწერების, გაუქმებებისა და ლოგირების გარეშე თქვენ გაქვთ ორი ქსელი, რომლებიც შემთხვევით იზიარებენ სახელს.
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
იპოვეთ ყველა ადგილი, სადაც ძველი მისამართია დაწერილი
დაიწყეთ ტექსტური სკანირებით, რადგან კონფიგურაციის ფაილები მარტივი ნახევარია. მოძებნეთ დემონის კონფიგურაციაში, ფაირვოლის ნაწყვეტებში, მონიტორინგის სამიზნეებში და დისკზე არსებულ ნებისმიერ გენერირებულ კლიენტურ პაკეტში. ჩართეთ IPv6 მისამართი, თუ ასეთს აქვეყნებთ; გადატანა, რომელიც მხოლოდ A ჩანაწერს მიჰყვება, ორმაგი სტეკის კლიენტებს ძველ გზაზე ტოვებს.
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsშემდეგ გადახედეთ ბირთვს, რადგან მოქმედი სისტემა მისამართს ინახავს იქ, სადაც არც ერთი ფაილი არ იხსენიებს. სტატიკური წყაროს NAT წესი, ipset ჩანაწერი, bind მისამართი და conntrack ჩანაწერი უფრო დიდხანს ცოცხლობს, ვიდრე ის კონფიგურაციის ცვლილება, რომელმაც ისინი წაშალა, და ზოგი გადატვირთვასაც გადაურჩება, რადგან შენახული წესების ნაკრებიდან დაბრუნდა. ერთი დონით ზემოთ, პროვაიდერის უსაფრთხოების ჯგუფები, დატვირთვის ბალანსერის სამიზნეები და მონიტორინგის შემოწმებები საერთოდ არ არის თქვენს ფაილურ სისტემაზე.
ჩაწერეთ ინვენტარი, სანამ რამეს შეცვლით; ის ასევე მუშაობს როგორც დაბრუნების სკრიპტი.
ჰოსტის სახელის კლიენტები აღდგებიან; ლიტერალური IP-ის კლიენტები დუმდებიან
თუ კლიენტები სერვერს ჰოსტის სახელით აღწევენ, გადასვლა ძირითადად DNS პრობლემაა, და გუშინ დაყენებული TTL წყვეტს, რამდენად ცუდი იქნება. რეზოლვერები ქეშავენ, stub რეზოლვერები კიდევ ქეშავენ, და ბევრი კლიენტი სახელს მხოლოდ ახალ კავშირზე ეძებს, ამიტომ დამყარებული გვირაბი ინარჩუნებს საწყის მისამართს.
თუ endpoint ლიტერალური მისამართია, არაფერი იხსნება ხელახლა და არაფერი არ იწერს საჩივარს. WireGuard ინახავს გახსნილ სოკეტის მისამართს: Endpoint = vpn.example.net:51820 IP ხდება იმ მომენტში, როცა wg-quick up მუშაობს, და რჩება იმ IP-დ, სანამ არ შეცვლით. OpenVPN უფრო შემწყნარებელია: ის ხსნის remote ჰოსტის სახელს კავშირის დროს და resolv-retry infinite-ით ხელახლა ცდის DNS-ს ხელახალი დაკავშირებისას. ლიტერალური IP-ის შემთხვევაში ორივე აგრძელებს ზარს იმ მანქანაზე, რომელიც აღარ არსებობს.
ხალხს აცდუნებს სარკისებრი სურათი. კლიენტი, რომელიც უკვე ახალ მისამართზეა მიმართული, სანამ ძველი მსმენელი ჯერ პასუხობს, გადის ყველა ტესტს, რომელსაც საკუთარი მაგიდიდან აკეთებთ. მეც მოტყუებული ვარ ამით: ახალი endpoint ტელეფონზე პირველივე ცდაზე ავიდა, და ძველი პროფილის კლიენტი მხოლოდ მაშინ გამოჩნდა, როცა ძველი მსმენელი ბევრად მოგვიანებით გამოირთო.
ნდობა მისამართთან ერთად არ გადადის
WireGuard იდენტობას ხელმისაწვდომობისგან ჰყოფს, რაც მისამართის გადატანას თითქმის უფასოს ხდის. Peer-ები საჯარო გასაღებით იდენტიფიცირდებიან, და endpoint მხოლოდ ის ადგილია, სადაც პაკეტები ახლა მიდის; ჰოსტი peer-ის endpoint-ს ბოლო ავთენტიფიცირებული პაკეტის წყაროს მისამართიდან აახლებს. უმოქმედო peer-ს მაინც სჭირდება მიზეზი ახალ ადგილთან სასაუბროდ, და მისამართს მხოლოდ მაშინ სწავლობს, როცა მისი სესია ძველდება და handshake-ის განმეორებითი ცდები ხილულ ადგილას ვარდება. WireGuard-ის სწრაფი გზამკვლევი endpoint ველს მოიცავს.
TLS-ზე დაფუძნებული სერვერები საწინააღმდეგო შემთხვევაა. სერტიფიკატი სახელზეა მიბმული, და მისამართზე დამრეკი კლიენტი თავის არჩევანს სუბიექტის ალტერნატიულ სახელებს ადარებს. დაუკავშირდით IP-ით სერტიფიკატს, რომელიც მხოლოდ DNS SAN-ს ატარებს, და შემოწმება ვარდება: კლიენტის მიერ გამოყენებული სახელი სერტიფიკატში არ არის. IP SAN-ით ხელახალი გამოცემა ამ ერთ კავშირს ასწორებს და შემდეგ გადატანას აუარესებს. პროფილში ჰოსტის სახელის შენარჩუნება და verify-x509-name-ის ადგილზე დატოვება შემოწმებას მკაცრად ინახავს, სანამ ქვემოთ მისამართი იცვლება.
შემდეგ შეამოწმეთ, რაზეა დემონი მიბმული; ძველ მისამართზე მიმაგრებული სოკეტი ჩუმად ვარდება. local 203.0.113.10-ით გაშვებული OpenVPN სერვერი უარს ამბობს ასვლაზე, როგორც კი ეს მისამართი გაქრება, ხოლო 0.0.0.0-ზე მსმენელი ცვლილებას უფასოდ მიჰყვება. NAT ანალოგიურად იყოფა: MASQUERADE მიჰყვება იმ მისამართს, რაც მანქანას ახლა აქვს, და სტატიკური SNAT --to-source 203.0.113.10 აგრძელებს გადაწერას მისამართზე, რომელიც აღარ გეკუთვნით, ამიტომ დაბრუნების ტრაფიკი ქრება. თუ ახალი მისამართი სხვა upstream კარიბჭესთან მოდის, შეამოწმეთ rp_filter: უკუ გზის ფილტრაცია ყრის დაბრუნების ტრაფიკს, რომელიც ინტერფეისზე მოდის და რომელსაც ბირთვი არ ელოდა.
გადასვლის რიგი და მტკიცებულება, რომ იმუშავა
TTL ერთი დღით ადრე დაწიეთ, ახალი მსმენელი დადგით და დაამტკიცეთ იმ პროფილით, რომელიც მხოლოდ თქვენ გაქვთ. იმავე ქსელის შიგნიდან ტესტი თითქმის არაფერს ამტკიცებს, ამიტომ გამოიყენეთ ტელეფონი მობილურ ქსელზე და გამოსცადეთ ის, რაც გვირაბმა უნდა გადაიტანოს და არა ping endpoint-ზე.
თვალყური ადევნეთ ორივე მისამართს მთელი ფანჯრის განმავლობაში. wg show all latest-handshakes ახალ ჰოსტზე, ან OpenVPN-ის სტატუსის ფაილი გეტყვით, რამდენი peer რეალურად გადავიდა. როცა ახალ endpoint-ს მოსალოდნელი peer-ები ჰყავს, ხოლო ძველს მხოლოდ ჩამორჩენილები, გაიყვანეთ ძველი მსმენელი ექსპლუატაციიდან, წაშალეთ მოძველებული NAT წესი და ამოიღეთ მისამართი პროვაიდერის ფაირვოლიდან. ძველი მსმენელის წაშლა ის ნაბიჯია, რომელიც გამოტოვებულია, და ის ხურავს იმ ნაპრალს, სადაც მოძველებული პროფილი ჯერ კიდევ აღწევს ძველ ქსელში.
დაწყებამდე წერილობით განსაზღვრეთ დაბრუნების ტრიგერი: თუ შეთანხმებული ფანჯრის შემდეგ ახალ endpoint-ს არც ერთი რეალური კლიენტისგან handshake არ აქვს, აღადგინეთ ძველი მისამართი და შეწყვიტეთ პროფილების გავრცელება. შემდეგ ხელახლა გაუშვით სკანირება და დაადასტურეთ, რომ არც ერთი მსმენელი აღარ არის მიბმული გაყვანილ მისამართზე. ორი რამ გადადის შემდეგ გადატანაზე: ჰოსტის სახელი კლიენტის პროფილში, რომ შემდეგი ცვლილება DNS რედაქტირება იყოს, და სერვერის აღდგენის ჩანაწერების გვერდით შენახული ინვენტარი.