Pi ჰოტსპოტი Pi-hole-ითა და VPN-ით: მიანიჭეთ თითოეულ სერვისს საკუთარი საქმე
გადაწყვიტეთ, ვინ ფლობს DHCP-ს, DNS-სა და პაკეტების გადაგზავნას, სანამ ერთ Pi-ზე სამ დამხმარეს ჩართავთ. დუბლირებული მფლობელები ქმნიან კონკურენტულ იჯარებსა და resolver-ის ციკლებს.
ტელეფონი ერთვება Pi-ის ჰოტსპოტზე, იღებს მისამართს, გვერდი კი მაინც არ იხსნება. Pi აშვებს ჰოტსპოტის დამხმარეს, Pi-hole-სა და VPN კლიენტს, და თითოეულ მათგანს სჯერა, რომ გზის ნაწილს ფლობს. ამ აწყობების უმეტესობა იმიტომ არ ფუჭდება, რომ კომპონენტი გაფუჭდა, არამედ იმიტომ, რომ ორი კომპონენტი ერთსა და იმავე საქმეს აკეთებს. დანიშნეთ ერთი მფლობელი თითოეულ ფუნქციაზე, სანამ რომელიმეს დააკონფიგურირებთ.
დანიშნეთ ერთი მფლობელი თითოეულ ფუნქციაზე
აქ ოთხი ფუნქციაა მნიშვნელოვანი და თითოეულს ზუსტად ერთი მფლობელი სჭირიალებს. ქვემოთ მოცემულ ცხრილში მითითებულია ფუნქცია, სამუშაო მფლობელი და ის, რაც იფუჭება, როცა ორი სერვისი მას ითვისებს.
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
გადაფარვა ჩვეულებრივ ერთი პაკეტით მოდის. ჰოტსპოტის დამხმარე საკუთარ dnsmasq-ის ეგზემპლარს აყენებს, Pi-hole-ს 53 პორტი სჭირდება, VPN კლიენტი კი მარშრუტებს ამატებს. თითოეული ნაბიჯი ცალკე გონივრული ჩანს, ერთად კი ქმნიან მანქანას, სადაც მეორე გაშვებული სერვისი ჩუმად ცვლის პირველის ქცევას.
ჩაწერეთ მფლობელები, სანამ სხვა რამეს ჩართავთ. აწყობის ჩანაწერებში მოკლე ცხრილი ხელს უშლის გვიანდელ ინსტალაციას ხელში ჩაიგდოს ფუნქცია, რომელსაც უკვე ჰყავდა მფლობელი.
აირჩიეთ ერთი დიაპაზონი და შეინახეთ ის გვირაბისგან მოშორებით
აირჩიეთ ჰოტსპოტის დიაპაზონი, მასში Pi-ის მისამართი, DHCP პული და resolver, რომელსაც კლიენტები იღებენ. შეინახეთ ეს დიაპაზონი გამიჯნული ზედა LAN-ისა და VPN გვირაბის დიაპაზონისგან, რადგან გადამფარავი ქვექსელები მარშრუტიზაციის პრობლემას მისამართების თარგმნის პროექტად აქცევს. გვირაბთან გადამფარავი დიაპაზონი Pi-ს ორ იდენტურ პრეფიქსს შორის შემთხვევით როუტერად აქცევს. ჩაწერეთ დიაპაზონი და პული ჰოტსპოტის კონფიგურაციაში ნაგულისხმევ მნიშვნელობაზე დატოვების ნაცვლად.
თუ ჰოტსპოტს NetworkManager-ის გაზიარებული რეჟიმი ფლობს, DHCP სერვერის დამატებამდე შეამოწმეთ ეფექტური კავშირი. გაზიარებული რეჟიმი საკუთარ დამხმარეებს უშვებს და გადაგზავნას რთავს, ამიტომ ის უკვე ამ ინტერფეისის მისამართების გეგმის მფლობელია. მეორე სერვერის დამატება მხოლოდ იმიტომ, რომ ხელმისაწვდომია, ქმნის კონკურენტულ შეთავაზებებს და არა რეზერვს.
IPv6-ზე გადაწყვეტილება გააცნობიერებლად მიიღეთ. როუტერის განცხადებები და DHCPv6 ბევრ კონფიგურაციაში DHCPv4-ისგან განსხვავებული დამხმარესგან მოდის, ხოლო IPv6-ის ჩართული დატოვება, სანამ VPN პოლიტიკა მხოლოდ IPv4-ს ფარავს, კლიენტებს გვირაბის გვერდის ავლით მიმავალ გზას აძლევს. ან დაგეგმეთ IPv6 მხარე, ან გამორთეთ ის ჰოტსპოტის ინტერფეისზე წერილობითი მიზეზით.
ვინ პასუხობს რეალურად 53 პორტზე
სანამ კონფიგურაციას შეიცვლით, ჩამოთვალეთ ყველა პროცესი, რომელიც 53 პორტს უსმენს. Pi-ზე, რომელიც აშვებს ლოკალურ resolver stub-ს, Pi-hole-სა და გაზიარების დამხმარეს, მსმენელების სია ერთადერთი სანდო რუკაა იმისა, თუ ვინ პასუხობს მოთხოვნებს:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-hole-ის ინტერფეისების სახელმძღვანელო განმარტავს, რომ ერთ ინტერფეისზე შეზღუდული მიღების რეჟიმი მაინც შეიძლება იყენებდეს wildcard სოკეტს და სხვაგან მოსული პაკეტები გადააგდოს. ეს არ არის იგივე, რაც მხოლოდ არჩეულ ინტერფეისებზე მიბმა, რაც იმ შემთხვევისთვისაა განკუთვნილი, როცა მანქანა სხვა DNS სერვისმა უნდა გაიზიაროს.
ორი პროცესი ჩვეულებრივ ერთსა და იმავე მისამართზე და პორტზე ვერ მიბმულდება, თუმცა SO_REUSEPORT-ს შეუძლია გაზიარებული მიბმა წარმატებული გახადოს; მაშინაც კი wildcard მსმენელს შეუძლია წაიღოს ვიწრო სერვისისთვის განკუთვნილი მოსვლები. აირჩიეთ დოკუმენტირებული რეჟიმი სასურველი როლისთვის და გადატვირთეთ სერვისები დანიშნული თანმიმდევრობით.
შეინახეთ Pi-hole-ის ადმინისტრირების გვერდი ჰოტსპოტის ქსელის გარეთ. კლიენტებს resolver სჭირდებათ და არა ვებ ინტერფეისი ან API, რომელსაც resolver-ის კონფიგურაციის შეცვლა შეუძლია.
ორი DNS ფეხი, თითოეულს საკუთარი პოლიტიკა
კლიენტის მოთხოვნა ტელეფონიდან Pi-ზე მიდის, ხოლო ცალკე მოთხოვნა Pi-დან მის ზედა resolver-ზე მიდის. მარშრუტიზაციის წესი, რომელიც გადაგზავნილ ჰოტსპოტის ტრაფიკს ემთხვევა, მეორე ფეხზე ავტომატურად არ ვრცელდება, რადგან Pi ამ ტრაფიკს ლოკალურად აწარმოებს. თუ VPN-მა DNS უნდა გადაიტანოს, ლოკალურ გზას საკუთარი პოლიტიკა სჭირდება.
ყურადღება მიაქციეთ ციკლს. Pi-hole-ის ზედა resolver-ის მიმართვა იმ მისამართზე, რომელსაც თავად Pi ემსახურება, პირდაპირ ან პორტის გადამისამართებით, ქმნის მოთხოვნებს, რომლებიც ტრიალებენ, სანამ ვადა არ გაუვათ. მიეცით მას რეალური ზედა resolver ან პირობითი forwarder იმ დომენებისთვის, რომლებზეც ვერ პასუხობს.
გადაწყვიტეთ, რა მოხდება, როცა გვირაბი ჩავარდება. ლოკალურ resolver-ზე დაბრუნება ბრაუზინგს ცოცხლად ინარჩუნებს, მაგრამ შეიძლება სახელები VPN-ის გარეთ გაჟონოს; დაბლოკვა პოლიტიკას უცვლელად ინარჩუნებს და შეფერხებას ხილულ შეცდომად აქცევს. ორივე არჩევანი დასაცავია, მაგრამ ის უნდა აირჩიოთ და არა მემკვიდრეობით მიიღოთ ნაგულისხმევი მნიშვნელობიდან.
დაამტკიცეთ გზა და ქცევა შეფერხებისას
ტესტეთ ფენებად: კლიენტი იღებს მისამართს, კლიენტი სახელს Pi-ის მეშვეობით წყვეტს, Pi დანიშნული ზედა resolver-ის მეშვეობით წყვეტს და აპლიკაცია მოთხოვნას ასრულებს. წარმატებული ping DNS-ზე არაფერს ამბობს, ხოლო წარმატებული ძიება გადაგზავნაზე არაფერს ამბობს.
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1შემდეგ გააჩერეთ გვირაბი და გაიმეორეთ. დანიშნული ქცევა რამდენიმე წამში უნდა გამოჩნდეს და არა Pi-hole-ის ან ჰოტსპოტის სერვისის ხელით გადატვირთვის შემდეგ. შეფერხების დროს შეამოწმეთ კლიენტის resolver-ის პარამეტრი, რადგან მეორადი საჯარო resolver გააგრძელებს პასუხს, მაშინაც კი, როცა პოლიტიკა შეცდომას ელოდა.
შეინახეთ ერთი მფლობელი გადაგზავნისა და NAT-ისთვის და შეამოწმეთ ის კლიენტიდან და არა თავად Pi-დან. მოთხოვნა, რომელიც წარმატებით ტოვებს Pi-ს, შეიძლება მაინც ჩამოვარდეს უკანა გზაზე, და კლიენტი ერთადერთი ადგილია, სადაც მთელი გზა ჩანს.