OpenVPN კლიენტების მიმართვა სხვა ჰოსტზე მყარ Pi-hole რეზოლვერზე

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

რას აკეთებს და რას არ აკეთებს გაგზავნილი DNS პარამეტრი

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

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

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

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

დაბრუნების გზა Pi-hole-დან პულამდე

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

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

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

Pi-hole-ის მოსმენის რეჟიმი მარშრუტიზებული კლიენტებისთვის

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

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

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

შეუსაბამეთ პასუხი მოთხოვნების ჟურნალს

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

resolvectl query intranet.example.lan
resolvectl dns

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

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

შეამოწმეთ კარიბჭის გადამისამართების წესი

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

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

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

რომელი ხელსაწყოც არ უნდა გამოიყენოს ჰოსტმა, შემოწმება ვიწროდ შეინახეთ: პული როგორც წყარო, 53 პორტი როგორც დანიშნულება და Pi-hole როგორც ერთადერთი ნებადართული სამიზნე. ფართო გადამისამართების წესი, რომელიც 80 პორტსაც უშვებს, სხვა პრობლემაა, რომელიც მოხდომას ელოდება.