NAT განსაზღვრავს, რომელ წყაროს მისამართს ხედავს თქვენი VPN სერვერი სინამდვილეში
თქვენი ლეპტოპის მისამართი არასოდეს აღწევს VPN სერვერს. NAT მას ბოლო ნაბიჯზე გადაწერს და გვირაბის IP მოგვიანებით ენიჭება. როგორ შევადაროთ ორივე ბოლო.
თქვენ წარმოიდგენთ, რომ VPN სერვერი პაკეტიდან კითხულობს თქვენი ლეპტოპის მისამართს და წერს მას ჟურნალში. ის, რასაც კითხულობს, არის ის, რაც ბოლო NAT ნაბიჯმა ჩასვა გარე სათაურში, ხოლო ჰოტსპოტად გამოყენებულ ტელეფონზე ეს ხშირად ასობით სხვა აბონენტთან გაზიარებული მისამართია. თქვენი მანქანის საკუთარი 192.168.x.x ამ სათაურში არასოდეს კვეთს ინტერნეტს, და გვირაბის მისამართს სერვერი გასცემს მას შემდეგ, რაც კავშირი უკვე დამყარებულია. ამიტომ, როცა სერვერის ჟურნალი და ლეპტოპზე ip addr არ ემთხვევა, არც ერთი არ არის მცდარი; ისინი ერთი სესიის სხვადასხვა ფენას აღწერენ.
სამი მისამართი, და მხოლოდ ერთია ჟურნალში
დაბნეულობა სამი მისამართის ერთში შეკუმშვიდან მოდის. თითოეულს განსხვავებული მფლობელი ჰყავს, ის სხვადასხვა სათაურში ცხოვრობს და სერვერს სხვადასხვა გზით აღწევს.
| Address | Who assigns it | Where it sits | Visible to the VPN server |
|---|---|---|---|
Device address, e.g. 192.168.1.24 | Your router via DHCP | Outer header, before translation | No, rewritten in place |
| Translated address and port | Router, ISP CGNAT, or both | Outer header, after translation | Yes, this is the tuple it logs |
Tunnel address, e.g. 10.8.0.6 | The VPN server itself | Inner header, after decapsulation | Yes, but it chose it |
მხოლოდ შუა სტრიქონია უცნობი დაკავშირების მომენტში. სერვერი მას წერს თავის პარტნიორთა ცხრილში, მდგომარეობის ფაილში ან ნაკადის ჟურნალში დემონის მიხედვით: WireGuard მას საბოლოო წერტილს უწოდებს, OpenVPN-ის მდგომარეობის ფაილი მას Real Address-ად აღნიშნავს, ხოლო strongSwan მას IKE_SA-ის დისტანციურ ჰოსტად აცხადებს. ეს მნიშვნელობა განახლდება ყოველ ჯერზე, როცა პაკეტი სხვა წყაროდან მოდის, ამიტომ ის იცვლება ისე, რომ არავინ არაფერს გადატვირთავს.
ქვედა სტრიქონი არის ის, რასაც ადამიანები შეცდომით კითხულობენ როგორც იდენტობის მტკიცებას. ის აღნიშნავს ადგილს სერვერის კონფიგურაციაში და არა პიროვნებას, რადგან სერვერმა ის თავისივე პულიდან აირჩია. ორმა მომხმარებელმა შეიძლება სხვადასხვა დღეს ერთი და იგივე გვირაბის მისამართი მიიღოს, და ერთმა შეიძლება ორი მათგანი ორი მოწყობილობიდან იქონიოს.
რატომ იცვლება ჟურნალში ჩაწერილი ტუპლი, სანამ გვირაბი აწეულია
მისამართების თარგმნა ტაიმერიანი ცხრილია და არა მუდმივი მიბმა. სახლის როუტერი UDP-ის რუკას ბოლო პაკეტის შემდეგ კიდევ გარკვეული დროით ინახავს, ოპერატორის კარიბჭე პორტებს საკუთარი გრაფიკით იყენებს ხელახლა, და Wi-Fi-იდან LTE-ზე გადასული ტელეფონი სრულიად სხვა წყაროთი ბრუნდება. Linux-ის conntrack-ის ნაგულისხმევი მნიშვნელობები აქ სასარგებლო საზომია: nf_conntrack_udp_timeout არის 30 წამი, ხოლო სტრიმინგის ვარიანტი 120, ამიტომ წყნარ გვირაბს რუკა შეიძლება დაკარგოს გაცილებით ადრე, ვიდრე მომხმარებელი შეამჩნევს.
გვირაბი ცოცხლობს, რადგან პროტოკოლი პარტნიორს ამოწმებს და არა მისამართს. WireGuard ხელის ჩამორთმევის შემდეგ მდგომარეობის გარეშეა, ამიტომ ნებისმიერი ავთენტიფიცირებული პაკეტი აახლებს შენახულ საბოლოო წერტილს და ხელახალი მიბმა შემდეგ პაკეტზე გამოჯანმრთელდება; ამიტომ არსებობს persistent-keepalive = 25, რომ რუკა თბილი დარჩეს უმოქმედობისას. OpenVPN-ის --float იგივეს აკეთებს და ავთენტიფიცირებულ კლიენტს ახალი მისამართიდან და პორტიდან გაგრძელების საშუალებას აძლევს. 2.4 და 2.5 ვერსიებში, სადაც float ნაგულისხმევად გამორთულია, ხელახალი მიბმა სესიას აბრუნებს და კლიენტი ხელახლა უკავშირდება.
IPsec აქ უფრო მეტი მოძრავი ნაწილით აღწევს. IKEv2 თარგმნას ამოიცნობს NAT-ის ამოცნობის დატვირთვებში წყაროსა და დანიშნულების ჰეშების შედარებით, გადადის UDP 4500 ინკაფსულაციაზე და keepalive-ებს ახალ ტუპლამდე მიჰყვება. როცა keepalive-ები დაბლოკილია, SA ქაღალდზე აწეული რჩება, სანამ ერთი მიმართულებით ტრაფიკი ჩუმად ჩერდება.
რა შეიძლება სერვერმა მიაწეროს და რა არა
მითი, რომლის მოკვლაც ღირს, არის ის, რომ თარგმნა ოპერატორისგან გმალავთ. ის ცვლის ეტიკეტს და არა დაკვირვებას. ოპერატორის NAT-ის უკან მდგარი კარიბჭე ხედავს 100.64.0.0/10 სივრცეს ან ერთ საჯარო მისამართს, რომელსაც მრავალი აბონენტი იზიარებს, და მაინც შეუძლია ნაკადი დაუკავშიროს სერტიფიკატის სუბიექტს, WireGuard-ის საჯარო გასაღებს, მინიჭებულ გვირაბის მისამართს, ბაიტების მთვლელებს და დროის ფანჯარას. არცერთ მათგანს თქვენი LAN მისამართი არ სჭირდება.
საზღვრები საპირისპირო მიმართულებითაც მუშაობს. ჟურნალში გაზიარებული მისამართი კარიბჭეზე მიუთითებს და არა სახლზე; ერთი და იმავე თარგმნილი მისამართიდან სხვადასხვა პორტზე ორი სესია სხვადასხვა მოწყობილობაა; ერთი და იგივე მისამართი ორ სხვადასხვა დღეს შეიძლება ორი უკავშირო აბონენტი იყოს, თუ პორტი ხელახლა გამოიყენეს. სერვერი, რომელიც მხოლოდ პარტნიორების გასაღებებს ინაწილებს, ანგარიშების ბაზის გარეშე ვერ დააკავშირებს მათ მომხმარებელს, ხოლო სერვერი, რომელიც მხოლოდ მისამართებს ინაწილებს, ერთი როუტერის უკან ლეპტოპსა და ტელეფონს ვერ გაარჩევს.
შეადარეთ ორივე ბოლო, ნაცვლად გამოცნობისა
იმის გასარკვევად, თუ რა მოხდა, დაიჭირეთ იგივე კავშირი ორივე ბოლოზე ერთსა და იმავე მომენტში და შეადარეთ ტუპლი და არა მისამართი. კლიენტზე, ნებისმიერ თარგმნამდე:
ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpointsშემდეგ წაიკითხეთ თარგმნის ჩანაწერი როუტერზე ან CGNAT კარიბჭეზე, და ის, რაც საბოლოოდ სერვერს აღწევს:
conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820სამი ნიმუში ხსნის უმეტეს შეუთავსებლობას. სერვერზე წყაროს პორტი განსხვავდება ლოკალური პორტისგან, სანამ დანიშნულება ემთხვევა: ჩვეულებრივი პორტის თარგმნა. სერვერზე წყაროს მისამართი ეკუთვნის ISP ბლოკს, რომელიც თქვენი არ არის: სულ მცირე ერთი დამატებითი NAT ფენა. პაკეტები ჩერდება უმოქმედობის პერიოდის შემდეგ და ახალი პორტით გრძელდება: რუკის ვადა გავიდა და არა მარშრუტიზაციის ხარვეზი. თუ დროის ნიშნები ერთი-ორი წამზე მეტითაა დაშორებული, ორ სხვადასხვა მცდელობას ადარებთ.
სად ამტვრევს განსხვავება ყველაფერს
შეწყვეტები, რომლებიც სერვერის ხარვეზს ჰგავს, ჩვეულებრივ აქ იწყება. თქვენს სახლის მისამართზე მიმაგრებული წვდომის წესი ვერ მუშაობს მას შემდეგ, რაც ISP-ის იჯარა იცვლება. თარგმნილ მისამართზე შესაბამისი fail2ban წესი ერთდროულად ბლოკავს ამ კარიბჭის უკან ყველა აბონენტს. ფიქსირებული დისტანციური მისამართის მქონე საიტ-საიტ პარტნიორი კვლავ აღარ აახლებს გასაღებებს მობილური კავშირის შეცვლის შემდეგ. გვირაბის პროტოკოლი რიგზე იყო; გარე ტუპლის შესახებ ვარაუდი არა.
იგივე დაბნეულობა სერვერის მხარესაც ჩანს. თუ VPN-ის ყუთი თავად NAT-ის უკანაა, საჭიროა პორტის გადამისამართება და მუშა გადაცემის გზა; strongSwan-ის გადაცემის სახელმძღვანელო IPsec-ისთვის ამ შემთხვევას მოიცავს. მხოლოდ კერძო მისამართზე ხელმისაწვდომი სერვერი ვერასოდეს ხედავს იმ თარგმნილ ტუპლს, რომელსაც მისი კლიენტები წარმოადგენენ, და ეს სხვა პრობლემაა, ვიდრე კლიენტების თარგმნა.
გაიარეთ ეს ოთხი შემოწმება თანმიმდევრობით და გაჩერდით პირველზე, რომელიც ვერ გაივლის:
- დაიჭირეთ ორივე ბოლოზე ერთდროულად; დაადასტურეთ, რომ წყაროს პორტი, დანიშნულების პორტი და დროის ნიშნები ემთხვევა.
- სერვერის პარტნიორთა სიაში წაიკითხეთ ის მისამართი, რომელიც მას ახლა აქვს და არა ის, რომელსაც ელოდით.
- შეამოწმეთ conntrack ან NAT ცხრილი ჩანაწერისა და მისი დარჩენილი სიცოცხლისთვის.
- დაადასტურეთ, რომ კლიენტზე გვირაბის ინტერფეისის მისამართი ემთხვევა სერვერის მიერ მინიჭებულს და არა LAN მისამართს.
თუ ორივე დაჭერა ტუპლზე თანხმდება და გვირაბი მაინც ვერ მუშაობს, თარგმნა თქვენი პრობლემა არ არის; გადადით ხელის ჩამორთმევასა და გვირაბის შიგნით არსებულ მარშრუტიზაციის ცხრილზე.