OpenVPN-ით LAN-ზე წვდომა გატეხილია? შეამოწმეთ ზონები, მარშრუტები და დაბრუნების გზა

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

რომელი ფილტრი ხედავს LAN-ისკენ მიმავალ პაკეტს

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

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

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

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

რატომ სჭირდება გაყოფილ გვირაბს გაგზავნილი პრეფიქსი

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

push "route 192.168.50.0 255.255.255.0"

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

ip route show | grep 192.168.50

საიტ-საიტი პარტნიორი მეტს ითხოვს, ვიდრე გაგზავნას. სერვერმა უნდა ისწავლოს, რომელი პრეფიქსები დგას ამ პარტნიორის უკან, რასაც აკეთებს ხაზი iroute მის client-config-dir ფაილში, და მის საკუთარ ცხრილსაც სჭირდება გვირაბში შესაბამისი მარშრუტი.

პასუხს სჭირდება მისაწვდომი მისამართი

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

tcpdump -ni tun0 host 192.168.50.20

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

კიბე, რომელიც სწორ ადგილას მთავრდება

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

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

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

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