გვირაბი აწეულია, ინტერნეტი არ არის: სად ჩერდება გადამისამართება

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

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

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

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

თვალი ადევნეთ ერთ საჯარო მოთხოვნას

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

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

შეამოწმეთ გადამისამართება, მარშრუტი და ტრანსლაცია

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

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

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

პასუხის გზა და გადამწყვეტი ორი სხვადასხვა პასუხია

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

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

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