OpenVPN-ზე ხართ დაკავშირებული, მაგრამ ping და SMB წვდომა არ მუშაობს? შეამოწმეთ სამი კარიბჭე

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

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

გადაცემა FORWARD ჯაჭვის პოლიტიკაა

OpenVPN-ის მსმენელის მიღება INPUT-ზე ხდება, ამიტომ გვირაბი შეიძლება დაკავშირდეს, მაშინ როცა LAN-ისკენ მიმავალი ყველა პაკეტი იშლება. ტრაფიკი, რომელიც მოდის tun0 -დან და გადის LAN ინტერფეისით, გადის FORWARD-ზე, და იქ ნაგულისხმევი DROP პოლიტიკის მქონე ჰოსტი მას ჩუმად ყრის. სანამ სხვა რამეს შეეხებით, შეამოწმეთ sysctl და ჯაჭვი: sysctl net.ipv4.ip_forward და iptables -L FORWARD -v -n.

ნება დართეთ სასურველ მიმართულებას და მასთან დაკავშირებულ პასუხებს, მაგალითად accept წესი გვირაბის ინტერფეისიდან LAN ინტერფეისამდე და stateful წესი established და related ტრაფიკისთვის. თუ LAN სხვა მარშრუტიზატორის უკანაა, მას სჭირდება დაბრუნების მარშრუტი კლიენტების აუზამდე ან source NAT VPN სერვერზე. დაადასტურეთ ეს გზა ერთი ping-ით, სანამ ახალ წესებს დაამატებთ, რადგან წესი, რომელსაც ვერ მიაღწევთ, არასდროს გამოჩნდება მრიცხველში.

SMB-ს ერთზე მეტი პორტი სჭირდება

ფაილების გაზიარება ერთი TCP 445 საუბარი არ არის. აღმოჩენა იყენებს UDP 137 და 138-ს, ძველი NetBIOS სესიები იყენებენ TCP 139-ს, ხოლო თანამედროვე SMB სესიები იყენებენ TCP 445-ს. წესი, რომელიც მხოლოდ 445-ს ხსნის, ქმნის იმ გამაღიზიანებელ შემთხვევას, როცა დაკავშირებული დისკი მუშაობს, ხოლო ქსელის დათვალიერება არა, ან პირიქით.

გვირაბში დიდი გადაცემები ასევე ხვდება MSS პრობლემებს, რომლებიც გატეხილ გაზიარებას ჰგავს. SYN, რომელიც LAN-ის სრულ სეგმენტის ზომას აცხადებს, იშლება გვირაბის უფრო მცირე MTU-ით, და კავშირი ჩერდება ხელის ჩამორთმევის შემდეგ. MSS-ის შეკვრა გადაცემის გზაზე, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, აშორებს ამ ტიპის გაჩერებას. შეამოწმეთ რამდენიმე მეგაბაიტის ასლით და არა საქაღალდის სიით, რადგან პატარა პასუხები გადის მაშინაც, როცა დიდი გადაცემები არ გადის.

გვირაბის ადაპტერი ახალი ქსელური პროფილის სახით მოდის

Windows თითოეულ ადაპტერს ქსელურ პროფილში აკლასიფიცირებს, და ახალი გვირაბის ადაპტერი ჩვეულებრივ Public-ში ხვდება, სადაც ფაილების და პრინტერების გაზიარების წესები დაბლოკილია. ეს ფაილური სერვერის ჰოსტის firewall-ის გადაწყვეტილებაა და არა VPN სერვერის მარშრუტიზაციის პრობლემა. შეცვალეთ კატეგორია განზრახ Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private -ით მას შემდეგ, რაც დაადასტურებთ, რომ პოლიტიკა ნებას იძლევა, რადგან კატეგორია ასევე ცვლის, რომელი შემომავალი წესები მოქმედებს.

იგივე პროფილი ხსნის ping-ს, რომელიც ვერ გადის, მაშინ როცა TCP 445 წარმატებულია: echo მოთხოვნები Public-ში ნაგულისხმევად იშლება.

სახელები დამოუკიდებლად არ კვეთენ მარშრუტიზებულ გვირაბს

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

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

სცადეთ ერთი ფენა ერთდროულად და წაიკითხეთ პირველი ჩავარდნა

ადით ზემოთ: გააკეთეთ ping გვირაბის კარიბჭეზე, გააკეთეთ ping LAN ჰოსტზე მისამართით, შემდეგ გახსენით სერვისის პორტი Test-NetConnection -ComputerName 10.8.0.5 -Port 445 -ით და მხოლოდ ამის შემდეგ აუთენტიფიცირდით გაზიარებაზე. პირველი ნაბიჯი, რომელიც ვარდება, ის ფენაა, რომელიც უნდა გამოსწორდეს, და ყოველი შემდგომი ნაბიჯი ხმაურია, სანამ ის არ გაივლის. ping, რომელიც პასუხობს, მაშინ როცა პორტი დახურული რჩება, მიუთითებს თავად ფაილური სერვერის firewall-ზე, ხოლო პორტი, რომელიც იხსნება ჩუმი ping-ების მიუხედავად, მიუთითებს ICMP ფილტრაციაზე. ჩაწერეთ პირველი წარუმატებელი ნაბიჯი, სანამ რამეს შეცვლით, რადგან მეორე ცვლილება პირველის შედეგს მალავს.

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

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