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 एका दिशेने चालतो आणि दुसऱ्या दिशेने मरतो तो टनेलकडे नाही, परतीच्या रस्त्याकडे निर्देश करतो, आणि हाच एक फरक वरच्या कोणत्या दुरुस्तीची तुम्हाला खरोखर गरज आहे हे ठरवतो.