VPN კარიბჭეს IP გადაცემა სჭირდება: რა უნდა შემოწმდეს

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

ორი როლი დამოუკიდებელია, ისევე როგორც ორი მისამართის ოჯახი.

საკუთარ მისამართზე პასუხი არაფერს ამტკიცებს

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

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

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

შეამოწმეთ თითოეული მისამართის ოჯახი ცალ-ცალკე

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

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

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

გადაცემა ოთხი მოთხოვნიდან ერთია

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

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

ტესტი კლიენტიდან, არა კარიბჭიდან

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

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

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