WireGuard არ აგზავნის DNS-ს: კერძო BIND ზონის მომსახურება

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

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

გვირაბი და რეზოლვერი ცალკეული ხელშეკრულებებია

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

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

მოემსახურეთ ზონას რეკურსიულ რეზოლვერად ქცევის გარეშე

სერვერის მხარე პატარა ავტორიტეტული ზონაა, და არა ზოგადი რეზოლვერი. ამ მაგალითში კარიბჭეა 10.90.0.1, კლიენტებია 10.90.0.0/24, და აპლიკაცია, რომელიც გაინტერესებთ, პასუხობს 10.60.0.20-ზე.

გააერთიანეთ ეს პარამეტრები არსებულ options ბლოკში და ნუ შექმნით მეორეს:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

შემდეგ გამოაცხადეთ ზონა და მისი ფაილი:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

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

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

გახსენით UDP და TCP 53 მხოლოდ VPN ინტერფეისზე. კერძო ავტორიტეტის საჯარო ინტერფეისზე გამოქვეყნება იწვევს როგორც შეკითხვებს, ისე ჩამოთვლას, და allow-transfer უნდა დარჩეს დახურული, თუ მეორადს ნამდვილად არ სჭირდება.

მიმართეთ კლიენტი მისკენ, თითოეული ბმულისთვის

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

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

ტილდა მთავარი სიმბოლოა. ის დომენს მხოლოდ-მარშრუტად აღნიშნავს: corp.example-ის ქვეშ არსებული სახელები ამ ბმულის DNS სერვერზე მიდიან და დომენი მოკლე სახელის საძიებო სუფიქსად არ ემატება. მის გარეშე portal-ის აკრეფა იწყებს portal.corp.example-ის გადაწყვეტას, რაც თქვენთვის მოხერხებულია და ყველა სხვისთვის გასაკვირი. შეინახეთ ტილდა ბრჭყალებში, რადგან ბრჭყალების გარეშე ის shell-ის გაფართოებაა, რომელიც ელოდება სახლის კატალოგზე მითითებას.

გამოიყენეთ ცვლილება ინტერფეისის მფლობელი მენეჯერის მეშვეობით, შემდეგ ხელახლა დაუკავშირდით კავშირს. ნუ გაუშვებთ wg-quick-ის მეორე ეგზემპლარს იმავე ინტერფეისისთვის; ორი მფლობელი მარშრუტებისთვის იჩხუბებს და ერთი მათგანი ყველაზე ცუდ მომენტში გაიმარჯვებს.

გადაამოწმეთ გზა სახელამდე

ჰკითხეთ სახელი კლიენტს და დაადასტურეთ როგორც პასუხი, ისე სერვერი, რომელმაც ის შექმნა:

resolvectl query portal.corp.example

თუ ეს 10.60.0.20-ს აბრუნებს, DNS ხელშეკრულება შესრულებულია. თუ დრო იწურება, ჯერ შეამოწმეთ მარშრუტი 10.90.0.1-მდე, შემდეგ ცეცხლოვანი კედლის წესი, შემდეგ allow-query სერვერზე. სახელების გადაწყვეტის წარუმატებლობები ამ კონფიგურაციაში თითქმის ყოველთვის ხელმისაწვდომობა ან ACL-ია, არა ზონის ფაილი. იმუშავეთ კლიენტიდან გარეთკენ, რადგან სერვერს არ შეუძლია გითხრათ, რატომ არასდროს მივიდა შეკითხვა.

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

რა ჯერ კიდევ არ არის ავტომატური

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

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

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

დაკავშირებული სტატიები