VPN და სახლის LAN ერთსა და იმავე ქვექსელშია: ჯერ მარშრუტი გაიარეთ
ორივე ადაპტერი ითხოვს 192.168.1.0/24-ს და მხოლოდ ერთი მარშრუტი იმარჯვებს. გაიარეთ ადაპტერების სია, გამარჯვებული მარშრუტი და დაბრუნების გზა, სანამ ხელახლა დანომრავთ ან DNS-ს დაადანაშაულებთ.
თქვენ უკავშირდებით ოფისის VPN-ს, სისტემური უჯრის ხატულა მწვანდება, ინტრანეტი იტვირთება და ორ მეტრში მდგარი პრინტერი პასუხის გაცემას წყვეტს. საზიარო საქაღალდე, რომელიც დილით მუშაობდა, იმავე მანქანაზე დროის ამოწურვას იწვევს და არც ერთი ჟურნალი პრინტერს არ იხსენიებს. პირველი რეაქცია DNS-ია, რადგან გადაუწყვეტელი სახელი არარსებულ სახელს ჰგავს, მაგრამ პრობლემა მისამართშია: ორი ადაპტერი ახლა ითხოვს 192.168.1.0/24-ს და მხოლოდ ერთ მარშრუტს შეუძლია ამ პრეფიქსის მოგება. გაიარეთ ეს სწორედ ამ თანმიმდევრობით და დაინახავთ, რომელმა ადაპტერმა აიღო იგი, სანამ რამეს შეცვლით.
დაიწყეთ სიმპტომიდან და არა გვირაბიდან
ნიშანი მოცულობაა. თუ ინტრანეტი მუშაობს და ყველა ლოკალური მოწყობილობა ვარდება, გვირაბი ჯანმრთელია, ლოკალური გზა კი არა. თუ ლოკალური მოწყობილობები მუშაობენ და ინტრანეტი ვარდება, პირიქით. თუ ერთი ჰოსტის გარდა ყველაფერი მუშაობს, თქვენ წინაშეა ერთი მისამართი, რომელიც ორივე მხარეს არსებობს.
ჩაწერეთ ერთი ლოკალური და ერთი შორეული მისამართი, სანამ რომელიმე პარამეტრს შეეხებით. „პრინტერი“ შესამოწმებელი არ არის; 192.168.1.40 არის. ეს ერთი ნაბიჯი ხელს უშლის ამ პრობლემის ყველაზე გავრცელებულ დაკარგულ საათს, კერძოდ DNS-ის პარამეტრების გადაწერას მარშრუტიზაციის გადაწყვეტილების გამო.
ნაბიჯი 1: ნახეთ ორივე ადაპტერი, რომლებიც პრეფიქსს ითხოვენ
გახსენით ქსელური კავშირები (ncpa.cpl) და წაიკითხეთ ორივე ადაპტერი გვერდიგვერდ. Ethernet-ის ადაპტერი აჩვენებს 192.168.1.50/24-ს 192.168.1.1 კარიბჭით. VPN-ის ადაპტერი აჩვენებს 192.168.1.201/24-ს, რომელიც სერვერმა გამოგზავნა. ორივე ლეგიტიმურია, ორივე ფიქრობს, რომ პრეფიქსი on-link-ია, და სტეკი მისთვის ერთ მარშრუტს შეინახავს.
Get-NetIPAddress -AddressFamily IPv4 მისამართებს ჩამოთვლის, ხოლო Get-NetIPInterface | Sort-Object InterfaceMetric აჩვენებს თანმიმდევრობას, რომლითაც სტეკი მათ გამოიყენებს. სწორედ ის მეტრიკის სვეტია გადაწყვეტილება, რომლის წაკითხვასაც აპირებთ, ამიტომ ჩაწერეთ რიცხვები და ნუ შეეცდებით დამახსოვრებას.
უიარაღოდ უარყავით DNS-ის თეორია: Resolve-DnsName printer.office.lan აბრუნებს იმავე მისამართს, რაც გუშინ. სახელი გადაწყდა; შემდეგ პაკეტი არასწორი ადაპტერიდან გავიდა. აქ ორი წუთი ნახევარ დღეს ზოგავს გადამწყვეტის პარამეტრებში.
ნაბიჯი 2: წაიკითხეთ მარშრუტი, რომელმაც ნამდვილად მოიგო
Find-NetRoute -RemoteIPAddress 192.168.1.40 ბეჭდავს ინტერფეისს, მომდევნო ნახტომს და წყაროს, რომელსაც სტეკი ამ მისამართისთვის გამოიყენებდა. ეს გამონატანი მიიღეთ პასუხად და არა მინიშნებად. route print -4 მთელ ცხრილს იძლევა, როცა გსურთ ნახოთ რომელი ჩანაწერი დამარცხდა და რამდენით.
სპეციფიკა იმარჯვებს განზრახვაზე. გამოგზავნილი 192.168.0.0/25 ამარცხებს ლოკალურ 192.168.0.0/24-ს, რადგან პრეფიქსი გრძელია, ამიტომ 192.168.0.0-დან 192.168.0.127-მდე გვირაბით გადის, ზედა ნახევარი კი ლოკალური რჩება. ნახევარი LAN-ის გაქრობა შეცდომის შეტყობინების გარეშე ამ ცხრილისთვის სწორი ქცევაა.
tracert -d 192.168.1.40 ადასტურებს ამას ცხრილის გარედან: თუ პირველი ნახტომი გვირაბის მისამართია და არა თქვენი როუტერი, მაშინ მარშრუტი მთელი ამბავია. Linux-ზე იგივე კითხვაა ip route get 192.168.1.40, რომელიც წყაროს მისამართს და მოწყობილობას ერთ სტრიქონში ბეჭდავს. როცა პასუხი tun0-ს ახსენებს, შეწყვიტეთ ბრაუზერზე ყურება.
ნაბიჯი 3: შეამოწმეთ დაბრუნების გზა, სანამ კლიენტს დაადანაშაულებთ
სწორი წინა მარშრუტიც ვარდება, თუ შორეულ მხარეს პასუხის გაცემა არ შეუძლია. როცა კლიენტის LAN-ს გვირაბით აღწევენ, ამ LAN-ის კარიბჭემ უნდა იცოდეს, სად ცხოვრობს გვირაბის აუზი: ip route add 10.8.0.0/24 via 192.168.1.12 იმ როუტერზე, და push „route 192.168.1.0 255.255.255.0“ სერვერიდან, რათა კლიენტებმა დაბრუნების გზა იცოდნენ.
პირველი ჩანაწერის გარეშე პასუხი სამიზნეს ტოვებს ნაგულისხმევი კარიბჭისკენ, რომელიც კერძო მისამართს პროვაიდერს გადასცემს და ყრის. სიმპტომი ცალმხრივია და ადვილად არასწორად იკითხება: მოთხოვნები tun0-ზე ჩანს, პასუხები — არასდროს.
VPN ჰოსტზე masquerade წესი აუქმებს იმ სტატიკური მარშრუტის საჭიროებას: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. ის ასევე მალავს ნამდვილ წყაროს მისამართებს, რაც ყოველ შემდგომ ჟურნალის კითხვას ართულებს. არასწორი ნაგულისხმევი კარიბჭის მქონე სამიზნე ჰოსტი იმავე სიჩუმეს იწვევს: საუკეთესო შემთხვევაში ICMP გადამისამართება, ჩვეულებრივ კი შავი ხვრელი, ამიტომ ჩაწერა ორივე ბოლოზეა საჭირო.
ნაბიჯი 4: აირჩიეთ შეკეთება, რომელთანაც შეგიძლიათ იცხოვროთ
ამისთვის ხუთი შეკეთება გამოიყენება და ისინი ურთიერთშემცვლელი არ არის. აირჩიეთ იმის მიხედვით, რა უნდა დარჩეს ხელმისაწვდომი ერთდროულად და არა იმის მიხედვით, რომელი ბრძანებაა უფრო მოკლე.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
მეტრიკები იაფი ვარიანტია და ის, რასაც ხალხი პირველად მიმართავს. ცვლილება ინტერფეისს ეხება, ამიტომ მუშაობს, სანამ გვირაბი აწეულია, და მისი ადგილი კლიენტის გვერდით სკრიპტშია და არა shell-ში, რომელსაც დაივიწყებთ. მას არ შეუძლია ერთდროული წვდომა იმავე მისამართზე ორ ქსელში, და სწორედ ეს ზღვარი აგზავნის ყველა დანარჩენს ცხრილის ქვევით.
სახლის LAN-ის ხელახლა დანომვრა 10.10.0.0/24-ზე სუფთა გადაწყვეტაა: DHCP-ის ერთი იჯარის განახლება პლუს ძველ დიაპაზონს ხსენებული რეზერვაციები, ბეჭდვის რიგები და ხისტად ჩაწერილი მისამართები. ოფისის მხარის ხელახლა დანომვრა ჩვეულებრივ თქვენი გადაწყვეტილება არ არის. IPv6 მთლიანად აშორებს შეჯახებას, როცა ორივე ქსელი ატარებს მას, fd00::/8-დან უნიკალური ლოკალური პრეფიქსით დასამახსოვრებელი რაღაცის ნაცვლად, მაგრამ აპლიკაცია TCP-ზე შეამოწმეთ და არა ping-ით, რადგან ICMP შეიძლება მუშაობდეს, სანამ სერვისი არ მუშაობს.
OpenVPN-ის საკუთარი თარგმანის ოპცია ბოლო საშუალებაა, რომელიც სერვერიდან კლიენტისთვის დამახასიათებელ დირექტორიის ჩანაწერში იგზავნება. ოპციის სახელის შემდეგ ის იღებს ოთხ პარამეტრს — მიმართულება, ქსელი, ნეტმასკა და ფსევდონიმი — და ფსევდონიმი სავალდებულოა: push "route 192.168.2.0 255.255.255.0" და push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". ქსელი და ნეტმასკა ის დიაპაზონია, რომელსაც კლიენტი ხედავს (192.168.2.0/24), ფსევდონიმი სერვერის მხარეს ნამდვილი ოფისის დიაპაზონია (192.168.1.0/24), ხოლო გამოგზავნილი მარშრუტი ამის მიღწევადს ხდის იმ ხილულ დიაპაზონს. შემდეგ ოფისი ამ კლიენტს 192.168.2.x-ის ქვეშ ეჩვენება. დააფიქსირეთ შესაბამისობა პროფილში, თორემ შემდეგი ადამიანი მას მარშრუტიზაციის ხარვეზად გამართავს.
ერთი სერვისის გამოქვეყნება თარგმანის ვიწრო ვარიანტია და საერთოდ არ სჭირდება OpenVPN-ის ოპცია. VPN ჰოსტზე DNAT წესი ერთ პორტს ხელახლა აქვეყნებს, ამიტომ LAN ინარჩუნებს თავის მისამართებს და სერვისს აღწევს იმ ჰოსტის მისამართზე, რომელიც უკვე იცის. ფასი ჩვეულებრივია: სერვისი VPN ჰოსტს წყაროდ ხედავს, ამიტომ კლიენტების მიხედვით ჟურნალები და უკუძიება აზრს კარგავს. ეს ფარავს ერთ ბეჭდვის რიგს ან ერთ ადმინის გვერდს და არა ორივე მხარის ჰოსტებს, რომლებიც ერთმანეთს აღწევენ.
რა მაინც არ იმუშავებს, და რა უნდა ჩაიწეროს
მაუწყებლობა არ გადის მარშრუტიზებულ გვირაბში. DLNA, UPnP, NetBIOS-ის დათვალიერება და Wake-on-LAN დამოკიდებულია მაუწყებლობაზე ან მრავალმაუწყებლობაზე, რომელსაც tun მოწყობილობა არ ატარებს, ამიტომ არც ერთი მარშრუტი არ ასწორებს აღმოჩენას. dev tap-ით ხიდი აფართოებს სეგმენტს და მასთან ერთად DHCP მაუწყებლობებს, ARP-ს და ყველა სხვა აღმოჩენის პაკეტს; უპირატესობა მიანიჭეთ unicast ჰოსტის მარშრუტს, მაგალითად route 192.168.2.1 255.255.255.255, შორეული როუტერის LAN-ის მხარის მისამართისთვის.
ორი როუტერი, რომლებიც ორივე 192.168.1.1-ს იყენებს იმავე გზაზე, ერთი და იმავე პრობლემის ოჯახს მიეკუთვნება: ლოკალური მისამართი ყოველთვის იმარჯვებს, ამიტომ შორეული როუტერის გვერდი მიუწვდომელი რჩება, სანამ ერთი LAN არ გადავა. მეორე ადაპტერის დამატება ორივე შემთხვევაში არაფერს ცვლის.
ჩაწერეთ მტკიცებულებები, სანამ რამეს შეასწორებთ: ip route get ან Find-NetRoute, ping -c 3 შესაბამის მისამართზე, traceroute, და tcpdump -ni tun0 icmp კლიენტზე, შემდეგ მარშრუტიზაციის ცხრილი და NAT მთვლელები სერვერზე. ping, რომელიც ერთი მიმართულებით მუშაობს და მეორეში იღუპება, დაბრუნების გზაზე მიუთითებს და არა გვირაბზე, და სწორედ ეს ერთი განსხვავება წყვეტს, ზემოთ რომელი შეკეთება გჭირდებათ სინამდვილეში.