VPN ჰოსტზე გავუშვათ თუ VM-ის შიგნით? გადაწყვეტილების სახელმძღვანელო
გვირაბის მფლობელი წყვეტს, რა რას ფარავს. აირჩიეთ ჰოსტის ან სტუმრის განლაგება, შემდეგ დაადასტურეთ ის მარშრუტის, DNS-ისა და გასასვლელის შემოწმებებით სტუმრის შიგნით.
გვირაბის აგება სტუმრის შიგნით და მისი აგება ჰოსტზე ორივე ცვლის იმ მისამართს, რომელსაც ბრაუზერი აცხადებს, და სწორედ აქ მთავრდება მსგავსება. სტუმრის საკუთრებაში არსებული გვირაბი ინახავს თავის გასაღებებს, ნაგულისხმევ მარშრუტს და გამხსნელს სტუმრის ბირთვში, ხოლო ჰოსტი დაშიფრულ პაკეტებს ერთ შორეულ მისამართზე გადასცემს. ჰოსტის საკუთრებაში არსებული გვირაბი ამის სარკული გამოსახულებაა: ჰოსტის კლიენტი ინახავს სესიას და იყენებს მარშრუტებსა და პოლიტიკას, ხოლო სტუმარი სესხულობს იმას, რაც გარეთ გამოდის. აირჩიეთ არასწორი მფლობელი და ყოველი შემდგომი სიმპტომი არასწორ მანქანასთან მიგიყვანთ. ორი ბრძანება წყვეტს ამ კითხვას დაახლოებით ერთ წუთში, და ამ სახელმძღვანელოს დარჩენილი ნაწილი არის ის, თუ რა უნდა გააკეთოთ პასუხით.
გადაწყვიტეთ მფლობელი, სანამ კლიენტს შეეხებით
წესი ეხება იმას, თუ სად იქმნება დაშიფრული ტექსტი და არა იმას, თუ რომელი მანქანა აჩვენებს VPN-ის ხატულას. თუ მას სტუმარი ქმნის, სტუმარს სჭირდება მოქმედი მარშრუტი VPN სერვერამდე და მეტი არაფერი ჰოსტისგან. თუ მას ჰოსტი ქმნის, სტუმრის გზა ჰოსტის გავლით უნდა გადაურჩეს ყველა პოლიტიკას, რომელსაც ჰოსტის კლიენტი აკისრებს ადგილობრივ ტრაფიკს.
სამი კითხვა ჩვეულებრივ თავად ირჩევს განლაგებას. უნდა გადაურჩეს სტუმრის ტრაფიკი ჰოსტზე არსებულ კორპორატიულ კლიენტს? მაშინ გვირაბი სტუმრის შიგნითაა. სჭირდება რამდენიმე სტუმარს ერთი სერტიფიკატი და ერთი გასასვლელი მისამართი? მაშინ ის ჰოსტზეა, განზრახ გამართული გადამისამართებით. უნდა დარჩეს სტუმრის ტრაფიკი სრულიად ჰოსტის VPN-ის გარეთ? მაშინ სტუმრის გვირაბი ერთადერთი განლაგებაა, რომელიც ამას კონსტრუქციით გაძლევთ.
ჩაწერეთ პასუხი ერთ ხაზში VM-ის სახელის გვერდით: guest-owned ან host-owned. ექვსმანქანიან ლაბორატორიაში ეს ჩანაწერი უფრო მეტ დროს ზოგავს, ვიდრე ქვემოთ მოცემული ნებისმიერი ნაბიჯი, რადგან ის გიშლით ხელს იმ გვირაბის გამართვაში, რომელიც არასოდეს ყოფილა იმ მანქანაში, რომელშიც შეხვედით.
WSL1 და WSL2 საპირისპირო შემთხვევებია
WSL1 ვირტუალური მანქანა არ არის, ამიტომ განლაგების კითხვა ძირითადად ქრება. მისი Linux-ის ბინარული ფაილები მუშაობს Windows-ის ქსელური დასტის წინააღმდეგ თარგმანის ფენის მეშვეობით, და Linux VPN კლიენტს არ აქვს დამოუკიდებელი ინტერფეისები დასაყენებლად. მოქმედი განლაგებაა გვირაბი Windows-ის მხარეს, სადაც დისტრიბუცია იყენებს შედეგს არაფრის მფლობელობის გარეშე.
WSL2 პირიქითაა. ის ნამდვილ ბირთვს უშვებს მსუბუქ დამხმარე VM-ში Hyper-V-ის ვირტუალური კომუტატორის უკან, და მისი მისამართების სივრცე NAT-ით გარდაიქმნება ჰოსტის მხარის ადაპტერის მეშვეობით. ამიტომ დისტრიბუციის შიგნით Linux კლიენტი ისე იქცევა, როგორც ფიზიკურ Linux-ის კოლოფზე: ქმნის tun0-ს ან wg0-ს, აყენებს საკუთარ მარშრუტებს და მუშაობს. ხარვეზი ჰოსტის მხარეს ცხოვრობს. როცა Windows VPN კლიენტი უკავშირდება პოლიტიკით, რომელიც ბლოკავს ტრაფიკს ადგილობრივ ქსელებში, ის WSL2-ის ქვექსელს არასანდო ადგილობრივ ქსელად მიიჩნევს და წყვეტს NAT-ის გზას. შემდეგ დისტრიბუცია კარგავს DNS-ს და გარე წვდომას, მაშინ როცა მისი საკუთარი გვირაბი ჯერ კიდევ ჯანსაღია: wg show იუწყება ხელის ჩამორთმევას, ip route სწორად გამოიყურება, და curl იკიდება.
რომელი შესწორება შეგიძლიათ გამოიყენოთ, დამოკიდებულია Windows-ის ბილდზე. ძველია ჰოსტის კლიენტში WSL-ის ქვექსელის გამონაკლისი, რომელიც ემატება კლიენტის ადგილობრივი ქსელის ან გაყოფილი გვირაბის პარამეტრებში. ახალი, იმ Windows 11 ბილდებზე, რომლებიც მას მხარს უჭერენ, სარკული ქსელირებაა: ჩასვით networkingMode=mirrored %UserProfile%\.wslconfig-ის [wsl2] განყოფილებაში, გაუშვით wsl --shutdown, და დისტრიბუცია გაიზიარებს ჰოსტის ინტერფეისებს კერძო NAT ქვექსელის ნაცვლად. სარკული რეჟიმი ასევე ცვლის localhost-ისა და შემავალი პორტების ქცევას, ამიტომ მოეპყარით მას როგორც მიგრაციას და არა გადამრთველს.
NAT, ხიდი და რისი დანახვა შეუძლია ჰოსტს
NAT-ის ქვეშ სტუმრის გვირაბის პაკეტები მიმართულია VPN სერვერის საჯარო მისამართზე და გადის ჰოსტის ადაპტერიდან დაშიფრული UDP ან TCP-ის სახით. ჰოსტი ხედავს ერთ ნაკადს და მის ბაიტების რაოდენობას, არაფერს შიგნით არსებული დანიშნულებების შესახებ. ხიდიანი ადაპტერის ქვეშ სტუმარს აქვს საკუთარი მე-2 დონის იდენტობა ფიზიკურ LAN-ში, იღებს საკუთარ DHCP იჯარას და MAC-ზე დაფუძნებული ნებისმიერი პოლიტიკისთვის მეორე მოწყობილობად გამოიყურება. არც ერთი რეჟიმი არ აძლევს ჰოსტს გვირაბის დატვირთვის წაკითხვის საშუალებას; ხიდიანი სტუმარი უბრალოდ გაცილებით უფრო თვალსაჩინოა მის გარშემო არსებული ქსელისთვის.
იზოლაციასაც აქვს ქვედა ზღვარი. სტუმარი ვერ დაიმალება იმ მანქანისგან, რომელსაც ეკუთვნის მისი მეხსიერება, და ვინც ჰოსტს აკონტროლებს, შეუძლია გასაღებები წაიკითხოს სტუმრის RAM-იდან. სტუმრის გვირაბი გაძლევთ მარშრუტიზაციის საზღვარს და მავნე პროგრამების საზღვარს, და არა დაცვას ლეპტოპის მფლობელი ადამიანისგან. ღირს დოკუმენტირებული ადაპტერის რეჟიმების ღიად ქონა არჩევისას, რადგან რეჟიმი ცვლის როგორც იმას, რასაც ჰოსტი ხედავს, ისე იმას, რასაც LAN ხედავს.
სახელმძღვანელო: განალაგეთ, დააკონფიგურეთ, დაამტკიცეთ
გაუშვით ეს ოთხი შემოწმება თანმიმდევრობით ახალ სტუმრის გარსში და შეჩერდით პირველზე, რომელიც არ ეთანხმება თქვენ მიერ ჩაწერილ მფლობელს.
ip route get 1.1.1.1, რომელიც აბრუნებსtun0-ს ანwg0-ს, ნიშნავს სტუმრის საკუთრებას, ხოლოeth0კერძო შემდეგი ნახტომით ნიშნავს ჰოსტის საკუთრებას.resolvectl query example.com, ან წაიკითხეთ/etc/resolv.confიქ, სადაც სტუმარი გამხსნელ სერვისს არ უშვებს. გვირაბი, რომელიც ტრაფიკს ატარებს, მაგრამ DNS-ს არა, ყველაზე გავრცელებული ნახევრად გამართული მდგომარეობაა.- შეადარეთ გასასვლელები:
curl -4 -s https://ifconfig.meსტუმარში დაcurl.exe -4 -s https://ifconfig.meჰოსტზე. განსხვავებული მისამართები ნიშნავს, რომ გვირაბი სტუმარს ეკუთვნის, ხოლო VPN-ზე მყოფი ჰოსტი სახლის ISP-ის გამომჟღავნებელ სტუმართან ერთად არის ის შემთხვევა, როცა არაფერი მემკვიდრეობით არ მიუღიათ. - გაიმეორეთ ორივე
-6-ით. მხოლოდ v4 გვირაბი აჟონავებს v6-ს, თუ კლიენტი არ დაბლოკავს ან არ გადაამისამართებს მას, და ბევრი კლიენტი ნაგულისხმევად ტოვებს v6-ს ფიზიკურ ინტერფეისზე.
ჰოსტ-კარიბჭის დიზაინში, სადაც რამდენიმე სტუმარი ერთ გვირაბს იზიარებს, ჰოსტმა უნდა გადასცეს და გადათარგმნოს. Linux-ის ჰოსტზე ეს სამი ნაწილია, და სტუმარი ჩუმად უბრუნდება თავის ჩვეულებრივ მარშრუტს, როცა რომელიმე მათგანი აკლია:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPTWireGuard-ის მხარეს ჰოსტის პარტნიორის AllowedIPs უნდა მოიცავდეს სტუმრების ქვექსელს, მაგალითად 192.168.122.0/24, თორემ დაბრუნების პაკეტები ვერასოდეს მოვა და კონფიგურაცია ცეცხლის კედლის პრობლემას ჰგავს. Windows-ის ჰოსტი იმავე შედეგს აღწევს ინტერნეტ კავშირის გაზიარებით ან NAT წესით Hyper-V კომუტატორზე, და მას სჭირდება დაბრუნების გზის იგივე შემოწმება.
როცა განლაგება ჯერ ღიაა, ეს ცხრილი ფარავს ყველაზე ხშირ ვარიანტებს:
| Situation | Owner | Check first |
|---|---|---|
| One VM, host also on a corporate VPN | Guest | Does the host client block local networks? |
| Six lab VMs, one exit address | Host plus forwarding | ip_forward, NAT rule, server AllowedIPs |
| Malware or research VM | Guest, NAT | Snapshot age and resolver state |
| Bridged VM on an office LAN | Guest | DHCP lease and port security |
ორი გვირაბი, ორი სტუმარი და მათ შორის კონფლიქტები
როცა ერთდროულად ორი გასასვლელი გჭირდებათ, გამძლე ნიმუშია ერთი გვირაბი თითო სტუმარზე. ყოველი VM ინახავს საკუთარ ნაგულისხმევ მარშრუტსა და გამხსნელს, ჰოსტი რჩება ჩვეულებრივ ქსელში, და ორი გვირაბი არასოდეს კამათობს ერთსა და იმავე მარშრუტიზაციის ცხრილზე. ორი სტუმრის ხიდით შეერთება არც მათ მარშრუტებს აერთიანებს: ვირტუალური ქსელი გზას აძლევს, და ყოველ კლიენტს მაინც უნდა ეთქვას, რომ ამ ადგილობრივ ტრაფიკს გვირაბის გვერდის ავლა შეუძლია.
ჰოსტის გვირაბისა და სტუმრის გვირაბის ერთად გაშვება ლეგიტიმურია, და განზრახ ჩადგმა ზოგჯერ ზუსტად ის არის, რაც გინდათ, როცა სტუმარი გამოდის თავისი გვირაბიდან და ის გვირაბი გამოდის ჰოსტის გვირაბიდან. შეწყვეტად იქცევა ის, რომ არავის ჩაუწერია, რომელი ბოლო წერტილი რომელი ფენით უნდა მიღწეულ იქნას. შეინახეთ ორ სვეტიანი სია დანიშნულებისა და მფლობელის შესახებ, და მარშრუტის კონფლიქტი აღმოჩენის მთელი შუადღის ნაცვლად ძიებად იქცევა.
გადაამოწმეთ, შემდეგ აღდგენა მფლობელს დაუტოვეთ
სცადეთ სტუმრის შიგნიდან ახალი აპლიკაციის პროცესით: ტრაფიკი, სახელების გარჩევა, მისამართების ორივე ოჯახი და რა ხდება, როცა გვირაბი ვარდება. ჰოსტის VPN ხატულა არაფერს ამბობს სტუმრის დაფარვაზე, და ეს არის ყველაზე გავრცელებული ცრუ დადასტურება მთელ ამ სფეროში.
აღდგენაც მფლობელს ეკუთვნის. სტუმრის საკუთრებაში არსებული გვირაბი აღდგება სტუმრის საკუთარი კლიენტით და მის მიერ დაწერილი მარშრუტებით. ჰოსტის საკუთრებაში არსებული დიზაინი აღდგება ჰოსტის ჩატვირთვის მიმდევრობით, და გადამისამართების წესები არ გადაურჩება გადატვირთვას, თუ ერთეული ან გაშვების ამოცანა მათ ხელახლა არ გამოიყენებს. აღდგენილი სნეპშოტი განლაგებაა და არა გაუქმება, რადგან ის დისკთან ერთად ძველ სერტიფიკატებსა და ძველ მარშრუტებს აბრუნებს. სანამ სამუშაოს დასრულებულად გამოაცხადებთ, დაადასტურეთ, რომ მფლობელი კვლავ ემთხვევა თქვენს ჩაწერილ ხაზს, რომ DNS და მისამართების ორივე ოჯახი იხსნება სტუმრის შიგნით, რომ მკვდარი გვირაბი ტოვებს გამოსადეგ ქსელს და არა შავ ხვრელს, და რომ გადატვირთვა ან სნეპშოტის აღდგენა იმავე მდგომარეობას ახდენს.