რატომ უგულებელყოფს Pi-hole v6 WireGuard-ის კლიენტების DNS მოთხოვნებს

Pi-hole v6 იღებს DNS მოთხოვნას 53 პორტზე და შემდეგ წყვეტს, დასაშვებია თუ არა მოსული პაკეტის პასუხი. WireGuard ჰოსტზე სწორედ ეს მეორე გადაწყვეტილებაა ჩვეულებრივ მიზეზი იმისა, რომ კლიენტი დროის ამოწურვას იღებს, მაშინ როცა რეზოლვერი LAN-იდან ჯანსაღად გამოიყურება. პორტი ღიაა, FTL მუშაობს, მაგრამ მაინც არაფერი ბრუნდება 10.90.0.1-დან. სამი რამ ურთიერთქმედებს, სანამ პასუხი გავა: dns.interface, dns.listeningMode და ორივეს წინ მდგარი ფაირვოლი.

მოსმენის სოკეტი არ წყვეტს, ვინ მიიღებს პასუხს

FTL ხსნის UDP და TCP მსმენელებს 53 პორტზე. ნაგულისხმევ კონფიგურაციაში სოკეტი ხშირად wildcard-ია, ამიტომ ss -lunp | grep :53 აჩვენებს 0.0.0.0:53 და [::]:53 მისამართებს, მიუხედავად იმისა, ემსახურება თუ არა VPN კლიენტებს. wildcard სოკეტი იღებს პაკეტს, შემდეგ FTL პასუხამდე იყენებს თავის ინტერფეისისა და წყაროს წესებს. ამიტომ ფრაზა „პორტი ისმენს“ ძალიან ცოტას ამტკიცებს გვირაბის კლიენტზე.

წაიკითხეთ მოქმედი კონფიგურაცია და არა ის ფაილი, რომელიც გგონიათ აქტიურად. pihole-FTL --config dns.interface და pihole-FTL --config dns.listeningMode ბეჭდავს ფაქტობრივ მნიშვნელობებს და ისინი შეიძლება განსხვავდებოდეს ჰოსტის ფაილისგან, როცა კონტეინერი, გარემოს ცვლადი ან განლაგების მენეჯერი ფლობს ამ პარამეტრს. Pi-hole FTL-ის კონფიგურაციის ცნობარი ჩამოთვლის რეჟიმებს და იმას, თუ რომელი მათგანი ეყრდნობა ინტერფეისს.

LOCAL კითხულობს რომელი ქვექსელი, SINGLE კითხულობს რომელი ინტერფეისი

LOCAL, ნაგულისხმევი, პასუხობს მოთხოვნებს, რომელთა წყაროს მისამართი ეკუთვნის ჰოსტის ერთ-ერთ ინტერფეისზე კონფიგურირებულ ქვექსელს. მარტივი wg0 10.90.0.1/24-ით გადის ამ ტესტს, რადგან 10.90.0.2-ზე მყოფი კლიენტი გვირაბის ქვექსელშია. მარშრუტიზებული კლიენტი პირის მეორე მხარეს, ან სხვა პრეფიქსში NAT-ის უკან დამალული კლიენტი, ვერ გადის მას, თუმცა პაკეტი wg0-ზე მოვიდა, და ჟურნალში არც ერთი მოთხოვნა არ ჩნდება.

SINGLE ცვლის კითხვას. ის იღებს მოთხოვნებს, რომლებიც მოდის dns.interface-ში დასახელებულ ინტერფეისზე, loopback-ის ჩათვლით, და უგულებელყოფს წყაროს ქვექსელს. სწორედ ეს რეჟიმი უძლებს ჯაჭვურ ან მარშრუტიზებულ VPN ტოპოლოგიას. დააყენეთ ორივე გასაღები ერთად, რადგან რეჟიმი დასახელებული ინტერფეისის გარეშე სრულყოფილი ინსტრუქცია არ არის:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND ცვლის სოკეტს და ამას ფასი აქვს

BIND არ ფილტრავს wildcard სოკეტს; ის 53 პორტს აკავშირებს მხოლოდ იმ მისამართებზე, რომლებიც დასახელებულ ინტერფეისზე არსებობს, ამიტომ ბირთვი უარყოფს სხვაგან მოსულ პაკეტებს. ის SINGLE-ზე მკაცრია და მისი სინონიმი არ არის. ფასი ჩატვირთვისას ჩნდება: თუ wg0 არ არის აწეული, როცა FTL იწყებს, შეიძლება დასაკავშირებელი მისამართი არ იყოს და რეზოლვერმა მსმენელის გარეშე იმუშაოს, სანამ ინტერფეისი გამოჩნდება და FTL ხელახლა ჩაიტვირთება.

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

ფაირვოლი მეორე კარიბჭეა

სწორი FTL რეჟიმიც კარგავს, თუ ჰოსტის ფაირვოლი 53 პორტს გადააგდებს wg0-ზე. დაუშვით VPN წყაროს დიაპაზონი ორივე პროტოკოლისთვის და ინტერნეტის მხარე დახურული დატოვეთ. nftables-ში, inet filter ცხრილის არსებული input ჯაჭვით, წესები ასე გამოიყურება:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

დაამატეთ შესაბამისი IPv6 წესები, თუ გვირაბი IPv6-ს ატარებს, და მოათავსეთ ისინი ჯაჭვის drop პოლიტიკამდე. თუ ჰოსტი იყენებს ufw-ს ან firewalld-ს, გამოხატეთ იგივე დამთხვევა იმ მენეჯერში ხელსაწყოების შერევის ნაცვლად. ნუ გადაამისამართებთ 53 პორტს ინტერნეტის მარშრუტიზატორიდან; კლიენტებმა რეზოლვერის VPN მისამართს გვირაბით უნდა მიაღწიონ.

ორი გზა განცალკევებული რჩება. კლიენტების მოთხოვნები FTL-ზე მთავრდება. FTL-ის საკუთარი ზედა დინების ძიებები გადის ჰოსტის მარშრუტიზაციის ცხრილის მიხედვით, რომელმაც შეიძლება გამოიყენოს გვირაბი ან არ გამოიყენოს, ამიტომ რეზოლვერი, რომელიც პასუხობს, მაგრამ სასარგებლო არაფერს აბრუნებს, ზედა დინების პრობლემაა. ვებ ადმინი და API საკუთარ პორტებზე ისმენენ და საკუთარი შეზღუდვა სჭირდებათ.

გადაამოწმეთ პასუხი და უარი

VPN კლიენტიდან ჰკითხეთ რეზოლვერის მისამართს ორივე პროტოკოლით: dig @10.90.0.1 example.com და dig +tcp @10.90.0.1 example.com. შემდეგ შეამოწმეთ მოთხოვნების ჟურნალი ადმინის ინტერფეისში, რომ FTL-მა მოთხოვნა ჩაწერა. კლიენტის დროის ამოწურვა ჟურნალში ჩანაწერის გარეშე ფაირვოლზე ან ინტერფეისის ფილტრზე მიუთითებს; ჩანაწერი პასუხის გარეშე ზედა დინების ამოხსნაზე მიუთითებს.

შეამოწმეთ უარყოფითი გზა VPN-ის გარეთ მყოფი ჰოსტიდან. dig @10.90.0.1 example.com უნდა ამოიწუროს, და ss -lunp რეზოლვერზე არ უნდა აჩვენებდეს 53 პორტს საჯარო მისამართზე მიბმულს. გადატვირთეთ სერვისი ერთხელ, შემდეგ გადატვირთეთ ჰოსტი და დაადასტურეთ, რომ რეზოლვერი კვლავ პასუხობს, როცა wg0 კვლავ გამოჩნდება. მოთხოვნა, რომელიც მხოლოდ შემდეგ გადატვირთვამდე მუშაობს, დასრულებული ცვლილება არ არის.