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

წესი აღწერს ტრანსპორტის კლასს და არა აპლიკაციას

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

nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100

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

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

HTTP/3 ჩუმად ტოვებს თქვენს TCP წესს

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

ცდის თუ არა კონკრეტული ბრაუზერი HTTP/3-ს, დამოკიდებულია მის კონფიგურაციაზე, საიტზე და იმაზე, წარმატებული იყო თუ არა წინა ცდა. ეს მას ცუდ საგნად აქცევს მეხსიერებიდან მსჯელობისთვის. სამაგიეროდ ჰკითხეთ ინსტრუმენტს:

curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'

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

DNS ცალკე გადაწყვეტილებაა, რომელიც თქვენ უნდა მიიღოთ

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

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

შემდეგ გადაამოწმეთ ამომხსნელით და არა გვერდით:

resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'

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

სამი საზღვარი, სამი განსხვავებული მექანიზმი

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

What you actually wantMechanism that fitsWhat it does not cover
These transport ports use this exitFirewall mark plus policy routeApplications, HTTP/3 over UDP, DNS
This browsing session stays separateApplication-aware VPN, or a separate network namespace plus a proxyOther applications in the same session
Only these private sites are reachableDestination-based routes with private DNSPublic sites on the same address family

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

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

გამოსცადეთ ის ნაკადები, რომლებსაც, სავარაუდოდ, ფარავთ

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

ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'

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

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

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