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 एक दिशामा चल्छ र अर्कोमा मर्छ त्यसले टनेल होइन फर्कने बाटो देखाउँछ, र यही एउटा भिन्नताले माथिका कुन मर्मत तपाईंलाई साँच्चै चाहिन्छ निर्धारण गर्छ।