როუტერის VPN მუშაობს, მაგრამ LAN კლიენტებს ინტერნეტი არ აქვთ
როუტერი ინტერნეტს თავისი გვირაბით აღწევს, მის უკან მყოფი მოწყობილობები კი — არა. გადაცემა, ტრანსლაცია და დაბრუნების მარშრუტები ცალკეული ნებართვებია.
სტატუსი ამბობს, რომ გვირაბი აქტიურია, როუტერზე არსებული ბრაუზერი გვერდებს ხსნის, და მის უკან არსებული ყველა მოწყობილობა მაინც დროში ვერ ეტევა. ეს კომბინაცია პრობლემას იმ ფენამდე ვიწროვებს, რომელსაც VPN-ის სახელმძღვანელოების უმეტესობა არასოდეს იხსენიებს: როუტერი ერთადერთი ჰოსტი არ არის, რომლის პაკეტებმაც გვირაბს უნდა გადაურჩეს. ლოკალურად წარმოქმნილი ტრაფიკი და გადაცემული ტრაფიკი ერთი და იმავე კოლოფში სხვადასხვა გზას გადის. სცადეთ კლიენტიდან და განსხვავება თეორიული აღარ იქნება.
წაიკითხეთ ხარვეზი LAN ჰოსტიდან
დაიწყეთ იმ მოწყობილობიდან, რომელიც ვერ მუშაობს, რადგან როუტერზე ჩატარებული დიაგნოსტიკა სხვა კითხვას პასუხობს. დაადასტურეთ, რომ კლიენტის ნაგულისხმევი კარიბჭე სწორედ ეს როუტერია, ჩაიწერეთ მისი წყაროს მისამართი და ქვექსელი, შემდეგ კი ნახეთ, რა გადის როუტერის გვირაბის ინტერფეისიდან.
თუ კლიენტის მისამართი ტრანსლირებულია, შორეული მხარე ხედავს გვირაბის მისამართს და იქიდან ყველაფერი ჯანსაღად გამოიყურება, მაშინ როცა კლიენტი მაინც ვერ მუშაობს. თუ ის არ არის ტრანსლირებული, შორეულმა მხარემ უნდა იცოდეს კლიენტის ქვექსელზე დაბრუნების მარშრუტი, და ბევრ კარიბჭეს ნაგულისხმევად ასეთი მარშრუტი არ აქვს. ნებისმიერ შემთხვევაში, თავად როუტერის წარმატებას მნიშვნელობა არ აქვს, რადგან მისი პაკეტები ლოკალურად შეიქმნა და გადაცემის გზას არასოდეს გაუყვა.
ლოკალური და გადაცემული ტრაფიკი განსხვავებულია
Linux და როუტერების უმეტესი პროგრამული უზრუნველყოფა კოლოფის მიერ წარმოქმნილ პაკეტებს სხვაგვარად ეპყრობა, ვიდრე მასზე გამავალ პაკეტებს. გამომავალი ჯაჭვი პირველ ტიპს ხედავს, გადაცემის ჯაჭვი — მეორეს, და როუტერის საკუთარ ტრაფიკზე მორგებულმა პოლიტიკამ გადაცემა ხელუხლებლად დატოვოს.
sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'შეამოწმეთ, საერთოდ ჩართულია თუ არა გადაცემა, შემდეგ წაიკითხეთ გამომავალი ჯაჭვის ნაცვლად გადაცემის ჯაჭვი. წესი, რომელიც დაშიფრულ გარე კავშირს უშვებს, არ არის წესი, რომელიც გაშიფრული პაკეტების გადაცემას უშვებს, და ამ ორის აღრევა ზუსტად ამ სიმპტომს იწვევს. გვირაბის აქტიურობა მხოლოდ პირველს ამტკიცებს.
დაბრუნების გზაც უნდა არსებობდეს
წყაროს ტრანსლაცია წყვეტს, საჭიროა თუ არა დაბრუნების გზა. გვირაბის ინტერფეისზე მასკირებისას პასუხები გვირაბის მისამართზე ბრუნდება და როუტერი მათ უკან ტრანსლირებას უკეთებს. მის გარეშე შორეულ კარიბჭეს კლიენტის ქვექსელზე აშკარა მარშრუტი სჭირდება, და მისმა პოლიტიკამაც უნდა დაუშვას ეს მიმართულება.
სანამ რაიმეს შეცვლიდეთ, ჩაიწერეთ, რომელი ორი დიზაინიდან იყენებს განლაგება, რადგან შესწორებები საპირისპირო მიმართულებებს მიუთითებს. ტრანსლაციის დამატება მალავს დაკარგულ დაბრუნების მარშრუტს და ამტვრევს აპლიკაციებს, რომლებსაც ორიგინალური წყაროს მისამართი სჭირდებათ. ტრანსლაციის გარეშე დაბრუნების მარშრუტის დამატება ჩუმად ფარულდება, როცა შორეული ფაირვოლი უცნობ წყაროს ყრის. აირჩიეთ ერთი, დააფიქსირეთ და მეორე მხარე შეუსაბამეთ.
კლიენტის DNS იმავე განხილვას ეკუთვნის. როუტერის რეზოლვერს შეუძლია უპასუხოს, მაშინ როცა სხვა სერვერზე მიმართული კლიენტი საერთოდ არაფერს იღებს.
შეამოწმეთ ერთი დაშვებული და ერთი აკრძალული ნაკადი
შესწორების შემდეგ სცადეთ ახალი კავშირი კლიენტიდან და არა როუტერის არსებული სესიიდან. შემდეგ დაადასტურეთ, რომ სეგმენტი, რომელმაც გვირაბი არ უნდა გამოიყენოს, კვლავ არ იყენებს მას.
curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.netშეამოწმეთ დაკვირვებული წყაროს მისამართი შორეულ ბოლოში, რადგან ეს გეუბნებათ, რომელი დიზაინი მუშაობს სინამდვილეში. გადაამოწმეთ როგორც სახელის ძებნა, ისე მისამართი, რადგან რეზოლვერის ქცევა იმავე კოლოფში ცალკე გზაა.
შეინარჩუნეთ წესები მხოლოდ იმ კლიენტურ ქსელებზე, რომლებსაც გვირაბი სჭირდებათ, და ნუ გამორთავთ გადაცემის ფილტრს ერთი ტესტის გასავლელად. ეს ცვლილება ტესტს ასწორებს და აშორებს იმ საზღვარს, რომელიც გვირაბს უნდა უზრუნველეყო. ჩაწერეთ წყაროს მისამართი, ტრანსლაციის გადაწყვეტილება და დაბრუნების მარშრუტი ერთ ჩანაწერში, თარიღით.