მეორე ქვექსელის დამატება საიტებს შორის VPN-ში: ორი გზა
პოლიტიკაზე დაფუძნებულ გვირაბებს ორივე მხარეს შესაბამისი სელექტორები სჭირდება; მარშრუტზე დაფუძნებულებს — მარშრუტი. აირჩიეთ სწორი გზა და ჯერ დაბრუნების მარშრუტი გაასწორეთ.
მომუშავე საიტებს შორის გვირაბში მეორე ქვექსელის დამატებას ერთ დიზაინში ხუთი წუთი სჭირდება, მეორეში კი თითქმის მთელი შუადღე. როცა გვირაბი მარშრუტებს ამონტაჟებს თქვენს მიერ დასახელებული პრეფიქსებისთვის, თქვენ ამატებთ მარშრუტს და ტრაფიკი მას მიჰყვება. როცა ის ერთ ფიქსირებულ სელექტორთა წყვილზე მოლაპარაკებს, ახალი პრეფიქსი დაუცველი რჩება, სანამ ორივე მხარე არ შეთანხმდება შესაბამის წყვილზე. სამი რამ წყვეტს საქმეს: რას აღწერს სინამდვილეში თითოეული მხარის კონფიგურაცია, ვიწროვდება თუ არა შეთანხმებული ტრაფიკი უმცირეს შესაბამის წყვილამდე და ვის ეკუთვნის ახალი დიაპაზონის დაბრუნების გზა.
წაიკითხეთ ბირთვი და არა სტატუსის ეტიკეტი
დაკავშირებაზე მომხსენებელ გვირაბს მინიმუმ ერთი შვილობილი ასოციაცია აქვს დაყენებული, მაგრამ არა აუცილებლად ის, რასაც ფიქრობთ. Linux-ში ბირთვი აჩვენებს, რა გამოიყენება: ip xfrm policy ჩამოთვლის სელექტორთა წყვილებს, ხოლო swanctl --list-sas (ან ძველი ipsec statusall) აჩვენებს, რაზე შეთანხმდნენ მხარეები, თითოეული მიმართულების ტრაფიკის სელექტორების ჩათვლით. თუ ახალი პრეფიქსი არც ერთში არ ჩანს, ის დაუცველია, რაც არ უნდა თქვას კონფიგურაციის ფაილმა.
შეადარეთ ეს მარშრუტების ცხრილს. მარშრუტზე დაფუძნებულ სქემაში გვირაბის მოწყობილობა დაცული პრეფიქსების შემდეგი ნახტომია. პოლიტიკაზე დაფუძნებულ სქემას ხშირად არ აქვს ცალკე მარშრუტი შორეული ქვექსელისთვის, მხოლოდ ნაგულისხმევი მარშრუტი, რადგან ტრაფიკს პოლიტიკა ირჩევს და არა ცხრილი.
პოლიტიკაზე დაფუძნებული გვირაბები: ორივე მხარემ უნდა ჩამოთვალოს ახალი პრეფიქსი
strongSwan-ის ტერმინებში სელექტორი ცხოვრობს შვილობილი კონფიგურაციის local_ts და remote_ts ველებში, leftsubnet და rightsubnet-ის მემკვიდრეებში. ახალი პრეფიქსი ორივე მხარეს სარკისებურად უნდა გამოჩნდეს: რასაც საიტი A ლოკალურს უწოდებს, საიტი B შორეულს უწოდებს. შეუსაბამობა იშვიათად იძლევა სუფთა შეცდომას. მხარეები ვიწროვდებიან გადაკვეთამდე, ძველი პრეფიქსი აგრძელებს მუშაობას და მხოლოდ ახალი მარცხდება ჩუმად.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense-ში ან OPNsense-ში ეს ნიშნავს მეორე Phase 2 ჩანაწერს, რომელიც ახალ ლოკალურ ქვექსელს ახალ შორეულს უწყვილებს, შემდეგ კი გამოყენებას. შეინახეთ ძველი ჩანაწერი; მისი ჩანაცვლება გადააადგილებს თავდაპირველ ქვექსელს დამატების ნაცვლად. თუ არსებული Phase 2 უკვე ფარავს 0.0.0.0/0-ის მსგავს ზესელს ან შეჯამებულ დიაპაზონს, ნუ დაამატებთ გვერდით უფრო ვიწრო ჩანაწერს: გადაფარებული სელექტორები კონკურენტ პოლიტიკებს აყენებენ და შეფასების რიგი წყვეტს გამარჯვებულს.
IKEv1 ყოველ ქვექსელთა წყვილს საკუთარ Phase 2-ად აქცევს და მხარე, რომელიც ერთ წყვილს იღებს გაცვლაზე, დანარჩენებს ყრის. IKEv2-ს შეუძლია ერთ შვილში რამდენიმე სელექტორთა წყვილის ტარება, მაგრამ მხოლოდ თუ ორივე იმპლემენტაცია მიიღებს მათ. swanctl --list-sas-დან მიღებული სია სიმართლეა; რაც აკრიფეთ, მოთხოვნაა.
მარშრუტზე დაფუძნებული გვირაბები: მარშრუტი პოლიტიკაა
XFRM ინტერფეისი ან VTI მოწყობილობა ტრაფიკს მარშრუტების ცხრილის მიხედვით ატარებს. თქვენ ახალ პრეფიქსს ორივე საიტზე მოწყობილობისკენ მიმართავთ და ინტერფეისის ტრანსფორმაციაზე მიბმული მდგომარეობა გამოიყენება. სინქრონიზაციისთვის სელექტორთა წყვილი არ არსებობს, ამიტომ ეს დიზაინი უკეთ სკალირდება ქვექსელების ზრდასთან ერთად. strongSwan-ის გადაცემის სახელმძღვანელო დეტალურად განიხილავს ბირთვის მხარეს.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard უფრო შორს მიდის. AllowedIPs ერთდროულად კრიპტოგრაფიული ნებადართული სიაა და, wg-quick-ის მეშვეობით, მარშრუტების ცხრილის ჩანაწერი. დაამატეთ პრეფიქსი მხოლოდ ერთ მხარეს და მიიღებთ ხელის ჩამორთმევას, გამავალ პაკეტებს და სიჩუმეს, რადგან შორეული მხარე ყრის პაკეტებს, რომელთა წყაროც მის სიაში არ არის. wg set ფორმა მთელ სიას ცვლის, ამიტომ გაიმეორეთ უკვე მომუშავე პრეფიქსები, თორემ მოწყვეტთ მათ:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0ის მეორე ბრძანება სავალდებულოა, როცა wg-quick-ის ნაცვლად wg set გამოიყენეთ. ბირთვი ახალ სიას მაშინვე იღებს, მაგრამ არაფერი ამატებს მისთვის მარშრუტს, ამიტომ ლოკალურად შექმნილი ტრაფიკი მაინც ნაგულისხმევი კარიბჭით გადის. ეს არის ყველაზე გავრცელებული მიზეზი, რატომ მუშაობს ახალი WireGuard ქვექსელი გვირაბის ჰოსტიდან და არა ლეპტოპიდან.
დაბრუნების გზა უფრო ხშირად ფუჭდება, ვიდრე გვირაბი
ახალი შორეული ქვექსელის ჰოსტებმა პასუხები VPN კარიბჭის გავლით უნდა დააბრუნონ. როცა ეს კარიბჭე მათი ნაგულისხმევი მარშრუტიზატორი არ არის, პასუხი LAN მარშრუტიზატორთან მიდის, რომელიც ან ყრის მას, ან კერძო წყაროს მისამართით ინტერნეტში გადასცემს. გამოსცადეთ შორეული მხარის ჰოსტიდან და არა კარიბჭიდან: ip route get 10.30.20.15 Linux-ში ან Find-NetRoute -RemoteIPAddress 10.30.20.15 PowerShell-ში აჩვენებს შემდეგ ნახტომს, რომელსაც ჰოსტი რეალურად გამოიყენებს. თუ პასუხი გვირაბის ბოლო წერტილი არ არის, იქ დაამატეთ სტატიკური მარშრუტი ახალი პრეფიქსისთვის.
წყაროს NAT იმ საიტზე, სადაც დაბრუნების მარშრუტი აკლია, ლეგიტიმური ალტერნატივაა და ბევრი hub-and-spoke განლაგება ასე ერიდება ყველა სერვერზე შეხებას. გამოიყენეთ ის ახალ პრეფიქსზე დანიშნულების მხარის კარიბჭეზეც:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEფასი რეალურია. შორეული ჟურნალები წყვეტენ ცალკეული წყაროს მისამართების ჩვენებას და თავდაპირველ ქვექსელზე დაფუძნებული ფაიერვოლის წესები კარიბჭისთვის ერთ წესად იკუმშება. აირჩიეთ ეს განზრახ და არა იმიტომ, რომ მარშრუტი აკლდა.
ფაიერვოლები დაბრუნების გზის მეორე ნახევარია. ზონაზე დაფუძნებული მოწყობილობები ავტომატურად არ ავრცელებენ არსებული გვირაბის ინტერფეისის ზონას ახალ ქვექსელზე და ძველი პრეფიქსისთვის დაწერილი წესი არ დაემთხვევა. დაამატეთ ახალი ქვექსელი ზონას ან წესების წყვილს ორივე მიმართულებით, სანამ IPsec-ს დაადანაშაულებთ.
გადაწყვიტეთ სამი კითხვით და შემდეგ გადაამოწმეთ ტრაფიკით
მოკლე ვარიანტი: მხარის კონფიგურაცია ასახელებს პრეფიქსებს (პოლიტიკაზე დაფუძნებული), თუ ტრაფიკი ინტერფეისში იმარშრუტება (მარშრუტზე დაფუძნებული)? ორივე ბოლო ჩამოთვლის ახალ პრეფიქსს? არსებობს დაბრუნების გზა ახალი ქვექსელიდან თავდაპირველ წყაროს დიაპაზონამდე?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
გადამოწმება ის ადგილია, სადაც ცვლილებების უმეტესობა ნაადრევად იხურება. კარიბჭიდან ping ცოტას ამტკიცებს, რადგან კარიბჭე თავის თავს იღებს წყაროდ და ხშირად ჰოსტისგან განსხვავებულ პოლიტიკას ემთხვევა. გააკეთეთ ping ახალი ქვექსელის ჰოსტიდან, შემდეგ გაუშვით ცვლილების გამომწვევი აპლიკაცია და დააკვირდით მრიცხველებს და არა სტატუსის ხატულას.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showპოლიტიკაზე დაფუძნებულ გვირაბში ip xfrm state-ის მრიცხველები ორივე მიმართულებით უნდა გაიზარდოს; ბრტყელი მრიცხველები ნიშნავს, რომ პაკეტი იმარშრუტება, მაგრამ არ ირჩევა. WireGuard-ში wg show თითო მხარის გადაცემას აჩვენებს და ნულოვანი მიღებული ბაიტით ხელის ჩამორთმევა შორეული მხარის სიაზე ან მის დაბრუნების მარშრუტზე მიუთითებს.
დაასრულეთ პრეფიქსის, მხარის სელექტორის ან მარშრუტის, დაბრუნების გზის გადაწყვეტილების და ფაიერვოლის ჩანაწერის დაფიქსირებით გვირაბის დანარჩენ ინვენტართან ერთად. შემდეგ გადატვირთეთ ერთი კარიბჭე და კვლავ სცადეთ: ხელით დამატებული მარშრუტი ქრება და შემდეგ ადამიანს ეს ხელახლა აღმოჩენა აღარ დასჭირდება.