AdGuard Home პასუხობს WireGuard კლიენტებს თქვენი ლოკალური ქსელის მისამართიდან

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

მოთხოვნა ცენტრალიზდება, პასუხი გადის სხვაგანიდან

კლიენტი, რომელიც კონფიგურირებულია 10.6.0.1 როგორც მის რეზოლვერს, უგზავნის UDP შეკითხვის 10.6.0.1 პორტ 53-ზე. ეს პაკეტი გადის ტუნელში და უახლოვდება ჰოსტს, სადაც AdGuard Home პასუხობს მას. ქსელზე, თუმცა, პასუხი არის ახალი პაკეტი, რომლის წყარო მისამართი შეირჩევა ჰოსტის სტეკის მიერ, არა კლიენტის მოლოდინის მიხედვით.

როდესაც კლიენტის რეზოლვერი არის დაკავშირებული სოკეტი, რაც არის systemd-resolved-ის, dnsmasq-ის და უმეტეს სტუბ რეზოლვერის მიერ გამოყენებული, ის იღებს მხოლოდ პასუხებს ზუსტად იმ მისამართიდან, რომელსაც მას უგზავნიან. პასუხი, რომელიც მოდის 192.168.1.10-დან შეკითხვისადმი 10.6.0.1-ზე, იშლება მანამდეც სანამ parsing მოხდება. რეზოლვერი ლოგავს წარმატებულ პასუხს, კლიენტი ლოგავს timeout-ს, და ორივე მონაყოლია სიმართლე.

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

როგორ არჩევს კერნელი პასუხის წყაროს

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

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

ss -lunp | grep :53აჩვენებს რომელ თამაშში ხართ. მსმენელი0.0.0.0:53არის ველური კარტის შემთხვევა; მსმენელი10.6.0.1:53უკვე დააფიქსირა პასუხი. სოკეტის კითხვა სწრაფია YAML-ის კითხვაზე, და ეს ასახავს იმსას, რაც მათიურად მიმდინარეობს, ვიდრე ბოლო შენახული მდგომარეობა.

რას აკონტროლებს bind_hosts რეალურად

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

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

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

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

რატომ განსხვავდება ერთი რეზოლვერის ორი ინსტალაცია

პლაგინით მართვადი, ამ კონტექსტში, ნიშნავს იმას, რომ რეზოლვერი დამონტაჟებულია და ზედამხედველობა უწევს სხვამ პაკეტმა: როუტერის ფირმვეარიანი პაკეტი, NAS პაკეტი ან სახლის ავტომატიზაციის დამატება. ეს პაკეტი ჩვეულებრივ იშვება საკუთარი AdGuard Home YAML-ის კოპიით და პროცესს თავისი განრიგით restarted აწყობს, მაშინ როცა დამოუკიდებელი ინსტანცია არის ვენდორის ბინარული ფაილი ან კონტეინერი, რომელიც თავად კონფიგურირებთ. ნებისმიერ შემთხვევაში თქვენ უყურებთ ორ დამოუკიდებელ პროცესს სხვადასხვა კონფიგურაციის ფაილებით და სხვადასხვა ბინდ არჩევანებით, მაშინაც კი, როცა ორივე ერთსა და იმავე upstream სიას და ერთსა და იმავე ფილტრის სიებს კითხულობს. ერთი შეუძლია შეაბას კონკრეტული tunel მისამართი, ხოლო მეორე მემკვიდრეობით იღებს wildcard-ს, და ვებსაწვრთვოს ინტერფეისი ორივე მხრიდან იდენტურად ჩანს.

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

დაიმოწმეთ, შემდეგ შეამოწმეთ ტუნელის მხრიდან

შეცვალეთbind_hostsტუნელის მისამართზე, გადატვირთეთ სერვისი და დაადასტურეთ სოკეტის გადატანა:ss -lunp | grep :53ახლა უნდა აჩვენოს10.6.0.1:53და არ იყოს ვაილდკარდის ჩანაწერი. თუ ჯერ კიდევ აჩვენებს0.0.0.0,მიმდინარე პროცესი არ კითხულობს თქვენ მიერ რედაქტირებულ ფაილს.

შემდეგ შეამოწმეთ კლიენტის მხრიდან, რადგან ეს არის ერთადერთი მხარე, რომელიც მნიშვნელობა აქვს. შეკითხვაdig @10.6.0.1 example.comგამოიყენებს გზას, რომელიც მომხმარებელი იყენებს, და ჩაწერა მასპინძელზეtcpdump -ni wg0 udp port 53აჩვენებს პასუხის წყაროს მისამართს ქსელზე. შედარეთ ეს კლიენტის რეზოლვერის კონფიგურაციაში მითითებულ მისამართთან; როდესაც ისინი თანაბარია, დროის ამოწურვა აღარ არის საიდუმლო.

ip route get 10.6.0.2ახსნა ჩარჩენილი უცნაურობის, რადგან აფბეჭდავს ინტერფეისი და წყაროს, რომელსაც ჰოსტი გამოიყენებს კლიენტთან დაბრუნებისთვის. თუ ეს გამოსავალი მიუთითებს LAN-ის ინტერფეისზე, ბინდ-ის ცვლილება სრული გამოსავალი არ არის და შემდეგ კითხვა უნდა გაკეთდეს როუტინგის ცხრილზე.

რისი გამოსწორება არ შეუძლია ბინდ-ის კონფიგურაციას

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

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