რატომ არ არის Access Server-ის კლიენტები მისაწვდომი LAN-იდან

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

წაიკითხეთ წყაროს მისამართი, რომელსაც სერვისი ხედავს

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

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

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

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

დაამატეთ მარშრუტი იქ, სადაც პასუხი წყდება

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

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

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

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

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

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

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

მარშრუტიზებული თუ მასკირებული: აირჩიეთ გაცნობიერებულად

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

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

კლიენტის უკან მდებარე ქვექსელი ცალკე ამოცანაა

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

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

შეამოწმეთ ერთი ნაკადით და ერთი ჩაწერით

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

tcpdump -ni any host 10.90.0.25 and port 443

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

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