საიტ-საიტ VPN-ის პასუხი გვირაბში არ გადის
გვირაბს რომ გვერდს უვლის, პასუხი შორეულ მხარეს მიღებული მარშრუტიზაციის გადაწყვეტილებაა. შეამოწმეთ ჰოსტების ცხრილი, სელექტორები და rp_filter, შემდეგ აირჩიეთ მარშრუტი ან NAT.
დილა ერთ გვირაბს დავუთმე, რომელიც სუფთად ავიდა და ტრაფიკს ზუსტად ერთი მიმართულებით გადაადგილებდა: ფილიალი სათავო ოფისის ფაილურ სერვერს აღწევდა, და ყოველი კავშირი, რომელიც სათავო ოფისიდან ფილიალში იხსნებოდა, პირველივე SYN-ზე იღუპებოდა. SA-ები აწეული იყო, გვირაბის მრიცხველები იზრდებოდა, და ხელის ჩამორთმევა არასდროს ყოფილა პრობლემა. პასუხი იმარშრუტებოდა იქ, სადაც გვირაბი არ ფარავს, და ეს არჩევანი შორეულ მხარეს ეკუთვნის. საიტ-საიტ VPN მხოლოდ იმ პაკეტებს გადააქვს, რომლებსაც ჰოსტი კარიბჭეს გადასცემს, და ყოველი ჰოსტი ამ არჩევანს ცალკე აკეთებს, ყოველ მიმართულებით, საკუთარი მარშრუტიზაციის ცხრილიდან.
ორივე მიმართულება ცალ-ცალკე იმარშრუტება
IP საუბრის მიმართულების არავითარ მეხსიერებას არ ინახავს. ყოველი ჰოსტი, რომელიც პაკეტს აგზავნის, ასრულებს საკუთარ ყველაზე გრძელი პრეფიქსის ძიებას, ირჩევს ერთ მომდევნო ნახტომს და ივიწყებს გადაწყვეტილებას. მოთხოვნა და პასუხი ორი დაუკავშირებელი პაკეტია, რომლებიც შემთხვევით ერთსა და იმავე კავშირს ეკუთვნის, გვირაბი კი ერთი ნახტომია, რომელსაც რომელიმე მათგანი გამოიყენებს ან არ გამოიყენებს. IKE-ის გაცვლაში არაფერი ასწავლის შორეულ სერვერს, როგორ მიაღწიოს თქვენს ქვექსელს; მოლაპარაკება მხოლოდ იმაზე თანხმდება, რომელი პრეფიქსების დაშიფვრა შეიძლება.
ეს შეთანხმება მეორე კარიბჭეა. strongSwan-ში ტრაფიკის სელექტორებია leftsubnet და rightsubnet, და პაკეტი, რომლის წყარო ან დანიშნულება შეთანხმებული წყვილის გარეთ რჩება, არ იშიფრება, რაც არ უნდა თქვას მარშრუტიზაციის ცხრილმა. პრეფიქსი, რომელიც გვირაბში იმარშრუტება, მაგრამ სელექტორებში არ არის, წყნარი ცალმხრივი მარცხია: მარშრუტი სწორად გამოიყურება, პაკეტი მაინც ღიად გადის ან იშორება, და მხოლოდ charon-ის ჟურნალი წუწუნებს.
შორეულმა ჰოსტმა თქვენი გვირაბის შესახებ არაფერი იცის
შორეული LAN-ის შიგნით პასუხი თქვენი კლიენტის მისამართზე გაგზავნილი ჩვეულებრივი პაკეტია. დანიშნულების ჰოსტი ვერ ხედავს IPsec სათაურს და არ აქვს მიზეზი, უპირატესობა მისცეს VPN კარიბჭეს; ეძებს თქვენს პრეფიქსს, ვერ პოულობს რაიმე უფრო კონკრეტულს თავის ნაგულისხმევ მარშრუტზე და მიჰყვება მას. თუ ნაგულისხმევი მთავარ ფაირვოლზე მიუთითებს, ფაირვოლს ან აქვს დაბრუნების მარშრუტი გვირაბში, ან არა. როცა არ აქვს, იღებთ წყნარ გადაგდებას, ICMP unreachable-ს, ან პასუხს, რომელიც ინტერნეტისკენ მიმართული ინტერფეისიდან გადის და იღუპება.
მეორე ინტერფეისი საკმარისია ამის გასატეხად, მაშინაც კი როცა მარშრუტი არსებობს. NAS მართვის ბმულით სხვა VLAN-ში, სერვერი სარეზერვო uplink-ით, პოლიტიკის წესი, რომელიც ერთ წყაროების დიაპაზონს მეორე ცხრილში აგზავნის: ამათგან ნებისმიერს შეუძლია პასუხის დაჭერა. Linux-ზე ip rule show და ip route show table all იმ წესებსა და ცხრილებს აჩვენებს, რომლებსაც ნაგულისხმევი სია მალავს.
წაიკითხეთ გადაწყვეტილება იმ მანქანაზე, რომელიც პასუხს აგზავნის
ჰკითხეთ ბირთვს, სანამ რამეს შეცვლით, და მიეცით წყაროს მისამართი, რადგან წყაროზე დამოკიდებული წესები პასუხს ცვლის.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"გამოსავალი ასახელებს გამავალ ინტერფეისს და მომდევნო ნახტომს. თუ ინტერფეისი ის არ არის, რომელიც VPN კარიბჭისკენ იყურება, ხარვეზი იპოვეთ, და დარჩენილი სამუშაო მარშრუტის ადგილის არჩევაა. კარიბჭიდან ping აქ ცოტას ამტკიცებს: ის მისამართით პასუხობს, რომელიც შორეულ ჰოსტს განლაგება შეუძლია, და არა თქვენი ლეპტოპის მისამართით.
Windows-ზე ეკვივალენტებია Find-NetRoute -RemoteIPAddress 10.10.5.10 გადაწყვეტილებისთვის და Get-NetRoute ცხრილისთვის. New-NetRoute-ით დამატებული მარშრუტი, რომელსაც ნაგულისხმევზე მაღალი მეტრიკა აქვს, წყნარად აგებს, ამიტომ წაიკითხეთ მეტრიკის სვეტი და არა ჩანაწერი. შემდეგ დაადასტურეთ პაკეტებით: tcpdump -ni any "host 10.10.5.10 and tcp port 445" შორეულ LAN ინტერფეისზე მოთხოვნას აჩვენებს, და იგივე ფილტრი გვირაბის მხარეს აჩვენებს, დაბრუნდა თუ არა პასუხი. მოთხოვნა ჩანს, პასუხი არა — ნიშნავს, რომ პასუხი სხვაგან გაიმარშრუტა ან გადააგდეს; პასუხი არასწორ ინტერფეისზე ცოდვილს გაძლევთ მანამ, სანამ მარშრუტს შეეხებით.
როცა სერვერის კარიბჭე VPN-ის ბოლო წერტილი არ არის
ბევრი საიტი ფაირვოლს ათავსებს სერვერებსა და კონცენტრატორს შორის. ის ფაირვოლი პასუხს გადაამისამართებს, ამიტომ მას სჭირდება მარშრუტი თქვენი კლიენტის პრეფიქსისთვის VPN კარიბჭისკენ, და გადამისამართების პოლიტიკა ორივე მიმართულებით. მდგომარეობის შემნახველი მოწყობილობები აუარესებენ: მოთხოვნამ ფაირვოლი გადაკვეთა იმ LAN ჰოსტიდან, რომელიც მან დაუშვა, პასუხი ახლა სხვა მიმართულებიდან მოდის, და კავშირის თვალთვალის ჩანაწერი აღარ ემთხვევა, ამიტომ პაკეტი უარყოფის ნაცვლად არასწორად ჩაითვლება და გადააგდება. ამიტომ პოლიტიკის ჟურნალი ცარიელი ჩანს, სანამ ტრაფიკი ქრება.
კარიბჭეს საკუთარი მეორე ფილტრი აქვს. Linux-ის უკუ მარშრუტის ფილტრაცია აგდებს პაკეტებს, რომელთა წყაროც მიუწვდომელია იმ ინტერფეისიდან, რომლითაც ისინი მოვიდნენ, და ეს ზუსტად ლეგიტიმური ასიმეტრიული დაბრუნების გზის ფორმაა. strongSwan-ის გადამისამართების გზამკვლევი სწორედ ამ მიზეზით მოითხოვს net.ipv4.ip_forward-ს და შესუსტებულ net.ipv4.conf.all.rp_filter-ს. 1-ის მკაცრი მნიშვნელობა რომელიმე კარიბჭეზე წყნარად ამტვრევს სწორ მარშრუტს, და nstat -az აჩვენებს გადაგდებებს, თუ იცით, სად უნდა შეხედოთ.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
დაამარშრუტეთ ან თარგმნეთ, შემდეგ ორივე მიმართულებით შეამოწმეთ
ორი შეკეთება ეკვივალენტური არ არის. მარშრუტის დამატება კლიენტის მისამართს უცვლელად ინახავს, ამიტომ წყაროზე დაფუძნებული წესები, აუდიტის ჟურნალები და დამრეკის ჩამწერი აპლიკაციები აგრძელებენ მუშაობას; ფასი ის არის, რომ გადაწყვეტილების მიმღებ ყოველ ნახტომს მარშრუტი სჭირდება, ეს კი მეტი ადგილია შეცდომისთვის. ნიღაბი შორეულ კარიბჭეზე დაბრუნების გზას ერთ ნახტომამდე ამცირებს, რადგან პასუხი ახლა თავად კარიბჭეზეა მიმართული, და მალავს, რომელმა კლიენტმა რა გააკეთა.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEაირჩიეთ ის გააზრებულად: როგორც კი კლიენტები კარიბჭის მისამართად გამოჩნდებიან, წყაროზე დაფუძნებული ACL-ები წყვეტენ მათ გარჩევას, და conntrack-მა უნდა შეინარჩუნოს დაკავშირება, რომ პასუხი უკან გვირაბში გადაიწეროს. თუ სელექტორები კვლავ გამორიცხავენ კლიენტის პრეფიქსს, NAT არაფერს ცვლის, რადგან მოთხოვნა გვირაბში არასდროს შესულა.
სანამ გამოსწორებულს უწოდებთ, ზედიზედ ოთხი რამ დაადასტურეთ: მარშრუტი იმ ჰოსტზე, რომელიც პასუხს აგზავნის, მარშრუტი ყოველ გადამამისამართებელ ნახტომზე, სელექტორები, რომლებიც ორივე პრეფიქსს ფარავს, და ჩანაწერი, რომელიც აჩვენებს, რომ პასუხი გვირაბში თქვენს მოსალოდნელ წყაროსთან ერთად შედის. შემდეგ გაიმეორეთ ტესტი მეორე საიტიდან. ერთი მიმართულების გავლა ნახევრად ღია დიზაინია, და მეორე მიმართულება ჩვეულებრივ იმისგან განსხვავებული მიზეზით ფარცხდება, რაც ახლა გაასწორეთ.