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

დაამტკიცეთ, სად ჩერდება ტრაფიკი

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

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

PPTP კვდება 47-ე პროტოკოლის გარეშე

PPTP მართვას TCP 1723-ზე გადასცემს, ხოლო მონაცემებს GRE-ის შიგნით, რომელიც IP პროტოკოლი 47-ია და არა პორტის ნომერი. მხოლოდ 1723-ის გადამისამართება კლასიკურ შედეგს იძლევა: კავშირი ავთენტიფიკაციას გადის და შემდეგ ჩუმდება, რადგან დატვირთვის მატარებელი პროტოკოლისთვის წესი არ არსებობს. კლიენტი ვერ გაარჩევს ამას უარყოფილი პაროლისგან, ამიტომ ჩაწერა კონფიგურაციის ცვლილებებამდე უნდა მოხდეს.

გამტარიანობა მოქმედებს შემავალი გადამისამართების საპირისპირო მიმართულებით, და firmware საკმაოდ ხშირად ერთსა და იმავე იარლიყს იყენებს ორივესთვის, რაც ყველას აბნევს. Linux კლიენტზე ლოკალურ ფაირვოლს შეუძლია GRE გადააგდოს გაცილებით ადრე, ვიდრე მარშრუტიზატორი ჩაერთვება, ამიტომ 47-ე პროტოკოლს საკუთარი წესი სჭირდება და conntrack დამხმარე უნდა ჩაიტვირთოს. Ubuntu-ს ufw ამ წესებს before ფაილში ინახავს, რადგან ჩვეულებრივი allow წესები პროტოკოლის ნომერს ვერ გამოხატავს. შემდეგ გადატვირთეთ ფაირვოლი მანქანის გადატვირთვის ნაცვლად.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP და IPsec ორი NAT-ის უკან

L2TP IPsec-ის შიგნით საჭიროებს UDP 500-ს გასაღებების გაცვლისთვის, UDP 4500-ს NAT-ის აღმოჩენისას, და ESP-ს როგორც პროტოკოლი 50. თითოეული მათგანი დამოუკიდებლად იფილტრება, ამიტომ ერთის ნებადართული წესი დანარჩენ ორზე არაფერს ამტკიცებს. ორი მარშრუტიზატორი ზედიზედ ყოველ პაკეტს ორჯერ თარგმნის, და მხარეები აღარ თანხმდებიან, რა იყო მოლაპარაკებული.

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

ოპერატორების ქსელები და მისამართების გაზიარება

WAN მისამართი 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ან 100.64.0.0/10 დიაპაზონში ნიშნავს, რომ მარშრუტიზატორს საჯარო მისამართი არ აქვს და ინტერნეტიდან ვერც ერთი შემავალი გადამისამართება ვერ მიაღწევს მას. ოპერატორის დონის NAT დამატებით ფილტრავს პროტოკოლებს, რომლებსაც არ ელის, და GRE ხშირი მსხვერპლია მობილურ კავშირებზე. შეადარეთ WAN მისამართი თავად მარშრუტიზატორზე, და არა ის მისამართი, რომელსაც საძიებო საიტი იტყობინება მის უკან მდგარი კლიენტისთვის.

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

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

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

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

SoftEther-ის ნაგულისხმევი მნიშვნელობები კარგი მაგალითია: TCP 443, 992 და 5555, ხოლო L2TP/IPsec და DNS-გვირაბის ფუნქციები საკუთარ სოკეტებს ამატებენ. ამ ფუნქციების გამორთვა მსმენელებს შლის და არ მალავს მათ, ხოლო გარე ჰოსტიდან შემოწმება გეუბნებათ, საერთოდ უშვებს თუ არა ოპერატორი პორტს. ლოკალურად მპასუხობი მსმენელი მაინც შეიძლება დახურული იყოს ზემოთ, ამიტომ შეადარეთ მარშრუტიზატორის საკუთარი WAN მისამართი იმას, რასაც გარე სერვისი იტყობინება.

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