Pi-hole და VPN ერთ Pi-ზე: მხარდაჭერილია თუ არა ოპერაციული სისტემა ჯერ კიდევ?

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

მხარდაჭერას გამოშვების ტოტი განსაზღვრავს და არა ოჯახის სახელი

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

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

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

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

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

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

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

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

ერთი ყუთი, ორი სერვისი, ქსელის ერთი მფლობელი

გადაწყვიტეთ, ვის ეკუთვნის მისამართება, გამხსნელი და გვირაბი, სანამ პირველი პაკეტი ავა, თორემ ორი სერვისი ერთსა და იმავე ვალდებულებას მოითხოვს და არც ერთი არ მოიგებს სუფთად. მიეცით Pi-ს სტატიკური მისამართი თქვენი როუტერის მიერ გაცემული DHCP აუზის გარეთ და გვირაბი შეინახეთ მის საკუთარ ქვექსელში: 192.168.50.10 Pi-სთვის და 10.42.0.0/24 გვირაბისთვის ერთი სამუშაო დაყოფაა, და თავად რიცხვები თვითნებურია, სანამ ისინი არ ეჯახება იმას, რასაც თქვენი როუტერი უკვე ემსახურება. შემდეგ ჩაწერეთ, რომელი კომპონენტი პასუხობს 53 პორტზე, რომელი ანაწილებს DHCP-ს თუ იყენებთ, და რომელს ეკუთვნის ნაგულისხმევი მარშრუტი, სანამ გვირაბი აწეულია. ეკრანის გარეშე იმიჯზე ეს უკანასკნელი საქმე NetworkManager-ს ან systemd-networkd-ს ეკუთვნის, და პროვაიდერის კლიენტის დაყენება, რომელიც გამხსნელის კონფიგურაციასაც გადაწერს ის გზაა, რომლითაც ხალხი ცოცხალ გვირაბსა და მკვდარ DNS-თან მიდის.

ყუთის გაზიარება ნორმალურია. როლის გაზიარება არა. Pi-hole 53 პორტის ერთადერთი მსმენელი უნდა იყოს, VPN დემონს კი საკუთარი DNS პარამეტრის კლიენტებთან გაგზავნა სურს, ამიტომ აირჩიეთ, რომელ ორიდან უნდა ენდონ კლიენტები, და მეორე ისე დააყენეთ, რომ გზიდან გვერდზე გადგეს.

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

შემდეგი განახლება არჩევნის ნაწილად აქციეთ

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

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

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

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

როცა არც ერთი გამოშვება არ ერგება ორივე სერვისს

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

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

თუ ორი მიმდინარე გამოშვება ყველაფერს აკმაყოფილებს, აირჩიეთ ის, რომლის განახლების ჩანაწერებსაც გამოცნობის გარეშე მიჰყვებით, და შეწყვიტეთ ძებნა. შემდეგ ჩაწერეთ ვერსია, არქიტექტურა, სერვისების მფლობელები და აღდგენის ნაბიჯი ერთ ადგილას, რადგან SD ბარათს შემდეგ შემხები ადამიანს ოთხივე დასჭირდება.