რატომ ვერ აღწევენ OpenVPN კლიენტები კარიბჭის IPsec სელექტორებს
კარიბჭიდან გაგზავნილი ping სხვა ნაკადს ამტკიცებს. თვალი ადევნეთ კლიენტთა პულს გამოგზავნილ მარშრუტს, IPsec სელექტორებს, გადამისამართების ჯაჭვსა და პასუხის გზას.
გაგზავნეთ ping კარიბჭიდან შორეული IPsec გვირაბის მიღმა მდებარე ჰოსტზე და ის სუფთად პასუხობს, ამიტომ გვირაბი ჯანმრთელად გამოიყურება და ბილეთი წინ მიიწევს. შემდეგ დაკავშირებული კლიენტი იმავე ჰოსტს ცდის და ვერაფერს იღებს უკან. ის ping არასოდეს ყოფილა კლიენტის ნაკადის მტკიცებულება, რადგან ის გავიდა თავად კარიბჭის წყარო-მისამართით და დაემთხვა სხვა IPsec სელექტორს. იმის გაგება, თუ რატომ განსხვავდება ეს ორი შემთხვევა, გასწორების უდიდესი ნაწილია.
კარიბჭის ping ამოწმებს ნაკადს, რომელსაც თქვენი კლიენტი არასოდეს იყენებს
წყარო-მისამართი განსაზღვრავს, რომელი პოლიტიკა მოქმედებს. კარიბჭეზე შექმნილი პაკეტი გადის მისი ლოკალური LAN-ის ან გვირაბის ბოლო წერტილის მისამართით, და პოლიტიკა, რომელიც მას ემთხვევა, ზუსტად ამ შემთხვევისთვის დაიწერა. კლიენტის პაკეტი OpenVPN ინტერფეისზე მოდის კლიენტთა პულის მისამართით, რაც სრულიად სხვა სელექტორია.
ამიტომ ხარვეზი მარშრუტიზაციის პრობლემად გამოიყურება, თუმცა სინამდვილეში პოლიტიკის ფარგლების პრობლემაა. კარიბჭიდან ხელმისაწვდომობა ამტკიცებს, რომ პარტნიორი მუშაობს და წინადადებები შეთანხმებულია, და არაფერს ამტკიცებს იმაზე, დაცულია თუ არა პული.
გაგზავნეთ ის შორეული პრეფიქსი, რომელიც აპლიკაციას ნამდვილად სჭირდება
აიღეთ საილუსტრაციო წყვილი 10.8.0.0/24 დაკავშირებული კლიენტებისთვის და 172.30.239.0/25 დაცული შორეული ქსელისთვის. კლიენტს სჭირდება მარშრუტი მეორე პრეფიქსისკენ, არა კარიბჭის LAN-ისკენ და არა სხვა გვირაბის მისამართისკენ. პულში გაგზავნილი მარშრუტია ის, რაც აიძულებს კლიენტს საერთოდ გადასცეს ეს ტრაფიკი კარიბჭეს. მის გარეშე პაკეტი ვერასოდეს მიაღწევს იმ პოლიტიკის გადაწყვეტილებას, რომელსაც ახლა ამუშავებთ.
Community სერვერზე, რომელიც იღებს გაგზავნილ მარშრუტებს, დირექტივა იღებს ნამდვილ ნიღაბს: push "route 172.30.239.0 255.255.255.128". Access Server იმავე დანიშნულებას აყენებს დაყენებული ვერსიის პირადი ქსელის ან წვდომის წესების პარამეტრებით, მარშრუტიზებული ან თარგმნილი რეჟიმის განზრახ არჩევით. გენერირებული firewall ჯაჭვების რედაქტირება მფლობელი კონფიგურაციის ნაცვლად ის გზაა, რომლითაც მომუშავე ინსტალაცია განუმეორებელი ხდება.
დაკავშირების შემდეგ წაიკითხეთ კლიენტის მარშრუტიზაციის ცხრილი და არა სერვერის განზრახვა. მხოლოდ პულს დაფარული მარშრუტი ნიშნავს, რომ გაგზავნა არასოდეს მოსულა, ხოლო გვირაბით ნაგულისხმევი მარშრუტი ამ მოთხოვნაზე ფართოა და მოგვიანებით გაგაკვირვებთ. შეამოწმეთ ნიღაბიც და პრეფიქსიც, რადგან /25, როგორც /24 გაგზავნილი, მეზობელი მისამართების ტრაფიკს ისეთ გზაზე აგზავნის, რომელსაც მისი ტარება არ შეუძლია. შემდეგ დაადასტურეთ, რომ კლიენტმა ამ დანიშნულებისთვის გვირაბის ინტერფეისი აირჩია.
დაე, სელექტორებმა კლიენტთა პული მოიცვათ
კლიენტების მისამართების შემანარჩუნებელი მარშრუტიზებული წვდომისთვის IPsec პოლიტიკამ პულსა და შორეულ პრეფიქსს შორის ტრაფიკი უნდა დაიცვას. კარიბჭის საკუთარი LAN-ისთვის დაწერილი სელექტორები ping-ს უშვებენ და კლიენტის მოთხოვნას აგდებენ, და ეს ზუსტად ის ასიმეტრიაა, რომლითაც ეს გამოძიება დაიწყო.
შეისწავლეთ შეთანხმებული პოლიტიკა და ასევე კონფიგურირებული წინადადებები, მაგალითად ipsec statusall-ით strongSwan-ზე ან თქვენი იმპლემენტაციის ეკვივალენტური სტატუსის ბრძანებით. პოლიტიკაზე დაფუძნებულ IPsec-ში ჩვეულებრივი მარშრუტი შეიძლება ფიზიკურ ინტერფეისზე მიუთითებდეს, სანამ შესაბამისი ტრაფიკი კვლავ დაშიფრულია, ამიტომ გვირაბის მოწყობილობის არარსებობა არაფერს ამტკიცებს. შეადარეთ სელექტორთა წყვილები თქვენ მიერ ჩაწერილ პულსა და პრეფიქსს.
კარიბჭეზე ზოგადი წყარო-NAT-იც შეიძლება არღვევდეს დამთხვევას. თუ masquerade წესი კლიენტის წყაროს პოლიტიკის შემოწმებამდე გადაწერს, პაკეტი აღარ ჰგავს თქვენ მიერ დაწერილ სელექტორს. ეს ერთ-ერთი მიზეზია, თუ რატომ არის ფართო masquerade წესი ცუდი გამოსწორება მეორე VPN-ისთვის: ის ცვლის, რომელი პოლიტიკა მოქმედებს და რომელ მისამართს ჩაწერს შორეული მხარე. გაათავისუფლეთ ის ტრაფიკი, რომლის მარშრუტიზაციაც გსურთ, ან განზრახ თარგმნეთ და განაახლეთ სელექტორები.
განზრახ აირჩიეთ მარშრუტიზაცია ან თარგმნა
მარშრუტიზაცია კლიენტის მისამართს შორეული მხარისთვის ხილულს ტოვებს, ამიტომ შორეული ჟურნალები და წყაროზე დაფუძნებული წესები მნიშვნელოვნად რჩება, და მოითხოვს, რომ შორეულმა კარიბჭემ იცოდეს პულზე დაბრუნების გზა. თარგმნა პულს ერთი მისამართის უკან მალავს, რაც აშორებს დაბრუნების გზის პრობლემას და ანადგურებს თითოეული კლიენტის იდენტობას.
აირჩიეთ ერთი დიზაინი და ჩაწერეთ, რადგან ორივეს სხვადასხვა სელექტორი და სხვადასხვა firewall თანმიმდევრობა სჭირდება. ნახევრად გამოყენებული masquerade მათ შორის რჩება და არცერთს არ აკმაყოფილებს. ჩაწერილი არჩევანი არის ისიც, რაც შემდეგ ინჟინერს უშვებს შეცდომა განზრახ გადაწყვეტილებისგან გაარჩიოს.
დახურეთ ციკლი გადამისამართებასა და პასუხზე
კარიბჭემ უნდა გადაამისამართოს ის პროტოკოლი და დანიშნულება, რომელიც გაქვთ მხედველობაში, რაც ნიშნავს ჩართულ IP გადამისამართებას და გადამისამართების ჯაჭვს, რომელიც წყვილს უშვებს. შემდეგ შორეულმა მხარემ პასუხები IPsec გზით უკან უნდა გამოგზავნოს, და ეს მარშრუტიზაციის გადაწყვეტილებაა მათ კარიბჭეზე და არა თქვენზე. ორივე ნახევარი ჩვეულებრივი კონფიგურაციაა და ორივე ადვილად რჩება ნახევრად დასრულებული. გამოსცადეთ ისინი ცალ-ცალკე, რათა გამოტოვებული გადამისამართების წესი გატეხილ გვირაბად არ მიიჩნიონ.
გადაამოწმეთ ერთი რეალური კლიენტიდან აპლიკაციაზე მოთხოვნით, დააკვირდით, როგორ გადის ის OpenVPN ინტერფეისს, IPsec გადაწყვეტილებასა და შორეულ ჰოსტს. შეისწავლეთ პასუხი ცალკე დაკვირვებად, რადგან მისული მოთხოვნა და არასოდეს დაბრუნებული პასუხი კლიენტის ადგილიდან ერთნაირად გამოიყურება. ერთი თვალთვალის ქვეშ მყოფი მოთხოვნა უფრო ღირებულია, ვიდრე კარიბჭიდან ნებისმიერი რაოდენობის ping.
ტესტირების დროს დანიშნულების ნებართვა ვიწროდ შეინარჩუნეთ და დაადასტურეთ, რომ წესის გარეშე კლიენტი სერვისს ვერ მიაღწევს. დაყენებული მარშრუტი და დამყარებული ასოციაცია არ არის იგივე, რაც მინიჭებული წვდომა.