UFW VPN-ის DNS სერვერს გვირაბის აწევისთანავე ტოვებს
UFW-ის ნაგულისხმევი უარის პოლიტიკა გვირაბის ინტერფეისსაც ფარავს. ტრაფიკი მიმართულებით დაალაგე, გაგზავნილ resolver-ს tun0-ზე ნება დართე, შემდეგ გარე გზა გახსენი.
სახელები წყვეტს გადაწყვეტას იმ მომენტში, როცა VPN უკავშირდება, მაშინ როცა საჯარო მისამართზე ping კვლავ პასუხობს და firewall-ის სტატუსი არაფერს არ აჩვენებს არასწორად. პოლიტიკაში არაფერი შეცვლილა; შეიცვალა ის, რომ ახალი ინტერფეისი გამოჩნდა, და ნაგულისხმევი უარი მას პირველივე პაკეტიდან ფარავს. UFW გადაწყვეტს მიმართულებითა და ინტერფეისით, ამიტომ უსადენო კავშირისთვის დაწერილი წესი არაფერს ამბობს გვირაბიდან გამომავალ ტრაფიკზე. შეკეთება რამდენიმე ვიწრო წესია, გარკვეული თანმიმდევრობით გამოყენებული.
სიმპტომი მხოლოდ მას შემდეგ ჩნდება, რაც გვირაბი აწეულია
ნაგულისხმევი უარის პოლიტიკა აკეთებს ზუსტად იმას, რაც უთხრეს: ყველაფერი შესაბამისი წესის გარეშე უარყოფილია, ყველა არსებულ ინტერფეისზე. გვირაბი არ არსებობდა, როცა წესები იწერებოდა, ამიტომ არც ერთი მათგანი ვერ დაიჭერს მას, და უარი, რომელიც ყოველთვის იყო, ახლა სახელების გადაწყვეტას ეხება. პირდაპირი ტრაფიკი ლიტერალურ მისამართზე ჯერ კიდევ შეიძლება მუშაობდეს, როცა უფრო ფართო ნებართვა ფარავს მას, და ამიტომ საჯარო resolver-ზე ping წარმატებულია, ხოლო სახელის ძიება ვერ ხერხდება. ხარვეზი არის წესი ინტერფეისისთვის, რომელიც პოლიტიკას არასდროს უნახავს.
ეს ასევე ხსნის, რატომ ბრუნდება მარცხი სუფთად: ჩამოწიე გვირაბი და სახელები ისევ გადაწყდება, რადგან მოთხოვნა ბრუნდება ინტერფეისზე, რომელსაც წესები აქვს. პოლიტიკა, რომელიც მარცხდება მხოლოდ გვირაბის აწეულობისას, DNS პრობლემა არ არის, და თავად resolver-ის რეგულირება აქ ყველაზე მეტ დროს კარგავს. წაიკითხე ინტერფეისების სია resolver-ის კონფიგურაციის წაკითხვამდე.
სამი მიმართულება, სამი განსხვავებული წესების ნაკრები
ერთი სესია ეხება წესებს ერთზე მეტი მიმართულებით, და გვირაბი მეორე ინტერფეისს უმატებს მათ თითქმის ყველას. ტრაფიკის ჯერ მიმართულებითა და ინტერფეისით დალაგება დანარჩენს მექანიკურს ხდის, რადგან ქვემოთ ყოველ სტრიქონს თავის ადგილზე თავისი წესი სჭირდება. მაგალითები იყენებს tun0-ს და 10.8.0.0/24 აუზს, ამიტომ შეცვალე სახელები და დიაპაზონები კლიენტის საკუთარი გამოსავლიდან აღებულით.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
ორი სტრიქონი ხშირად ირევა, რადგან ორივე გვირაბს ახსენებს. resolver-ის წესი უშვებს ტრაფიკს, რომელსაც კლიენტი გვირაბში აგზავნის, ხოლო SSH-ის წესი უშვებს ტრაფიკს, რომელსაც სერვერი იქიდან იღებს; ისინი სხვადასხვა მანქანაზე ცხოვრობენ და დამოუკიდებლად მარცხდებიან. ყველაზე ხშირად დავიწყებული სტრიქონი მეორეა, რადგან კლიენტი საერთოდ ვერ ააშენებს გვირაბს, სანამ სერვერის საჯარო მისამართზე მისი ტრაფიკი ნებადართული არ იქნება. იმუშავე ზემოდან ქვემოთ და ყველა მარცხს ერთი სავარაუდო მიზეზი აქვს.
გაგზავნილ resolver-ს საკუთარი წესი სჭირდება
გვირაბი DNS-ს გადაიტანს თუ არა, დამოკიდებულია იმაზე, რას აგზავნის სერვერი. სერვერი, რომელიც resolver-ის ოფციას უგზავნის, კლიენტის კონფიგურაციაში კერძო მისამართს აყენებს, და ეს მისამართი მხოლოდ გვირაბის გავლით მარშრუტიზდება. თუ სერვერი არაფერს აგზავნის, კლიენტი ინარჩუნებს იმ resolver-ს, რომელიც უკვე ჰქონდა, და ქვემოთ მოცემულ წესებს ნებადართული არაფერი აქვთ. სანამ რამეს დაწერ, შეამოწმე გაგზავნილი მდგომარეობა და მიმდინარე მოთხოვნის შედეგი:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedსტატუსის გამოსავალი ასახელებს გამოყენებულ resolver-ს და კავშირს, რომელზეც ის მიბმულია, და მის უკან არსებული მარშრუტის ძიება აჩვენებს, რომელი ინტერფეისი გადაიტანს მოთხოვნას ამ მისამართზე. როცა resolver სხვა კავშირზე ზის, პრობლემა firewall-ზე უფრო ადრეა და არც ერთი წესი არ დაეხმარება. როცა ორივე გვირაბზე თანხმდება, ორი წესია საჭირო, რადგან მოთხოვნების უმეტესობას UDP გადაიტანს და TCP იღებს საქმეს, როცა პასუხი იჭრება. ჩაწერე ორივე მნიშვნელობა, რადგან სწორედ მათ დაასახელებენ წესები:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'გახსენი გარე გზა შიდაზე ადრე
კლიენტმა სერვერის საჯარო მისამართს უნდა მიაღწიოს სანამ გვირაბი იარსებებს, ამიტომ მისი წესი ფიზიკურ კავშირზე ზის და პირველ რიგში უნდა იყოს ადგილზე. პოლიტიკა, რომელიც resolver-ს უშვებს, მაგრამ სერვერს ივიწყებს, კლიენტს სრულიად უუნაროს ტოვებს გვირაბის აშენებაში, და ამ სიმპტომს ჩვეულებრივ kill switch-ს აბრალებენ. შემდეგ ნება დართე იმ სერვისებს, რომლებიც ნამდვილად გინდოდა გვირაბით, ერთდროულად ერთი ვიწრო წესი, ინტერფეისის მთლიანად გახსნის ნაცვლად. ვიწრო წესებია მიზეზი, რის გამოც უარი ადგილზე შეიძლება დარჩეს.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'თანმიმდევრობა მნიშვნელოვანია ტესტირებისას, რადგან პირველი წესია ის, რაც გვირაბს საერთოდ ასვლის საშუალებას აძლევს. დაამატე ის, დაუკავშირდი და დაადასტურე, რომ გვირაბი აწეულია, სანამ სერვისის წესს დაამატებ, რადგან ორივეს ერთად კეთება ნიშნავს, რომ მარცხი არაფერს გეუბნება იმაზე, რომელი ნახევარია არასწორი. ზემოთ მოცემული დოკუმენტაციის მისამართი შეცვალე იმ საბოლოო წერტილით, რომლისთვისაც კლიენტია კონფიგურირებული.
დაასრულე კლიენტის მხარე განზრახ გათიშვით. უარმა ჯერ კიდევ უნდა უარყოს ის ტრაფიკი, რომელიც განზრახ გამორიცხე, რადგან resolver, რომელიც პასუხობს, როცა გვირაბი აწეულია, ეჭვისას უარმყოფი პოლიტიკის მხოლოდ ნახევარს ფარავს.
დაკავშირებული კლიენტი ჯერ არ არის მიღებული
სერვერს საკუთარი მიმართულება აქვს გასათვალისწინებელი, და ხელის ჩამორთმევის დამთავრებული კლიენტი ჯერ კიდევ ვერ აღწევს სერვერზე მოქმედ არაფერს, სანამ სერვერი არ მიიღებს მას. საჯარო მსმენელის წესი მხოლოდ გვირაბის არსებობას უშვებს; ის გვირაბის ტრაფიკს შიგნით არ უშვებს. სერვერზე ეს ორი წესია პლუს ერთი შემოწმება, რომ სერვისი ნამდვილად უსმენს:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'წესში აუზი უნდა ტოლი იყოს იმ დიაპაზონისა, რომელსაც სერვერი ანაწილებს, და გვირაბის ნომერი უნდა შეესაბამებოდეს სერვერის მიერ შექმნილს, რადგან სხვა ინტერფეისის წესი წესის არარსებობისგან არ გაირჩევა. limit განზრახ არის ადმინისტრაციული პორტისთვის, რადგან ის ზღუდავს განმეორებით კავშირებს უსაზღვროდ მიღების ნაცვლად. მსმენელის შემოწმება ჰყოფს დახურულ პორტს გადაგდებული პაკეტისგან, რომლებიც კლიენტის მხრიდან ერთნაირად გამოიყურება. დანომრილი წესებიც არ არის მთელი სურათი: UFW-ის before წესები და ხელით დაწერილი ნებისმიერი nftables სტრიქონი უფრო ადრე ემთხვევა და ჯერ კიდევ შეიძლება უარყოს პაკეტი, რომელსაც სია თითქოს უშვებს.