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” ताकि क्लाइंट वापसी का रास्ता जानें।
पहली एंट्री के बिना जवाब लक्ष्य को उसके डिफ़ॉल्ट गेटवे की ओर छोड़ता है, जो एक निजी पता ISP तक भेजकर गिरा देता है। लक्षण एकतरफ़ा है और ग़लत पढ़ा जाना आसान: अनुरोध 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 |
मीट्रिक सबसे सस्ता विकल्प है और वही जिस पर लोग पहले हाथ डालते हैं। बदलाव इंटरफ़ेस पर लागू होता है, इसलिए टनल चालू रहने तक काम करता है, और इसकी जगह क्लाइंट के पास की स्क्रिप्ट में है, उस शेल में नहीं जिसे आप भूल जाएँगे। यह दो नेटवर्क पर एक ही पते तक एक साथ पहुँच नहीं दे सकता, और यही सीमा बाक़ी सबको तालिका में नीचे भेजती है।
घर के 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 और हर दूसरा खोज पैकेट; दूर के राउटर के LAN पक्ष के पते के लिए route 192.168.2.1 255.255.255.255 जैसा यूनिकास्ट होस्ट रूट चुनें।
एक ही रास्ते पर दोनों 192.168.1.1 इस्तेमाल करने वाले दो राउटर एक ही तरह की समस्या हैं: स्थानीय पता हमेशा जीतता है, इसलिए दूर के राउटर का पेज तब तक पहुँच से बाहर रहता है जब तक एक LAN न हटे। दूसरा अडैप्टर जोड़ने से दोनों में से किसी भी स्थिति में कुछ नहीं बदलता।
कुछ भी संपादित करने से पहले सबूत लिख लें: ip route get या Find-NetRoute, संबंधित पते पर ping -c 3, एक traceroute, और क्लाइंट पर tcpdump -ni tun0 icmp, फिर सर्वर पर रूटिंग तालिका और NAT काउंटर। जो ping एक दिशा में चलता है और दूसरी में मर जाता है वह वापसी के रास्ते की ओर इशारा करता है, टनल की ओर नहीं, और यही एक फ़र्क़ तय करता है कि ऊपर की कौन-सी मरम्मत आपको सचमुच चाहिए।