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

რატომ ვერ დაემთხვევა ჩვეულებრივი მარშრუტი პორტს

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

თანამედროვე iproute2 და ბირთვები აფართოებენ წესის ამომრჩევს: ipproto, sport და dport მიიღება, ამიტომ ip rule add ipproto tcp dport 22 table 100 განზრახვას ერთ სტრიქონში გამოხატავს. გაუშვით ip rule add help რეალურ ჰოსტზე, რათა ნახოთ, ჩამოთვლის თუ არა თქვენი აწყობა dport. თუ ჩამოთვლის, ერთი ბრძანებით დასრულდა; თუ არა, ქვემოთ მოცემული ნიშნის გზა ეკვივალენტურია.

როგორც არ უნდა იყოს, წესი მხოლოდ მაჩვენებელია. ცხრილ 100-ს მაინც სჭირდება მარშრუტი და სწორედ ამ ნაწილს ივიწყებს ხალხი.

სამი ნაწილი, თუ ერთი

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

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

სამი ნაწილი თანმიმდევრობით

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

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

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

ip rule add fwmark 0x1/0x1 table 100

მესამეც, მიეცით ამ ცხრილს ნაგულისხმევი მარშრუტი ფიზიკური ბმულის გავლით. მისამართები საილუსტრაციოა; ჩასვით თქვენი:

ip route add default via 192.168.1.1 dev wlan0 table 100

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

რა ინახავს მას მუშა მდგომარეობაში პირველი პაკეტის შემდეგ

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

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

ნუ მონიშნავთ თავად გვირაბის ტრანსპორტს. WireGuard ან UDP OpenVPN გვირაბი TCP 22 არ არის, ამიტომ ზემოთ მოცემული რეცეპტი უსაფრთხოა, მაგრამ გამონაკლისი, დაწერილი როგორც ყველაფერი გვირაბის დანიშნულების გარდა, შეიძლება დაშიფრული პაკეტები დაიჭიროს და გვირაბი ისე გატეხოს, რომ მარშრუტიზაციის მარყუჟს დაემსგავსოს.

შეამოწმეთ და ნუ ჩათვლით

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

ip route get 203.0.113.10
ip rule show
nft list ruleset

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

როდის არის ეს არასწორი იარაღი

პორტზე დაფუძნებული გამონაკლისები ბუნებით მყიფეა. სერვისები პორტებს იცვლიან, HTTP/3 მოდის როგორც UDP 443, და ერთმა აპლიკაციამ შეიძლება რამდენიმე სხვადასხვა ტიპის ნაკადი გახსნას. თუ ნამდვილი მოთხოვნაა, რომ ეს პროგრამა ჩვეულებრივ ბმულს იყენებდეს, მარშრუტიზაციის ფენა არასწორი ადგილია; ქსელის სახელთა სივრცე ან თითო აპლიკაციის პროქსი უფრო შეეფერება.

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

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

დაკავშირებული სტატიები