VPN უკავშირდება, მაგრამ LAN მოწყობილობებამდე ვერ აღწევს: რა უნდა შემოწმდეს
შესასვლელი საკუთარ მისამართზე პასუხობს, სანამ მის უკან არაფერი პასუხობს. მიჰყევით კლიენტის ნაკადს ნაბიჯ-ნაბიჯ, რომ იპოვოთ წარუმატებელი საზღვარი.
ტრაფიკი გვირაბში შედის, შესასვლელი საკუთარ მისამართზე პასუხობს და მის უკან არაფერი პასუხობს. ეს ნიმუში გავრცელებულია და წინააღმდეგობა არ არის: შესასვლელის პასუხი ამტკიცებს, რომ გვირაბი დასრულდა, და არაფერს ამტკიცებს იმის შესახებ, თუ რა ხდება მის მიღმა მისამართებულ პაკეტს. ორი ტესტი ერთსა და იმავე მანქანაზე სხვადასხვა კოდურ გზას იყენებს.
ამიერიდან შეამოწმეთ რაღაც შესასვლელის მეორე მხარეს. შესასვლელის საკუთარი მისამართი გააგრძელებს პასუხს, რამდენადაც გატეხილი იქნება გადაგზავნა.
შესასვლელი პასუხობს საკუთარი სტეკიდან
შესასვლელზე მისამართებული პაკეტი მის ლოკალურ შემავალ გზაზე გადაეცემა, სადაც ბირთვი წყვეტს, მიიღებს თუ არა მას მოსმენილი სოკეტი. შესასვლელის უკან მდებარე ჰოსტზე მისამართებული პაკეტი სამაგიეროდ გადაცემის გზაზე გადაეცემა, სადაც შემოწმებების სხვა ნაკრები მოქმედებს. გადაცემა შეიძლება სრულად გამორთული იყოს, ან ბირთვმა ჩართოს და შემდეგ იგი უარყოს ფილტრის წესმა, რომელიც გვირაბს საერთოდ არ ახსენებს. ამათგან არაფერი არ ზემოქმედებს შესასვლელის საკუთარ პასუხზე, ამიტომ სიმპტომი ასე საიმედოდ ატყუებს.
გვირაბის მეშვეობით მიღწეული ადმინისტრირების გვერდები ასევე პირველ კატეგორიას მიეკუთვნება. ისინი გვირაბის შესახებ მტკიცებულებაა, და არა მის უკან არსებული ქსელის შესახებ.
მიჰყევით ნაკადს პირველ საზღვრამდე, რომელიც მას ჩამოაგდებს
დაიწყეთ კლიენტიდან და დაადასტურეთ მარშრუტი და წყაროს მისამართი, რომელსაც ნაკადი გამოიყენებს. შემდეგ დააკვირდით შესასვლელს, რომ ზუსტად ეს ნაკადი ჩამოდის, და კვლავ იმავე ნაკადს LAN-ისკენ მიდის. თუ ის არასოდეს ჩამოდის, პრობლემა კლიენტის მხარეს ან გვირაბის დაშვებულ პრეფიქსებშია. თუ ჩამოდის და არასოდეს მიდის, პრობლემა გადაცემაში ან წინა გზის ფილტრშია, და ჩაწერამ უკვე თქვა, რომელი.
იგივე ტესტის შესასვლელიდან გაშვება საინტერესო ნახევარს მალავს, რადგან შესასვლელიდან წარმოქმნილ პაკეტს სხვა წყარო და დაბრუნების სხვა მოთხოვნა აქვს. გამოიყენეთ კლიენტის ნაკადი, მისივე წყაროს მისამართით, ყოველ ნაბიჯზე. არასწორ ინტერფეისზე გადაღებული ჩაწერა თავდაჯერებულ სისულელეს იძლევა.
დაბრუნების მარშრუტები და ჰოსტის ფარები ცალ-ცალკე მარცხდება
მას შემდეგ რაც პაკეტი ჰოსტამდე მიაღწევს, კიდევ სამი რამ უნდა შესრულდეს. სერვისი უნდა უსმენდეს იმ მისამართზე, რომელზეც პაკეტი გაიგზავნა, ჰოსტის ფარმა უნდა მიიღოს იგი, და პასუხს უნდა ჰქონდეს დაბრუნების მარშრუტი კლიენტთა აუზისკენ. ეს უკანასკნელი ხშირად მარცხდება, რადგან ჰოსტის ნაგულისხმევი მარშრუტი მიუთითებს მარშრუტიზატორზე, რომელსაც გვირაბის დიაპაზონის შესახებ არასოდეს სმენია. შედეგი არის კავშირი, რომელიც ჰოსტის თვალსაზრისით მყარდება და მეორე მიმართულებით ჩუმად კვდება.
განზრახ შეამოწმეთ დაბრუნების გზა: გაგზავნეთ კლიენტიდან და დააკვირდით დაბრუნებას. ცალმხრივი ჩაწერა წამებში წყვეტს იმას, რასაც საათობრივი ვარაუდი ვერ გადაწყვეტს.
დაადასტურეთ ყოველი ნახტომი კლიენტის წყაროს მისამართით
შეასრულეთ შემოწმებები თანმიმდევრობით და შეინახეთ ყოველი გამოსავალი, რადგან ღირებულება შედარებაშია და არა რომელიმე ცალკე სტრიქონში. ქვემოთ მოცემული ბრძანებები ამაგრებენ წყაროს მისამართს, აჩვენებენ არჩეულ მარშრუტს და იწერენ გადაცემის ორივე მხარეს. შეცვალეთ თქვენი LAN ჰოსტი და გვირაბის ინტერფეისი.
ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20მარშრუტის მოთხოვნა გვიჩვენებს, გაგზავნის თუ არა კლიენტი საერთოდ იმ პაკეტს გვირაბში, ხოლო ping გვიჩვენებს, დაბრუნდა თუ არა რამე ჰოსტიდან. ორი ჩაწერის შედარება ჩამოსვლას გასვლისგან ჰყოფს, რადგან კადრი გვირაბის ინტერფეისზე, რომელსაც LAN-ის ინტერფეისზე ანალოგი არ აქვს, გადაცემის გადაწყვეტილებაა და არა სერვისის უკმარისობა. როცა ორივე ჩაწერა მოთხოვნას აჩვენებს და მხოლოდ ერთი პასუხს, დაბრუნების მარშრუტია დარჩენილი ეჭვმიტანილი.
ჩაწერეთ, რომელმა მისამართმა უპასუხა და რომელი გადაცემული დანიშნულება ვერ შესრულდა. ეს წინადადება ანგარიშს სამოქმედოდ აქცევს იმ მტკიცების ნაცვლად, რომ სერვერი მიუწვდომელია.