VPN პორტის გახსნა კლიენტებს LAN-ზე წვდომას არ აძლევს

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

ორი ჯაჭვი, ორი განსხვავებული დანიშნულება

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

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

რას უშვებს სინამდვილეში მსმენელის წესი

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

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

შეამოწმეთ კლიენტიდან, არასოდეს კარიბჭიდან

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

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

გადაგზავნას სამი რამ სჭირდება და არა ერთი

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

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

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

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

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

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