რატომ ვერ აღწევს თქვენი LAN სერვისს VPN კლიენტზე

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

გატეხილი გვირაბი არ არის

ორივე ბოლო კერძო დიაპაზონებში ზის, რაც ჩვეულებრივი შემთხვევაა და არა არასწორი კონფიგურაცია. 10.8.0.6 მისამართი გვირაბის შიგნით რეალურია და სხვაგან არსად არსებობს, ამიტომ LAN-ს არ აქვს მიზეზი იქ რამე გაუგზავნოს. მარშრუტიზაციაზე ხელის მოკიდებამდე დაადასტურეთ, რომ სერვისი საერთოდ ხელმისაწვდომია გვირაბის შიგნით: კლიენტზე ss -ltn გვიჩვენებს, მიბმულია თუ არა მსმენელი 127.0.0.1-ზე, LAN-ის ინტერფეისზე თუ გვირაბის მისამართზე. მხოლოდ loopback-ზე მიბმული დემონი თავის გარდა არავის პასუხობს, და ამას ვერც ერთი მარშრუტი, DNAT თუ პორტის გადამისამართება ვერ შეცვლის.

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

მარშრუტის ფორმა: უთხარით LAN-ს, სად არის აუზი

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

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

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

push "route 192.168.1.0 255.255.255.0"

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

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

NAT-ის ფორმა: DNAT შიგნით, და ის SNAT ხაზი, რომელსაც ყველა გამოტოვებს

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

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

სამომხმარებლო firmware იყენებს საკუთარ ჯაჭვის სახელებს და ამ თარგმანს თქვენთვის არ ქმნის. Tomato-ზე შემომავალი წესი ხვდება WANPREROUTING-ში და შემდეგ wanin-ის მსგავს ფილტრის ჯაჭვში, და სრულად რომ გამოიყურებოდეს, წესების ნაკრებს მაინც სჭირდება ხელით დაწერილი POSTROUTING ხაზი. ეს firmware-ის ხარვეზი არ არის; ეს წესების ნაკრებია, რომელიც მხოლოდ შემომავალი ტრაფიკისთვისაა დაწერილი.

რატომ აგდებს სწორად რომ გამოიყურებოდეს წესი მაინც პაკეტს

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

• ჯაჭვების რიგი. iptables -I ზემოთ ჩასვამს და -A ბოლოში ამატებს, ამიტომ ადრინდელი დამშვები ან დამბლოკავი წესი პირველი წყვეტს.
• არასწორი ჯაჭვი. თავად როუტერისკენ მიმართული ტრაფიკი INPUT-ს კვეთს, და გადამისამართებული ტრაფიკი მას არასდროს ეხება. ერთი სერვისის გამოქვეყნებას შეიძლება ორივეში სჭირდებოდეს წესები.
• მიმართულების დროშები. -i tun0 ემთხვევა კლიენტებიდან მომავალ ტრაფიკს და -o tun0 მათკენ მიმავალ ტრაფიკს. არასწორი დროშით REJECT ბლოკავს იმას, რაც არ გინდოდათ.
• წყაროს შეზღუდვა. გადამისამართება, რომელიც ერთ კლიენტის მისამართს იღებს, იმ კლიენტიდან მუშაობს და ყველა სხვა წყაროს სიტყვის გარეშე აგდებს.

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

ლოკალური გადამისამართება, როცა LAN-ზე ვერაფერი შეიცვლება

SSH-ის ლოკალური გადამისამართება მთელ კითხვას თავს არიდებს. მას არ სჭირდება მარშრუტი LAN-ზე, კლიენტის firewall-ის თანამშრომლობა, და არსად გამოქვეყნებული პორტი:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

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

სანამ კიდევ ერთ წესს დაამატებთ, შეამოწმეთ ორივე მიმართულება

თარგმანი კვალს ტოვებს, და მათი კითხვა ვარაუდზე უკეთესია. VPN-ის ჰოსტზე conntrack -L გვიჩვენებს, მოხდა თუ არა თარგმანი საერთოდ, iptables -t nat -L -n -v გვიჩვენებს, გადაადგილდნენ თუ არა მრიცხველები, და tcpdump -ni any port 3000 გვიჩვენებს, რომელი წყაროს მისამართი რეალურად მოვიდა. კლიენტზე ss -ltn ადასტურებს, რომ მსმენელი იმ მისამართზეა, რომლამდეც გვირაბს მიღწევა შეუძლია.

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