Pi-hole VPN-ის დაკავშირების შემდეგ რეკლამებს არ ბლოკავს: ხუთი შემოწმება

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

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

ჰკითხეთ კლიენტს და არა როუტერს. Linux-ზე resolvectl status ბეჭდავს DNS სერვერებს თითოეული ბმულისთვის და იმას, თუ რომელი ბმული იმარჯვებს; /etc/resolv.conf თავისთავად ჩვეულებრივ stub-ია, რომელიც 127.0.0.53-ზე მიუთითებს. Windows-ზე ipconfig /all ჩამოთვლის DHCP-ის მიერ მოწოდებულ სერვერებს თითოეული ადაპტერისთვის, ხოლო macOS-ზე scutil --dns იგივეს აჩვენებს სფეროების მიხედვით. თუ პასუხი Pi-hole-ის მისამართი არ არის, თქვენ გაქვთ მიკუთვნების პრობლემა და საფეხური 2 არის ის ადგილი, სადაც ის ბინადრობს.

ორი რამ ამარცხებს სისტემის რეზოლვერს მაშინაც, როცა ის სწორად არის დაყენებული. ბრაუზერები საკუთარი უსაფრთხო DNS-ით (Chrome-ის “Use secure DNS” პარამეტრი, Firefox-ის network.trr.mode) კითხვებს HTTPS-ის გავლით აგზავნიან საჯარო რეზოლვერთან და არასოდეს ხსნიან პორტს 53. და თავად კლიენტზე მყოფმა VPN კლიენტმა შეიძლება დააყენოს DNS სერვერი თავის გვირაბის ინტერფეისზე ~. მარშრუტიზაციის დომენით, რაც ამ ბმულს ყველა სახელისთვის ავტორიტეტულს ხდის.

შეამოწმეთ ის გზა, რომელსაც აპლიკაციები გადიან და არა ის, რომელსაც გამართვის ხელსაწყო გადის. resolvectl query example.com გვიჩვენებს, თუ რომელმა ბმულმა უპასუხა, და getent hosts example.com გადის იმავე NSS გზას, რომელსაც აპლიკაცია გადის; macOS-ზე dscacheutil -q host -a name example.com კითხულობს იმ სფეროებრივ რეზოლვერებს, რომლებსაც scutil --dns ჩამოთვლის. შიშველი dig ამას არ აკეთებს: ის კითხულობს /etc/resolv.conf-ს და გამოტოვებს ბმულის მიხედვით არჩევანს, ამიტომ შეიძლება Pi-hole-იდან უპასუხოს, სანამ ყველა აპლიკაცია გაგზავნილ რეზოლვერს იყენებს, და ეს არის ზუსტად ის ხარვეზი, რომლისთვისაც ეს სია არსებობს. შეინახეთ dig @192.168.1.53 ერთი კონკრეტული სერვერის შესამოწმებლად.

2. დაადასტურეთ, ვინ ანაწილებს პასუხს

მიკუთვნება მოდის იმისგან, რაც DHCP-ს პასუხობს. dnsmasq-ში ეს ერთი სტრიქონია, dhcp-option=6,192.168.1.53; როუტერის ვებ ინტერფეისში ეს არის DNS ველი LAN DHCP განყოფილებაში. კლიენტებმა უნდა განაახლონ სანამ დაინახავენ. დღეების განმავლობაში ჩართული მოწყობილობა ჯერ კიდევ ძველ იჯარას ინახავს, ხოლო ხელით აკრეფილი რეზოლვერის მქონე მოწყობილობა მას სამუდამოდ ინახავს. განაახლეთ სატესტო კლიენტზე, ნაცვლად იმისა, რომ გავრცელება ჩათვალოთ მოცემულობად.

IPv6 არის ის ნახევარი, რომელიც გამორჩება. როუტერის რეკლამებს შეიძლება ჰქონდეს საკუთარი DNS სერვერი (RDNSS), და OpenWrt-ზე ეს არის odhcpd-ის ra_dns პარამეტრი; კლიენტი, რომელიც IPv6-ს ანიჭებს უპირატესობას, იყენებს ამ სერვერს, სანამ ახლახან დაყენებული DHCPv4 პარამეტრი უგამოყენებელი რჩება. თუ მზად არ ხართ IPv6-ზე DNS-ის მოსამსახურებლად, წაშალეთ მხოლოდ DNS რეკლამა: ra_dns odhcpd-ში, ან RDNSS პარამეტრი იმაში, რაც როუტერის რეკლამებს პასუხობს. მთელი რეკლამის გამორთვა LAN-იდან IPv6 მისამართებსაც აშორებს, რაც გაცილებით დიდი ცვლილებაა, ვიდრე განზრახული გქონდათ, მაშინ როცა მხოლოდ DNS პარამეტრის წაშლა მისამართებს ხელუხლებლად ტოვებს და დაკარგულ RDNSS-ს პაკეტების ჩაჭერაში თვალსაჩინოს ხდის.

3. დაამტკიცეთ, რომ კითხვა Pi-hole-ს აღწევს

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

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

დროის ამოწურვა მიუთითებს ფილტრაციაზე ან მარშრუტზე; REFUSED მიუთითებს წვდომის წესზე; SERVFAIL მიუთითებს Pi-hole-ის უკან მდგომ ზედა რეზოლვერზე; სწორი პასუხი, რომელიც არასოდეს ჩნდება კითხვების ჟურნალში, ნიშნავს, რომ კლიენტმა სხვა რამ იკითხა. შეამოწმეთ UDP და TCP 53, რადგან დიდი პასუხები და ზოგიერთი რეზოლვერი TCP-ზე ბრუნდება, და გამოაქვეყნეთ ორივე, როცა Pi-hole კონტეინერში მუშაობს. მხოლოდ UDP-ის დამფარავი რუკა წარმოქმნის წყვეტილ ხარვეზებს, რომლებიც პაკეტების დაკარგვას ჰგავს.

შემდეგ Pi-hole-ის მოსმენის რეჟიმი წყვეტს, საერთოდ პასუხობს თუ არა. მხოლოდ ლოკალურ რეჟიმში dnsmasq უგულებელყოფს წყაროების კითხვებს, რომლებიც უშუალოდ დაკავშირებულ ქვექსელზე არ არიან, და ზუსტად ასე გამოიყურება სხვა როუტერის უკან მყოფი ან გვირაბით მომავალი კლიენტი: კლიენტს დრო ეწურება და კითხვა ჟურნალს არასოდეს აღწევს. კითხვა, რომელიც მაინც REFUSED-ად ჩნდება, წვდომის სიამ ან firewall-ის წესმა უარყო. ყველა წყაროს დაშვება ჩვეულებრივი გამოსწორებაა, ერთად firewall-ის წესთან, რომელიც პორტ 53-ს თქვენს საკუთარ ქვექსელებზე ზღუდავს.

4. შეამოწმეთ, გვირაბმა პასუხი შეცვალა თუ გადაყლაპა

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

მეორე ხარვეზი ხელმისაწვდომობაა და არა ჩანაცვლება. თუ გვირაბის დაშვებული პრეფიქსები მოიცავს თქვენს LAN ქვექსელს, როუტერს აქვს მარშრუტი, რომელიც 192.168.1.53-ის კითხვებს გვირაბში აგზავნის, და მეორე მხარეს უკან დაბრუნების მარშრუტი არ აქვს: კითხვებს დრო ეწურება, თუმცა გვირაბი ჯანმრთელია. საპირისპირო ხდება მაშინ, როცა Pi-hole იმ ქვექსელში ზის, რომელსაც გვირაბი არ ატარებს. შეადარეთ მისამართი გვირაბის დაშვებულ პრეფიქსებს და როუტერის მარშრუტების ცხრილს, სანამ კვლავ შეეხებით DNS-ს.

აირჩიეთ ერთი გამოსწორება და არა ორივე. ან გვირაბი მოაშორეთ DNS-ს — OpenVPN-ზე pull-filter ignore “dhcp-option DNS” და WireGuard-ზე AllowedIPs-ში LAN პრეფიქსის გარეშე —, ან მიიღეთ გაგზავნილი რეზოლვერი და უარი თქვით ლოკალურ ფილტრაციაზე იმ როუტერის უკან მყოფი კლიენტებისთვის. რასაც აირჩევთ, დაწერეთ ის პროფილის გვერდით, რადგან შემდეგი ადამიანი, ვინც მას შეცვლის, სხვა შემთხვევაში შემთხვევით შეაბრუნებს გადაწყვეტილებას.

5. გაიმეორეთ ტესტი ხელახალი დაკავშირების შემდეგ

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

დატოვეთ მეორადი რეზოლვერის გზა, რომელიც გვირაბზე არ არის დამოკიდებული, რათა Pi-hole-ის გათიშვა გადაიზარდოს უფილტრავ დათვალიერებაში და არა დათვალიერების სრულ არარსებობაში. შეინახეთ წინა DHCP და რეზოლვერის მნიშვნელობები, სანამ ტესტი ორჯერ არ გაივლის; ცვლილება, რომელიც ვახშმის დროს არღვევს სახლის ინტერნეტს, ბევრად უფრო რთული გასამართია, ვიდრე ის, რომლის უკან დაბრუნებაც ერთ წუთში შეგიძლიათ.