Pi वरील हॉटस्पॉट क्लायंट TUN VPN द्वारे घरच्या LAN पर्यंत पोहोचत नाहीत

पत्ता मिळतो पण घरचे शेअरिंग उघडता येत नाही अशा हॉटस्पॉट क्लायंटना पूल नाही, परतीचा मार्ग हवा आहे. TUN मार्ग, प्रीफिक्स मालक आणि NAT यांचा मागोवा घ्या.

स्थानिक Wi-Fi आणि Ethernet क्लायंट Pi च्या हॉटस्पॉटशी जोडतात, त्याच्या DHCP श्रेणीतून पत्ता घेतात आणि तक्रार न करता इंटरनेट पृष्ठे लोड करतात. नंतर तेच क्लायंट घरच्या LAN वर फाइल शेअरिंग किंवा वेब इंटरफेस उघडताना वेळ संपते, तर Pi स्वतः त्या LAN पर्यंत बोगद्यातून पोहोचतो. वायरलेस स्तरावर काहीही तुटलेले नाही. जे कमी आहे ते राउटेड करार आहे: हॉटस्पॉट प्रीफिक्स TUN इंटरफेसमध्ये न्यावा लागेल, आणि घरच्या बाजूला कशालातरी उत्तरे तिथे परत कशी पाठवायची हे माहीत असले पाहिजे. एकही पॅकेट प्रवास पूर्ण करण्यापूर्वी दोन्ही अर्धे असणे आवश्यक आहे.

तीन भिन्न कामांसह तीन जोडण्या

Linux Ethernet ब्रिज गंतव्य MAC पत्त्यानुसार फ्रेम पुढे पाठवतो. OpenVPN TUN मोडमध्ये IP पॅकेट वाहून नेतो आणि त्यात MAC स्तर अजिबात नाही, त्यामुळे स्थानिक ब्रिज जोडल्यास बोगदा कधीही पोर्ट म्हणून नोंदवला जात नाही. कर्नल TUN/TAP दस्तऐवज हे विभाजन स्पष्ट करतात: TAP उपकरण Ethernet इंटरफेससारखे दिसते, TUN उपकरण नाही. दोन स्थानिक पोर्ट ब्रिज करून नंतर राउटिंग करणारी रचना इंटरफेसची नावे काय सांगोत, राउटरच असते.

हा फरक मालकी ठरवतो. क्लायंटचे सबनेट, त्यांचे डीफॉल्ट गेटवे आणि त्या श्रेणीचे DHCP अधिकार Pi च्या स्थानिक योजनेचे आहेत. घरचे DHCP प्रसारण राउटेड बोगद्याला ओलांडत नाही, आणि कोणतेही ब्रिज सेटिंग ते बदलत नाही; क्लायंटना घरच्या DHCP सर्व्हरकडे वळवणे हे स्वतःच्या अयशस्वी पद्धती असलेले वेगळे, जाणीवपूर्वक रिले डिझाइन आहे.

मोडेमही क्लायंट ब्रिजबाहेर ठेवा. PPP जोडणी वेगळ्या लेबलाचे Ethernet उपकरण नाही, आणि pppd चे दस्तऐवजी डीफॉल्ट-राउट तर्क IPCP चर्चेनंतर चालते आणि ती लिंक पडल्यावर आपला मार्ग मागे घेते. DHCP टेम्पलेट कॉपी करून प्रत्येक usb0 चे ppp0 असे नामकरण करणे गेटवे, मेट्रिक किंवा जीवनचक्राबद्दल काहीही सिद्ध करत नाही.

कोणताही कॉन्फिग संपादित करण्यापूर्वी प्रीफिक्स निवडा

ओव्हरलॅपिंग प्रीफिक्स फायरवॉल नियमांपेक्षा जास्त संध्याकाळ वाया घालवतात, कारण बोगदा निरोगी असतानाही ओव्हरलॅप मार्ग शोध चुकीच्या इंटरफेसवर पाठवते. Pi वर आधीच काय आहे त्याची यादी करून सुरुवात करा, नंतर निकाल चार स्वतंत्र तलाव म्हणून वाचा.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

पहिला तलाव म्हणजे कॅरियरने मोडेमला दिलेला underlay पत्ता; तो क्लायंटकडे असलेल्या प्रत्येक योजनेबाहेर राहिला पाहिजे. दुसरा म्हणजे सर्व्हरने निवडलेले बोगदा सबनेट, अनेकदा त्याचे स्वतःचे खाजगी /24 नेटवर्क. तिसरा हॉटस्पॉट ब्रिज, आणि चौथा म्हणजे तुम्हाला पोहोचायचे घरचे प्रीफिक्स. या फेरीत हॉटस्पॉटला 172.28.90.0/24 मिळते, ब्रिज 172.28.90.1 वर आहे, आणि घरचे सेवा LAN 192.168.77.0/24 ठेवते, जे ग्राहक राउटरसोबत येणारे 192.168.1.0/24 आणि 10.0.0.0/24 डीफॉल्ट आणि 100.64.0.0/10 कॅरियर श्रेणी टाळते.

हॉटस्पॉटच्या DHCP श्रेणीत फक्त ब्रिजचा पत्ता गेटवे म्हणून जाहीर करा, दुसरे काही नाही. हॉटस्पॉट क्लायंटना कधीही गेटवे म्हणून घरचा पत्ता देऊ नका; त्या विभागापर्यंत त्यांचा लिंक-स्तरीय मार्ग नाही.

प्रत्येक दिशा तिच्या मालकीच्या बाजूला राउट करा

Pi ला बोगद्यातून घरच्या प्रीफिक्ससाठी मार्ग हवा. सर्व्हर मोडमधील सर्व्हर सहसा तो मार्ग ढकलतात, म्हणून आधी फॉरवर्डिंग सुरू आहे आणि कर्नल tun0 मधून घरचा पत्ता सोडवतो याची खात्री करा.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

ip route get अजूनही underlay इंटरफेस नोंदवत असेल, तर तिथेच थांबा; मार्गात पुढे काहीही चुकीची शोध दुरुस्त करू शकत नाही.

घरच्या उपकरणांना 172.28.90.0/24 पर्यंत मार्ग नाही, त्यामुळे त्यांची उत्तरे डीफॉल्ट गेटवेचे अनुसरण करतात आणि राउटरवर मरतात. दोन समर्थित दुरुस्त्या आहेत. एकतर घरच्या राउटरवर स्थिर मार्ग जोडा जो हॉटस्पॉट प्रीफिक्स VPN सर्व्हरच्या LAN पत्त्याकडे निर्देश करतो, किंवा सर्व्हर स्वतः गेटवे असल्यास क्लायंट प्रीफिक्स सर्व्हरच्या स्वतःच्या राउटिंग तक्त्यात नोंदवा. OpenVPN च्या मल्टी-क्लायंट मोडमध्ये क्लायंट-विशिष्ट डिरेक्टरी ते संबंध वाहते: क्लायंट प्रमाणपत्राच्या सामान्य नावावर नाव दिलेली फाइल, ज्यात iroute 172.28.90.0 255.255.255.0 आणि ती सर्व्हर कर्नलमध्ये स्थापित करणारी जुळणारी route ओळ असते. सर्व्हरवर अंदाज केलेला कर्नल मार्ग कोणता क्लायंट प्रीफिक्सचा मालक आहे हे सर्व्हरला सांगण्याइतकेच विधान नाही.

हे काम करण्यासाठी घरच्या नेटवर्कची DHCP सेवा VPN सर्व्हरवर हलवू नका. संपूर्ण घरासाठी डीफॉल्ट गेटवे बदलणे एक खाजगी परतीचा मार्ग जोडण्यापेक्षा खूप मोठा बदल आहे, आणि ते DNS, पत्ता आरक्षणे आणि नवीन भाडेपट्टा दुर्लक्ष करणारे प्रत्येक उपकरण अयशस्वीतेत ओढते.

फायरवॉलचा अंदाज न घेता फॉरवर्डिंग उघडा

फॉरवर्डिंग सुरू असणे म्हणजे पॅकेटला जाण्याची परवानगी आहे असे नाही. ब्रिजकडून बोगद्याकडे जाणारा रहदारी अजूनही फिल्टर नियमांना धडकतो, आणि डीफॉल्ट-ड्रॉप फॉरवर्ड धोरण हॉटस्पॉट रहदारी टाकून देते तर Pi चा स्वतःचा रहदारी चालू राहतो, जे वरचे विभाजित लक्षण तंतोतंत निर्माण करते.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 ते tun0 पर्यंत स्वीकार नियम आणि जुळणारी उत्तर दिशा, तसेच स्रोत पुन्हा लिहू शकणारा postrouting नियम शोधा. साखळी धोरण drop असेल आणि कोणताही नियम जुळत नसेल, तर धोरण accept मध्ये उलटण्याऐवजी अरुंद स्वीकार जोडा आणि पुन्हा चाचणी करा.

भाषांतर ही आवश्यकता नाही, धोरणाची निवड आहे. घरच्या LAN कडे जाणारे स्रोत NAT प्रत्येक हॉटस्पॉट क्लायंटला Pi च्या बोगदा पत्त्यासारखे दाखवते, जे घरच्या लॉगमध्ये प्रति-क्लायंट श्रेय गमावते आणि मूळ स्रोत अपेक्षणाऱ्या सेवा तोडते. NAT शिवाय राउटिंग क्लायंट पत्ते दृश्यमान ठेवते पण वरच्या परतीच्या मार्गावर अवलंबून असते. एक निवडा आणि DNS व IPv6 ला त्याच पद्धतीने हाताळा, कारण तुटलेल्या IPv6 मार्गाशेजारी चालणारा IPv4 मार्ग ब्राउझरमध्ये अजूनही अर्धा तुटलेला वाचला जातो.

येण्या-जाण्याचा प्रवास तपासा, नंतर तो जाणीवपूर्वक तोडा

हॉटस्पॉट क्लायंटवरून चाचणी करा, Pi वरून कधीही नाही, कारण Pi चा स्वतःचा रहदारी पुढचा आणि परतीचा दोन्ही मार्ग टाळतो. एक क्लायंट घरच्या सेवेपर्यंत पोहोचण्याचा प्रयत्न करत असताना दोन्ही इंटरफेस पहा.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

दोन्ही कॅप्चर एकत्र वाचा. br0 वर दिसून tun0 वर कधीही न दिसणाऱ्या विनंत्या म्हणजे Pi फॉरवर्ड करत नाही किंवा मार्ग दुसरीकडे निर्देश करतो. tun0 वर उत्तरांशिवाय विनंत्या म्हणजे घरच्या बाजूला परतीचा मार्ग नाही किंवा सर्व्हरने पॅकेट फिल्टर केले. tun0 वर दिसून br0 वर पुन्हा न दिसणारी उत्तरे म्हणजे उलटा फिल्टर नियम गहाळ आहे, जिथे बोगदा परिपूर्ण दिसतो आणि क्लायंट अजूनही काहीच पाहत नाही.

मग मार्ग जाणीवपूर्वक तोडा. मोडेम कनेक्शन खाली आणि पुन्हा वर करा आणि मार्ग व कॅप्चर तपासण्या पुन्हा चालवा; बोगद्यातून टिकणारा पण पुन्हा जोडल्यावर नाहीसा होणारा मार्ग एक-वेळच्या आदेशात नाही, कनेक्शन प्रोफाइलमध्ये हवा. बोगद्याचे वाहतूक अजूनही underlay मधून बाहेर पडते आणि स्वतःतून नाही याची खात्री करा, हे पीअरपर्यंत होस्ट मार्गाशिवाय ढकललेला डीफॉल्ट मार्ग स्वीकारल्यावरचे क्लासिक लूप आहे.

हॉटस्पॉट क्लायंट घरचे नाव सोडवू शकतो, TCP सेवा उघडू शकतो आणि एका मोडेम पुनर्जोडणीत सत्र जिवंत ठेवू शकतो तेव्हाच रचना स्वीकारा. जर अनुप्रयोगाला घरच्या विभागात खरोखर Ethernet-स्तरीय शोध हवा असेल, तर स्थानिक ब्रिजला ब्रिज केलेले म्हणून वर्णन करून प्रसारण येण्याची वाट पाहण्याऐवजी समर्थित Layer 2 रचना निवडा.

संबंधित लेख