მარშრუტიზებული VPN კლიენტი სერვერს აღწევს, მაგრამ LAN ჰოსტებს არა

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

მიჰყევით პასუხს და არა მოთხოვნას

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

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

მოათავსეთ დაბრუნების მარშრუტი იქ, სადაც ჰოსტები იყურებიან

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

რატომ ჩანს, რომ წყაროს NAT ამას ასწორებს

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

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

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

ღრუბლოვანი გზა სამ პარამეტრს მოითხოვს

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

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

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

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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