საიტებს შორის VPN ან დისტანციური წვდომა: რას აკავშირებს თითოეული
ერთი აკავშირებს გეითვეებს, მეორე — მოწყობილობებს. შეადარეთ ტრაფიკის სელექტორები მარშრუტებს, დაგეგმეთ მისამართები და შემდეგ შეამოწმეთ გადაგზავნა და პოლიტიკა რეალური ჰოსტიდან.
ორივე გადაწყვეტას VPN ეწოდება და ისინი სხვადასხვა პრობლემას ხსნიან. საიტებს შორის გვირაბი აკავშირებს ორ გეითვეის, ასე რომ მათ უკან მყოფ ყველა ჰოსტს შეუძლია მეორე მხარეს დაშვებულ მისამართებამდე მიაღწიოს არაფრის ინსტალაციის გარეშე. დისტანციური წვდომის გვირაბი ცალკეულ მოწყობილობებს აკავშირებს ქსელთან, ერთდროულად ერთი კლიენტი. შედარება მნიშვნელოვანია, რადგან განლაგების შეცდომების უმეტესობა ერთის კონფიგურაციისას მეორის ქცევის მოლოდინიდან მოდის, და სიმპტომი ჩვეულებრივ დროის ამოწურვაა იმ სერვისში, რომელსაც გვირაბმა ნამდვილად მიაღწია.
ორი გადაწყვეტა, ორი საზღვარი
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
არც ერთი გადაწყვეტა არ აფართოებს LAN-ის მაუწყებლობის დომენს. მოშორებული მხარის მოწყობილობები არ ჩნდება ლოკალურ აღმოჩენის სიაში, და ამის მოლოდინი პირველი დაშვებაა, რომელიც უნდა მიატოვოთ. კერძო DNS სახელები, რომლებსაც განზრახ აქვეყნებთ, უფრო პროგნოზირებადია, ვიდრე ნებისმიერი აღმოჩენის პროტოკოლი, და ისინი ვენდორის შეცვლას გადაურჩებიან.
აიღეთ 10.10.0.0/24 ერთ საიტზე და 10.20.0.0/24 მეორეზე. გეითვეი A-ს სჭირდება მარშრუტი ან ტრაფიკის სელექტორი, რომელიც 10.20.0.0/24 პრეფიქსს გვირაბში გაგზავნის, ხოლო გეითვეი B-ს სჭირდება მისი სარკული ასახვა. შემდეგ ორივე მხარის ჰოსტები ჩვეულებრივ IP კავშირს იყენებენ და არასოდეს იგებენ, რომ გვირაბი არსებობს. ეს უხილავობა თვისებაა, და სწორედ ამიტომ გაუმართაობები ჩვეულებრივ ქსელურ შეცდომებს ჰგავს და არა გვირაბის შეცდომებს.
პოლიტიკაზე დაფუძნებული და მარშრუტზე დაფუძნებული ერთი და იგივე გვირაბი არ არის
პოლიტიკაზე დაფუძნებული IPsec განლაგებისას შეთანხმებული ტრაფიკის სელექტორები ზუსტად განსაზღვრავენ, წყარო-დანიშნულების რომელი წყვილებია დაცული. თუ ერთი გეითვეის უკან ახალი ქვექსელი გამოჩნდა და არც ერთი სელექტორი არ ფარავს მას, გვირაბი აქტიური რჩება და ახალი ქვექსელი უბრალოდ არ გადაიცემა. მარშრუტზე დაფუძნებულ გადაწყვეტაში ტრაფიკს ინტერფეისი იღებს და გადაწყვეტილებას მარშრუტიზაციის ცხრილი იღებს, რაც პრეფიქსის დამატებას მარშრუტის ცვლილებად აქცევს და არა გვირაბის ხელახალ მოლაპარაკებად.
StrongSwan ორივე ხედს პირდაპირ აჩვენებს, და მათი ერთად წაკითხვა არის გზა იმის გასარკვევად, თუ რომელი მოდელი განათავსეთ სინამდვილეში.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'სელექტორების სია, რომელშიც თქვენთვის მნიშვნელოვანი პრეფიქსი გამოტოვებულია, ხსნის გაუმართაობას ყოველგვარი პაკეტის ჩაჭერის გარეშე, და არასწორ ინტერფეისზე მიმთითებელი მარშრუტი ხსნის სარკულ გაუმართაობას დაბრუნების გზაზე. წაიკითხეთ ორივე, სანამ რაიმეს ხელახლა მოილაპარაკებთ, რადგან გასაღების განახლება არ დაამატებს სელექტორს, რომელიც არასოდეს გიკონფიგურირებიათ.
დაგეგმეთ მისამართები გვირაბამდე
გადაფარვადი დიაპაზონები ის დიზაინის შეცდომაა, რომელსაც კონფიგურაციით ვერ გამოასწორებთ. თუ ორივე საიტი 192.168.1.0/24-ს იყენებს, ჰოსტს, რომელსაც 192.168.1.50 სჭირდება, ორი კანდიდატი აქვს და არჩევის არავითარი საშუალება. გვირაბი აუთენტიფიკაციას გაივლის, უსაფრთხოების ასოციაციები დამყარდება, და მარშრუტიზაციის გადაწყვეტილება მაინც არასწორი ან ორაზროვანი იქნება.
აირჩიეთ სამი პატიოსანი ვარიანტიდან ერთი: ერთი საიტის ხელახალი ნუმერაცია, გადაფარვადი დიაპაზონის გეითვეიზე თარგმნა ისე, რომ თითოეულმა მხარემ განსხვავებული პრეფიქსი დაინახოს, ან ამ ჰოსტებისთვის პირდაპირი მარშრუტიზაციის დათმობა და სერვისის სხვაგვარად გამოქვეყნება. თითოეულს თავისი ფასი აქვს, და პირველი ჩვეულებრივ ყველაზე იაფია ორწლიან ჰორიზონტზე. გადაწყვიტეთ გვირაბის არსებობამდე, რადგან შემდეგ ცვლილება შეეხება ყველა მოწყობილობას, რომელსაც ძველი მისამართი აქვს.
MTU-ის საკითხიც ადრე მოაგვარეთ. გვირაბი ამცირებს სასარგებლო დატვირთვას, და ფრაგმენტაციაზე დამოკიდებული დიზაინი სხვაგვარად იქცევა, ვიდრე ის, რომელიც MSS-ს გეითვეებზე აფიქსირებს.
გადაგზავნა და პოლიტიკა გვირაბის გარეთაა
გეითვეი მზად უნდა იყოს პაკეტები გადააგზავნოს გვირაბის ინტერფეისსა და LAN ინტერფეისს შორის, და ორივე მიმართულებას სჭირდება პოლიტიკა, რომელიც სერვისს უშვებს. Linux-ში ეს ორი ცალკე პარამეტრია, გარდა ამისა firewall-ის წესები, რომლებიც წყვეტენ, საერთოდ დაიშვება თუ არა გადაგზავნილი ნაკადი.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTმიმღები ჰოსტი მესამე ფენას ამატებს: მისმა საკუთარმა firewall-მა მაინც უნდა მიიღოს კლიენტი მოშორებული ქვექსელიდან. ფაილური სერვერი, რომელიც მხოლოდ საკუთარ ლოკალურ /24-ს უშვებს, უარყოფს 10.20.0.7-დან გადაგზავნილ ტრაფიკს, მიუხედავად იმისა, რამდენად ჯანსაღად გამოიყურება გვირაბი, და ამ უარყოფის მარშრუტიზაციის ხარვეზად წაკითხვა ადვილია.
შეამოწმეთ ჰოსტიდან და არა გეითვეიდან
თავად გეითვეის მიერ გაგზავნილი ping შეიძლება განსხვავებულ წყაროს მისამართსა და პოლიტიკას მიჰყვეს, ვიდრე გადაგზავნილი მომხმარებლის ტრაფიკი. ეს მას სუსტ ტესტად აქცევს და ზოგჯერ შემცდომელს: წარმატებულია, როცა აპლიკაცია ვარდება, ან ვარდება, როცა აპლიკაცია მუშაობს.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullგამოიყენეთ რეალური ჰოსტი, რეალური წყაროს მისამართი და ის რეალური პროტოკოლი, რომელსაც აპლიკაცია იყენებს. შემდეგ დაბრუნების გზა ცალკე წაიკითხეთ, რადგან დაბრუნების მარშრუტის გარეშე მომუშავე წინა მიმართულება წარმოქმნის დროის ამოწურვას, რომელიც დაბლოკილი სერვისის იდენტურია.
აირჩიეთ გადაწყვეტა იმ კითხვის მიხედვით, რომელსაც პასუხობთ: ქსელებს აკავშირებთ თუ მოწყობილობებს იღებთ? დანარჩენი ყველაფერი, მათ შორის რომელ ვენდორს კონფიგურირებთ, ამ პასუხიდან გამომდინარეობს.