VPN კლიენტი LAN სერვერზე: რატომ გადიან პასუხები არასწორი გზით

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

პასუხი ახალი პაკეტია, არა გზის უკუღმა სვლა

სასარგებლოა იმ იდეის მიტოვება, რომ პასუხი იმავე გზით ბრუნდება, რომლითაც მოთხოვნა წავიდა. მარშრუტიზაცია განისაზღვრება თითოეული პაკეტისა და თითოეული მიმართულებისთვის, გამომგზავნ ჰოსტზე. გვირაბის შიგნით 10.64.0.23-იდან მოსული მოთხოვნა დაბრუნების გზას არ ქმნის; როცა ჰოსტი პასუხობს, ეს პასუხი ახალ პაკეტად შედარებულია ცხრილს და გადის იმ მარშრუტით, რომელიც იმარჯვებს.

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

დანარჩენის კითხვისას ორი ქვექსელი გქონდეთ თავში. ერთი არის VPN მისამართების აუზი, საიდანაც მოდიან დისტანციური კლიენტები, ამ მაგალითში 10.64.0.0/24. მეორე არის LAN, რომელიც უნდა გააგრძელოს მუშაობა, 172.16.24.0/24 თავისი მარშრუტიზატორით 172.16.24.1-ზე. ხარვეზი ის არის, რომ მათ შორის ტრაფიკი ნაგულისხმევი მარშრუტით განისაზღვრება.

დაამტკიცეთ ეს ჩაწერით და ძიებით

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

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

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

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

დააყენეთ ყველაზე ვიწრო მარშრუტი, რომელიც გვირაბს აღემატება

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

გამოიყენეთ replace add-ის ნაცვლად, რადგან ხელახლა დაკავშირებულ კლიენტს უკვე დაყენებული აქვს თავისი ჩანაწერი, და მეორე add ცდება არსებული მარშრუტის შეცდომით, რომელიც ნებართვის პრობლემად იკითხება. Windows ჰოსტზე ეკვივალენტია route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, სადაც -p ჩანაწერს გადატვირთვებს შორის ინახავს, რადგან კლიენტმა შეიძლება ცხრილი თავიდან ააგოს, როცა გვირაბი ისევ ამოვა. თანამედროვე Windows ჰოსტზე მხარდაჭერილი ეკვივალენტია New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, ხოლო ძველი route ბრძანება შენარჩუნებულია როგორც მემკვიდრეობითი ფორმა.

ერთი დეტალი წყვეტს, ეს სწორია თუ მხოლოდ დამაჯერებელი: შემდეგი ნახტომი უნდა იყოს მარშრუტიზატორი, რომელიც ნამდვილად ფლობს კლიენტებზე დაბრუნების გზას. მარშრუტის იმ მისამართზე მიმართვა, რომელზეც თავად გვირაბით აღწევენ, ქმნის მარყუჟს, რომელიც წყვეტილი დანაკარგის სახით ვლინდება და არა სუფთა ხარვეზის. სანამ ხაზს დაადასტურებთ, დარწმუნდით, რომ შემდეგი ნახტომი LAN ქვექსელშია.

შეინარჩუნეთ პასუხი ხელახალი დაკავშირების შემდეგ

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

მდგომარეობიანი ფაირვოლი მაინც შეიძლება ამარცხებდეს სწორ მარშრუტს. თუ ჩაწერა ახლა აჩვენებს, რომ პასუხი eth0-იდან გადის, და კლიენტი მაინც დროის ამოწურვას იღებს, შეამოწმეთ, ხომ არ ყრის ჰოსტი პაკეტს გაგზავნამდე. უკუგზის მკაცრი ფილტრაცია და net.ipv4.conf.all.rp_filter 1-ზე დაყენებული ყრის იმ პაკეტებს, რომელთა წყაროც იმ ინტერფეისიდან უკან არ გაიმარშრუტებოდა, საიდანაც მოვიდა, და ეს ზუსტად ის ასიმეტრიული შემთხვევაა, რომელიც ახლახან შექმენით და შემდეგ გამოასწორეთ, ხოლო conntrack-ის მდგომარეობა იგივე ამბავს ყვება გადამისამართებული პორტებისთვის.

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