გჭირდებათ თუ არა დინამიკური DNS სახლის VPN სერვერისთვის?

სახლის VPN-ის იმ ხარვეზების უმეტესობა, რომლებზეც მეკითხებიან, DNS-ის ხარვეზი არ არის და მაინც ჯერ დინამიკური DNS-ის გამოწერას ყიდულობენ. სანამ რამეს დააყენებთ, გადაწყვიტეთ, ჰოსტის სახელი ხომ არ არის ის ნაწილი, რომელიც ნამდვილად გატეხილია. განახლების პროგრამა ჩანაწერს გადაწერს, როცა თქვენი პროვაიდერის მოცემული მისამართი იძვრება; მას არ შეუძლია პორტის გახსნა, ოპერატორის NAT-ის გავლა ან მოქმედი WireGuard სესიისთვის იმის შეგრძნობა, რომ მისი ბოლო წერტილი შეიცვალა. სამი პირობა წყვეტს, დინამიკური DNS მთელი გადაწყვეტაა თუ მხოლოდ მისი ერთი ხაზი.

პირველი პირობა: თქვენი მისამართი ნამდვილად იძვრება

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

გაზომეთ და ნუ გამოიცნობთ. წაიკითხეთ WAN მისამართი როუტერის სტატუსის გვერდზე, შემდეგ შეადარეთ იმას, რასაც გარე სამყარო ხედავს. გაუშვით ეს LAN-ის მანქანიდან:

curl -fsS https://api.ipify.org; echo

თუ ორი მნიშვნელობა განსხვავდება, რაღაც თქვენი როუტერის წინ თარგმნის და არც ერთი ჰოსტის სახელის განახლება ამას არ გამოასწორებს. 100.64.0.0/10-ის შიგნით მდებარე მისამართი ოპერატორის დონის NAT-ის საერთო დიაპაზონია და ეს არის ჩვეულებრივი მიზეზი იმისა, რომ სწორად განახლებული სახელი გარედან მაინც დროის ამოწურვას იწვევს.

მეორე პირობა: კლიენტები სახელს ხელახლა ეძებენ

მოკლე TTL არის ის ნაწილი, რომელსაც ხალხი გამოტოვებს. რეკურსიული გადამწყვეტები ჩანაწერის TTL-ს პატივს სცემენ, მაგრამ კლიენტის სტეკები ცალკე ქეშირებს და უკვე აწეული გვირაბი არაფერს ხელახლა არ წყვეტს. გამართვის დროს ჩანაწერი დააყენეთ 60-300 წამზე; ეს ამცირებს ფანჯარას, როცა მოძველებული პასუხი მიეწოდება და დაკავშირებულ სესიას არ გადააადგილებს.

OpenVPN ყოველ ხელახალ დაკავშირებაზე ხელახლა წყვეტს ხაზს remote vpn.example.net 1194 და resolv-retry infinite აიძულებს განაგრძოს ცდა გასვლის ნაცვლად, როცა ძებნა ვერ ხერხდება. სერვერზე float დამკვიდრებულ სესიას აძლევს საშუალებას მიჰყვეს პარტნიორს, რომლის წყაროს მისამართიც შეიცვალა. WireGuard უფრო პირდაპირია: wg-quick up კონფიგურაციის გამოყენებისას წყვეტს Endpoint ბოლო წერტილს და კლიენტი ხელახლა წყვეტს მას, როცა გვირაბს ხელახლა აშენებს, ამიტომ ძველი მისამართის მიმართ ჯერ კიდევ წარმატებული ხელის ჩამორთმევა წარმატებული რჩება, სანამ არ შეწყდება.

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

მესამე პირობა: შიგნით შესვლის გზა ჯერ კიდევ ღიაა

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

გამოსცადეთ გარედან. ტელეფონი მობილურ მონაცემებზე გამორთული Wi-Fi-ით ყველაზე იაფი პატიოსანი ტესტია; იმავე LAN-ის ლეპტოპი — არა. როცა სახელი თქვენს საჯარო მისამართზე წყდება და როუტერს NAT-ის მარყუჟი არ აქვს, შიდა ტესტი იშლება, თუმცა ჩანაწერი სრულიად სწორია, და სწორედ ეს აგზავნის უმეტესობას იმ ჩანაწერის რედაქტირებაზე, რომელიც არასდროს ყოფილა არასწორი.

რა გაუშვათ, როცა სამივე სრულდება

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

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

გაუშვით ის systemd ტაიმერიდან რამდენიმე წუთში ერთხელ და არა shell ციკლიდან, და ჩაწერეთ პროვაიდერის პასუხი ჟურნალში, ნაცვლად წარმატების ვარაუდისა. მოეპყარით სერტიფიკატს როგორც გასაღებს, რადგან ის წყვეტს, სად იგზავნება ყოველი კლიენტი: გამოიყენეთ შეზღუდული განახლების ტოკენი ანგარიშის პაროლის ნაცვლად, შეინახეთ ფაილი 0600 რეჟიმში და განახლებები გაგზავნეთ HTTPS-ით.

გადაამოწმეთ, სანამ ვალდებულებას აიღებთ

ერთი მოძიება გეტყვით, რას ხედავს დანარჩენი მსოფლიო და დაბეჭდავს იმ TTL-ს, რომელიც ცვლილების შემდეგ უნდა მოიცადოთ:

dig +noall +answer vpn.example.net @1.1.1.1

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

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

როცა პასუხი არის არა

თუ პირველი ან მესამე პირობა იშლება, იცვლება გადაწყვეტილება და არა კონფიგურაცია. ოპერატორის NAT-ის მიღმა თქვენი პრაქტიკული არჩევანია პროვაიდერისგან საჯარო მისამართის თხოვნა, შესვლის წერტილის სტაბილური მისამართის მქონე პატარა VPS-ზე გადატანა, ან ისეთი გადაფარვის გამოყენება, რომელიც საკუთარ შეხვედრას ინახავს. თუ მისამართი სტატიკურია, გამოტოვეთ განახლების პროგრამა: ერთი A ჩანაწერი, ერთი AAAA ჩანაწერი, თუ IPv6-ს იყენებთ, იგივე პორტის გადამისამართება.

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

სანამ გააგრძელებთ, თანმიმდევრობით დაადასტურეთ ოთხი რამ:

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

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