libvirt სტუმრის DNS-ის გასწორება, რომელსაც ნიშანზე დაფუძნებული VPN დაცვითი კედელი ბლოკავს

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

სტუმრები DNS-ს კარგავენ გვირაბის ამოსვლის მომენტში

დაადასტურეთ ფორმა სანამ რამეს შეცვლით. ჩამოწიეთ გვირაბი, გაუშვით dig @192.168.122.1 example.com სტუმრიდან და ნახეთ, რომ პასუხობს. აამაღლეთ გვირაბი, გაიმეორეთ და ნახეთ, რომ დრო იწურება. შედეგების ეს წყვილი ერთ ნაბიჯში გამორიცხავს გატეხილ libvirt ქსელს, არასწორ გამხსნელის მისამართს და მკვდარ dnsmasq-ს.

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

რატომ არასოდეს ირთვება accept წესი უფრო გვიან ჯაჭვში

ნიშანზე დაფუძნებული VPN დაცვითი კედელი წყვეტს პაკეტის ნიშნის ან კავშირის ნიშნის ყურებით, და არა თქვენი წყაროს მისამართით. ყველაფერი, რაც ფიზიკურ ინტერფეისზე მოდის მოსალოდნელი ნიშნის გარეშე, უარყოფილია, და ეს უარყოფა ხდება იმ წესების სიმრავლეში, რომელსაც ნიშნის ტესტი ეკუთვნის. გვიან ჯაჭვში დამატებული ip saddr 192.168.122.0/24 accept ხაზი ამ პაკეტისთვის უბრალოდ არასოდეს განიხილება, ამიტომ აშკარა წესი სწორად გამოიყურება და არაფერს ცვლის.

მისი გაფართოება მანამ, სანამ რაღაც იმუშავებს, მეორე ხაფანგია. მთელი libvirt ქვექსელის მიღება ჰოსტის შესვლის გზაზე ხსნის ჰოსტის ყველა სერვისს სტუმრებისთვის, მაშინ როცა რეალური საჭიროება ერთი პორტია.

მექანიზმი, რომელიც შესაძლებელს ხდის ვიწრო გამონაკლისს, კავშირების თვალყურის დევნაა. როცა ct mark-ს ადგენთ პაკეტზე, მნიშვნელობა ინახება conntrack ჩანაწერში და არა მხოლოდ პაკეტზე, ამიტომ ამ კავშირის ყოველი პაკეტი შემდგომში მას ატარებს, მათ შორის ჰოსტიდან სტუმართან დაბრუნებული პასუხი. მთელი ხრიკი ეს არის: მონიშნეთ მოთხოვნა ერთხელ და დაბრუნების გზა უკვე მონიშნულია.

მონიშნეთ მოთხოვნა სანამ VPN ცხრილი დაინახავს

მოათავსეთ გამონაკლისი საკუთარ ცხრილში, რომ გვიანმა მკითხველმა იპოვოს იგი VPN წესების გაანალიზების გარეშე:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

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

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

შეინარჩუნეთ ხვრელი 53 პორტის სიგანეში

როგორც დაწერილია, ეს ნებას რთავს DNS-ს libvirt ქვექსელიდან ჰოსტამდე TCP ან UDP 53 პორტზე და სხვა არაფერს. ის არ აძლევს სტუმრებს გვირაბის გარეთ ინტერნეტზე წვდომას და არ აძლევს ჰოსტს სტუმრების მიმართ კავშირების გახსნის საშუალებას. თუ სტუმარს მოგვიანებით ჰოსტის სხვა სერვისი დასჭირდა, დაამატეთ ცალკე წესი, რომელიც ამ დანიშნულების პორტს ასახელებს, ნაცვლად ამის შესუსტებისა.

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

აიძულეთ გადატვირთვას გადაურჩეს და დაამტკიცეთ ორივე ნახევარი

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

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

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