პორტის გადამისამართება VPN წვდომის წინააღმდეგ: სად მიდის პაკეტი სინამდვილეში

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

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

DNAT წესი თავიდან წერს დანიშნულებას და იქ ჩერდება

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

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

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

წესი ასევე განსაზღვრავს წარუმატებლობის რეჟიმებს, რომლებსაც მოგვიანებით შეხვდებით. თუ კარიბჭე გადასცემს, მაგრამ აპლიკაციის ჰოსტს დაბრუნების მარშრუტი არ აქვს კლიენტამდე, პასუხები არასწორი წყაროთი გადის და ხელის ჩამორთმევა ჩერდება. თუ მეორე წესი პირველად ემთხვევა, თანმიმდევრობა წყვეტს შედეგს, და iptables -t nat -L -n -v აჩვენებს მრიცხველებს, რომლებიც ამტკიცებენ, რომელმა წესმა აიღო პაკეტი.

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

VPN საერთოდ არ აქვეყნებს აპლიკაციას. კლიენტი აშენებს გარე პაკეტს, რომელიც მიმართულია კარიბჭის საჯარო მისამართზე, შიგნით დაშიფრავს შიდა პაკეტს, ხოლო კარიბჭე გაშიფრავს და შიდა პაკეტს კერძო დანიშნულებისკენ მიმართავს. WireGuard-ში გარე ტრანსპორტი UDP-ია, ჩვეულებრივ მაღალ პორტზე; OpenVPN-ის შემთხვევაში TCP 443-ზე გარე პაკეტი TLS-ის მსგავსია ყველასთვის, ვინც გზას აკვირდება.

გვირაბის შიგნით შიდა პაკეტი ინარჩუნებს კერძო მისამართებს: კლიენტის გვირაბის მისამართი, ვთქვათ 10.8.0.6, და აპლიკაცია 10.20.30.40-ზე. ამიტომ მსმენელი ხედავს წყაროს გვირაბის აუზიდან, და ყოველი კლიენტი იზიარებს ამ კარიბჭეს როგორც შემდეგ ნახტომს. VPN-ის უკან წვდომის ჟურნალები ხშირად სწორედ ამ მიზეზით აჩვენებენ კარიბჭეს და არა მომხმარებელს, თუ კარიბჭე არ ინახავს თავდაპირველ წყაროს.

შეხვევა ხარჯავს სათაურის ადგილს და ეს არის ერთადერთი მექანიზმის დონის განსხვავება, რომელსაც გაზომვადი შედეგი აქვს. გარე IP სათაური პლუს UDP პლუს WireGuard-ის საკუთარი სათაური ჭამს გზის MTU-ს, ამიტომ დიდი პაკეტები უნდა დაიყოს ან შიდა TCP სტეკმა უნდა შეზღუდოს თავისი MSS. გადაცემა, რომელიც გადამისამართებულ გზაზე მუშაობს, შეიძლება გვირაბზე გაჩერდეს, როცა შუალედური მოწყობილობა ყრის ICMP-ს, რომელიც უფრო მცირე MTU-ს შეატყობინებდა.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

გამოვლენა შესასვლელთან წყდება, არა შიფრით

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

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

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

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

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

გაზომეთ გზა, არა ეტიკეტი

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

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

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

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

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

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