VPN होस्टवर चालवायचा की VM च्या आत? निर्णय मार्गदर्शक
टनेलचा मालिक ठरवतो की काय काय झाकते। होस्ट किंवा अतिथीवर जागा निवडा, नंतर अतिथीच्या आत मार्ग, DNS आणि बाहेर पडण्याच्या तपासण्यांनी त्याची पुष्टी करा।
अतिथीच्या आत टनेल बांधणे आणि तो होस्टवर बांधणे—दोन्ही ब्राउझर जो पत्ता कळवतो तो बदलतात, आणि साम्य तिथेच संपते। अतिथीच्या मालकीचा टनेल त्याच्या किल्ल्या, त्याचा डीफॉल्ट मार्ग आणि त्याचा सोडवणारा अतिथीच्या कर्नलमध्ये ठेवतो, तर होस्ट एन्क्रिप्ट केलेले पॅकेट एका दूरच्या पत्त्यावर पाठवतो। होस्टच्या मालकीचा टनेल त्याचे उलटे चित्र आहे: होस्ट क्लायंट सत्र धरतो आणि मार्ग व धोरण लागू करतो, आणि अतिथी बाहेर येते ते उसने घेतो। चुकीचा मालिक निवडला तर पुढील प्रत्येक लक्षण तुम्हाला चुकीच्या मशीनकडे पाठवेल। दोन आदेश हा प्रश्न सुमारे एका मिनिटात निकाली काढतात, आणि या मार्गदर्शकाचा उर्वरित भाग म्हणजे उत्तराचे काय करायचे हे।
क्लायंटला हात लावण्यापूर्वी मालिक ठरवा
नियम सायफरटेक्स्ट कुठे तयार होतो याबद्दल आहे, कोणते मशीन VPN चिन्ह दाखवते याबद्दल नाही। अतिथी तो तयार करत असेल, तर अतिथीला VPN सर्व्हरपर्यंत कार्यरत मार्ग हवा आणि होस्टकडून दुसरे काही नको। होस्ट तो तयार करत असेल, तर होस्ट क्लायंट स्थानिक रहदारीवर जे धोरण लादतो त्याचा विचार न करता अतिथीचा होस्टमार्ग टिकला पाहिजे।
साधारणपणे तीन प्रश्न तुमच्यासाठी जागा निवडतात। अतिथीच्या रहदारीला होस्टवरील कॉर्पोरेट क्लायंट ओलांडावा लागतो का? तर टनेल अतिथीच्या आत आहे। अनेक अतिथींना एकच क्रेडेन्शियल आणि एकच बाहेर पडण्याचा पत्ता हवा आहे का? तर तो होस्टवर आहे, फोर्वर्डिंग जाणीवपूर्वक बसवलेले। अतिथीची रहदारी होस्टच्या VPN बाहेरच राहायला हवी का? तर अतिथीतील टनेल हीच एकमेव रचना जी ते बांधणीनेच देते।
उत्तर VM च्या नावाशेजारी एका ओळीत लिहा: guest-owned किंवा host-owned। सहा मशीनच्या प्रयोगशाळेत ती नोंद खालील कोणत्याही पायरीपेक्षा जास्त वेळ वाचवते, कारण तुम्ही ज्या मशीनमध्ये लॉगिन केले त्या मशीनमध्ये कधीच नसलेल्या टनेलची चौकशी करण्यापासून ती तुम्हाला थांबवते।
WSL1 आणि WSL2 विरुद्ध प्रकरणे आहेत
WSL1 व्हर्च्युअल मशीन नाही, म्हणून जागेचा प्रश्न बहुतांशी पुसट होतो। त्याच्या Linux बायनरीज भाषांतर स्तरातून Windows च्या नेटवर्क स्टॅकविरुद्ध चालतात, आणि Linux VPN क्लायंटकडे संरचना करण्यासाठी स्वतंत्र इंटरफेस नाहीत। जे काम करते ते Windows बाजूचे टनेल आहे, आणि वितरण काहीही मालकी न घेता निकाल वापरते।
WSL2 उलट आहे। तो Hyper-V व्हर्च्युअल स्विचच्या मागे हलक्या युटिलिटी VM मध्ये खरे कर्नल चालवतो, आणि त्याची पत्ता-जागा होस्ट बाजूच्या अडॅप्टरमार्फत NAT होते। म्हणून वितरणातील Linux क्लायंट भौतिक Linux बॉक्सवर जसा वागेल तसा वागतो: तो tun0 किंवा wg0 तयार करतो, स्वतःचे मार्ग बसवतो आणि चालतो। अपयश होस्टच्या बाजूला राहते। जेव्हा Windows VPN क्लायंट स्थानिक नेटवर्कवरील रहदारी अडवणाऱ्या धोरणाने जोडतो, तेव्हा तो WSL2 उपजाळाला अविश्वासार्ह स्थानिक नेटवर्क मानून NAT मार्ग कापतो। मग वितरण DNS आणि बाहेरचा प्रवेश गमावते, तर त्याचे स्वतःचे टनेल अजूनही निरोगी असते: wg show हँडशेक कळवते, ip route बरोबर दिसते, आणि curl लटकते।
कोणता उपाय वापरू शकता हे Windows बिल्डवर अवलंबून आहे। जुना म्हणजे WSL उपजाळासाठी होस्ट क्लायंटमधील अपवाद, जो क्लायंटच्या स्थानिक-नेटवर्क किंवा विभाजित-टनेल सेटिंग्जखाली जोडला जातो। नवीन, जे Windows 11 बिल्ड ज्यांना ते समर्थन देतात त्यांमध्ये, म्हणजे मिरर नेटवर्किंग: %UserProfile%\.wslconfig च्या [wsl2] विभागात networkingMode=mirrored ठेवा, wsl --shutdown चालवा, आणि वितरण खाजगी NAT उपजाळाऐवजी होस्टचे इंटरफेस सामायिक करेल। मिरर मोड localhost आणि येणाऱ्या पोर्टचे वर्तनही बदलतो, म्हणून त्याला टॉगल नव्हे तर स्थलांतर माना।
NAT, ब्रिज आणि होस्ट काय पाहू शकतो
NAT अंतर्गत अतिथीचे टनेल पॅकेट VPN सर्व्हरच्या सार्वजनिक पत्त्यावर पाठवले जातात आणि एन्क्रिप्ट केलेल्या UDP किंवा TCP स्वरूपात होस्ट अडॅप्टरमधून बाहेर पडतात। होस्ट एक प्रवाह आणि त्याची बाइट-संख्या पाहतो, आतल्या गंतव्यांबद्दल काहीही नाही। ब्रिज अडॅप्टरखाली अतिथीची भौतिक LAN वर स्वतःची 2-स्तरीय ओळख असते, स्वतःचे 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 होस्ट Internet Connection Sharing किंवा Hyper-V स्विचवरील NAT नियमाने तोच निकाल मिळवतो, आणि त्यालाही तीच परत-मार्ग तपासणी लागते।
रचना अजून खुली असताना, हा तक्ता सर्वात सामान्य व्यवस्था झाकतो:
| 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 चिन्ह अतिथीच्या व्याप्तीबद्दल काहीही सांगत नाही, आणि या संपूर्ण क्षेत्रात तीच सर्वात सामान्य खोटी पुष्टी आहे।
पुनर्प्राप्तीही मालिकाचीच। अतिथी-मालकीचा टनेल अतिथीच्या स्वतःच्या क्लायंटने आणि त्याने लिहिलेल्या मार्गांनी पुनर्संचयित होतो। होस्ट-मालकीची रचना होस्टच्या बूट-क्रमाने पुनर्संचयित होते, आणि फोर्वर्डिंग नियम रीबूटमध्ये टिकत नाहीत जोपर्यंत unit किंवा स्टार्टअप कार्य त्यांना पुन्हा लागू करत नाही। पुनर्संचयित स्नॅपशॉट म्हणजे तैनाती, रद्द नव्हे, कारण तो डिस्कसोबत जुने क्रेडेन्शियल आणि जुने मार्ग परत आणतो। काम पूर्ण झाले असे म्हणण्यापूर्वी पुष्टी करा की मालिक अजूनही तुम्ही लिहिलेल्या ओळीशी जुळतो, DNS आणि दोन्ही पत्ता-कुटुंबे अतिथीच्या आत सोडवली जातात, मृत टनेल काळ्या छिद्राऐवजी वापरण्यायोग्य नेटवर्क सोडतो, आणि रीबूट किंवा स्नॅपशॉट पुनर्संचयन तीच स्थिती पुन्हा निर्माण करते।