დისტანციური მომხმარებლები VPN ჰაბის გავლით მეორე საიტს ვერ აღწევენ

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

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

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

ამიტომ ყოველი გვირაბის ცალკე გამოცდა ძალიან ცოტას ამტკიცებს. ჰაბის LAN მისამართზე ping პირველ გადაწყვეტილებას ამოწმებს, ხოლო მთავარი ოფისიდან ჰაბზე ping — მესამეს. პაკეტს, რომელიც ვარდება, წყაროდ მომხმარებელთა აუზი აქვს და დანიშნულებად მეორე საიტი, ამიტომ ჯერ ეს პრეფიქსები ჩაწერეთ. აქ აუზია 10.80.0.0/24, ჰაბის LAN — 10.10.0.0/24, ხოლო მთავარი ოფისი — 10.20.0.0/24.

გაუშვით შორეული პრეფიქსი დისტანციურ კლიენტთან

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

push "route 10.20.0.0 255.255.255.0"

გაშვებული მარშრუტი ძალაში შედის, როცა კლიენტი უკავშირდება, ამიტომ ონლაინ დარჩენილი მომხმარებელი ვერაფერს ხედავს, სანამ ხელახლა არ დაუკავშირდება. შეამოწმეთ კლიენტზე: ip route get 10.20.0.50 Linux-ზე, route print Windows-ზე. გამოსავალმა უნდა დაასახელოს გვირაბის ინტერფეისი.

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

მიეცით ჰაბს რეალური გასასვლელი მარშრუტი

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

იქ, სადაც საიტ-საიტის ფეხი თავად OpenVPN-ია, მარშრუტი შეიძლება ცხოვრობდეს იმ კონფიგურაციაში, პარტნიორის გვირაბის მისამართით კარიბჭის როლში: route 10.20.0.0 255.255.255.0 172.30.0.2. კარიბჭე სავალდებულოა. თუ გამოტოვებთ, შემდეგი ჰოპი ვარდება იმპლემენტაციის ნაგულისხმევზე, რომელიც განსხვავდება ერთი დისტანციური კლიენტისა და მრავალპარტნიორიანი ჰაბისთვის.

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

გააფართოეთ შორეული მხარე მომხმარებელთა აუზამდე

მთავარი ოფისი უკვე ფარავს ჰაბის LAN-ს, 10.10.0.0/24-ს. მომხმარებელთა აუზი მეორე პრეფიქსია და სელექტორებშიც უნდა იყოს, თორემ არც ერთი პოლიტიკა არ ფარავს 10.80.0.25-ზე მიმართულ პასუხს. ყოველი პარტნიორი თავისი მხრიდან ერთსა და იმავე წყვილ პრეფიქსთა ნაკრებს ასახელებს:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

ერთი მოწყობილობის local_ts მეორის remote_ts-ია. დააკოპირეთ ჰაბის ბლოკი მთავარ ოფისში და წყვილი ინვერტირდება, ამიტომ შვილობილი SA ვერასდროს ამოდის.

უფრო ძველი ipsec.conf სინტაქსი იყენებს მძიმეებით გამოყოფილ leftsubnet-ს. მოქმედი უსაფრთხოების ასოციაცია ინახავს იმ სელექტორებს, რომლებზეც მოლაპარაკება აწარმოა, ამიტომ რედაქტირების შემდეგ ხელახლა დააყენეთ გვირაბი. 10:00-ზე შეცვლილი სელექტორი, რომელიც 09:40-ზე ამოსულ SA-სთან გამოიცდება, მაინც ვარდება, მაშინ როცა კონფიგის ფაილი მთელი დროის განმავლობაში სწორად გამოიყურება.

შემდეგ შეამოწმეთ ბოლო ჰოპი. ip route get 10.80.0.25 შორეულ ბოლოში გვირაბისკენ უნდა მიუთითებდეს. თუ სერვისი LAN მარშრუტიზატორს თავის ნაგულისხმევ კარიბჭედ იყენებს, ამ მარშრუტიზატორსაც სჭირდება დაბრუნების მარშრუტი, თორემ პასუხი იქვე კვდება. tcpdump -ni eth1 host 10.80.0.25-ის გაშვება იმ სეგმენტზე გვიჩვენებს, საერთოდ გავიდა თუ არა პასუხი ბოლოდან.

დაუშვით ნაკადი ჰაბზე

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

საპირისპირო გზის ფილტრაცია მის გვერდით მდგომი ჩუმი მარცხია: როცა ორი ფეხი სხვადასხვა ინტერფეისზეა, rp_filter=1-მა შეიძლება პასუხი ჩამოაგდოს, მაშინ როცა მიღების წესის მთვლელი საერთოდ არ იძვრის. შეადარეთ iptables -vnL FORWARD მცდელობამდე და მის შემდეგ. წესს, რომელიც არასდროს იზრდება, არ აღწევენ, ამიტომ შეხედეთ ერთი დონით ქვემოთ და ნუ გადაწერთ მას.

თუ ტრანზიტი მხოლოდ ერთ ჯგუფს სჭირდება, მარშრუტი ჩადეთ თითო კლიენტის ფაილში client-config-dir-ის ქვეშ, გლობალური push-ის გაფართოების ნაცვლად. Source NAT ჰაბზე ასევე აცილებს შორეული მხარის დაბრუნების მარშრუტის საჭიროებას, მაგრამ მალავს მომხმარებლის მისამართს, ამიტომ შორეული საიტის ჟურნალები და მისამართებზე დაფუძნებული წესები მომხმარებლებს აღარ არჩევენ.

შეამოწმეთ კლიენტიდან, შემდეგ უკუღმა დააბრუნეთ

გამოსცადეთ TCP პორტი და არა მხოლოდ ICMP, რადგან ping შეიძლება გაიაროს, სანამ სერვისი დაბლოკილი რჩება. nc -vz 10.20.0.50 445 და traceroute -n 10.20.0.50 კლიენტიდან გვიჩვენებს, ჰაბის გვირაბის მისამართია თუ არა მეორე ჰოპი. ჰაბზე tcpdump -ni tun0 host 10.20.0.50 და იგივე ფილტრი საიტ-საიტის ინტერფეისზე: მოთხოვნა ორივეზე და პასუხი არც ერთზე — პრობლემას შორეულ მხარეს გადააქვს.

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

შეინახეთ დაბრუნების სია, რადგან ოთხი ობიექტი შეიცვალა და სამი ადვილად დასავიწყებელია: გაშვებული მარშრუტი, ჰაბის მარშრუტი, სელექტორები და ქსელური ეკრანის წესები. გააუქმეთ ისინი უკუღმა, ხელახლა დააყენეთ SA და ერთ მომხმარებელს აკავშირეთ თავიდან. ნაწილობრივი დაბრუნება ტოვებს მარშრუტს, რომელიც გვირაბისკენ მიუთითებს, რომელიც აღარ ემთხვევა, და ამის წაკითხვა უფრო რთულია, ვიდრე თავდაპირველი სიჩუმე. OpenVPN 2.6-ის სახელმძღვანელო ადასტურებს push-ს, route-ს და iroute-ს თქვენი ვერსიისთვის.