შეამოწმეთ VPN სერვერის აღდგენა გადატვირთვის შემდეგ: რა უნდა შეამოწმოთ პირველად

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

ოთხი მფლობელი, ოთხი განსხვავებული ტესტი

გადატვირთვამდე დაასახელეთ, რამ უნდა დააბრუნოს გვირაბი. ტესტი, რომელსაც ატარებთ, და შესწორება, რომელსაც იყენებთ, ორივე ამ პასუხზეა დამოკიდებული და არსებობს ოთხი ჩვეულებრივი მფლობელი: systemd-ის unit VPN-ის დემონისთვის, wg-quick-ის ეგზემპლარის unit WireGuard-ის ინტერფეისისთვის, კონტეინერის runtime ან ქსელის მენეჯერის პროფილი. თუ მფლობელს ვერ ასახელებთ, გაჩერდით და იპოვეთ ის, რადგან მოსალოდნელი გაშვების ბილიკის გარეშე გადატვირთვის ტესტი მხოლოდ იმას გეუბნებათ, რომ რაღაც მოხდა.

ყოველი მფლობელი თავის კონფიგურაციას სხვაგან ინახავს. systemd-ის მიერ მართული OpenVPN სერვერი კონფიგურაციას გაშვებისას კითხულობს, ამიტომ ჩატვირთვის მომენტში ფაილში რაც არის, ის ეშვება. wg-quick-ის ინტერფეისი მისამართებს, მარშრუტებსა და DNS-ს იმავე ფაილიდან იღებს, რაც ნიშნავს, რომ ჭურვიდან ხელით ამაღლებული და არასდროს unit-ად ჩართული ინტერფეისი არ დაბრუნდება. კონტეინერი თავის შესვლის წერტილს აბრუნებს, მაგრამ ჰოსტის firewall-ის ცვლილებებს არა, თუ ისინი კონტეინერის გარეთ არ ცხოვრობენ.

ჯერ საბაზისო მდგომარეობა, თორემ შედეგს არაფერი ნიშნავს

ჩაწერეთ სამუშაო მდგომარეობა, სანამ მუშაობს: მისამართები გვირაბზე, მარშრუტები კლიენტის ქვექსელისთვის, NAT ან გადამისამართების წესები, მოსმენის სოკეტი და გადამისამართების sysctl. ip addr show wg0, ip route, nft list ruleset ან iptables-save, ss -lunp და sysctl net.ipv4.ip_forward საკმარისია უმეტეს ჰოსტზე.

ჩაწერეთ, როგორ არის სერვისი კონფიგურირებული გაშვებისთვის, და არა მხოლოდ ის, რომ მუშაობს. systemctl is-enabled wg-quick@wg0 და systemctl is-active wg-quick@wg0 სხვადასხვა კითხვას პასუხობენ, და ჩატვირთვისას სწორედ ჩართული მდგომარეობაა მნიშვნელოვანი, როგორც აღწერილია systemctl(1)-ში. OpenVPN-ისთვის შეამოწმეთ, რომელ შაბლონს იყენებს ჰოსტი, რადგან openvpn@server და openvpn-server@server სხვადასხვა ნაგულისხმევის მქონე სხვადასხვა unit-ებია.

შეასრულეთ გადატვირთვა და წაიკითხეთ პირველი მარცხი

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

დემონი შეიძლება აქტიური იყოს, სანამ გვირაბი გამოუსადეგარია, და ეს ყველაზე გავრცელებული ცრუ გავლაა. გაშვება შეიძლება დასრულდეს ქსელის ონლაინ გახდომამდე, თუ unit მხოლოდ network.target-ს ელოდება და არა network-online.target-ს. მითითებული ფაილები, როგორიცაა სერტიფიკატები, გასაღებები ან CRL, შეიძლება იმ მომენტში წაუკითხავი იყოს, რადგან mount ან საიდუმლოების ბილიკი ჯერ მზად არ არის. არც ერთი პრობლემა არ ჩანს systemctl status-ში, სანამ არ წაიკითხავთ unit-ის ჟურნალს.

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

სამი პირობა, რომლებიც თქვენს შესწორებას განსაზღვრავს

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

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

ჩაწერეთ შედეგი runbook-ში

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

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