तुमच्या LAN मधील प्रत्येक डिव्हाइससोबत एक VPN कनेक्शन शेअर करा

एक लॅपटॉप टनेल धरून ठेवतो, घराच्या उर्वरित भागाला तोच प्रवेश हवा असतो, आणि पहिला प्रयत्न सर्व काही जोडलेल्या मशीनकडे वळवणे हा असतो। हे VPN शी काहीही संबंध नसलेल्या कारणांमुळे अयशस्वी होते: प्राप्त करणाऱ्या होस्टने पॅकेट पुढे पाठवावे, त्याचा स्रोत पुन्हा लिहावा आणि उत्तरांना परतीचा मार्ग सापडेल याची खात्री करावी। तीनपैकी एकही चुकल्यास जोडलेला लॅपटॉप काम करत राहतो, तर इतर प्रत्येक डिव्हाइसला उत्तर मिळत नाही। उपाय म्हणजे राउटिंगची रचना, क्लायंटची सेटिंग नाही।

डिव्हाइस होस्टकडे वळवणे का अयशस्वी होते

दूरच्या नेटवर्कसाठी पत्ता दिलेले पॅकेट मिळणारा होस्ट त्या क्षणी राउटर बनतो, कोणी त्याला तसे कॉन्फिगर केले असेल किंवा नसेल याची पर्वा न करता। फॉर्वर्डिंग लिनक्स आणि विंडोजवर डीफॉल्टनुसार बंद असते, जोपर्यंत एखादे वैशिष्ट्य ते सुरू करत नाही। पत्ता भाषांतर महत्त्वाचे आहे कारण दूरच्या बाजूला उत्तरे कुठे पाठवायची हे माहीत असणे आवश्यक आहे, आणि खाजगी LAN पत्ता त्याला काहीही अर्थ देत नाही। परतीचा मार्ग हा तिसरा भाग आहे, आणि पहिला पिंग यशस्वी वाटल्यावर लोक विसरतात तोच।

सेटिंग्ज अव्यवस्थितपणे सुरू आणि बंद करण्याऐवजी त्याच क्रमाने निदान करा। प्रत्येक गहाळ भाग थोडासा वेगळा लक्षण निर्माण करतो।

होस्टवर फॉर्वर्डिंग आणि पत्ता भाषांतर सुरू करा

जोडलेल्या होस्टवरील दोन बदल पहिले दोन भाग व्यापतात: IPv4 फॉर्वर्डिंग सुरू करा आणि LAN रहदारी टनेल इंटरफेसवर भाषांतरित करा।

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

sysctl मूल्य /etc/sysctl.d खालील फाइलमध्ये टिकवून ठेवा, आणि रीबूटनंतर masquerade नियम पुन्हा तपासा, कारण फायरवॉलचे पुढील भाग सानुकूल साखळ्या रिकाम्या करू शकतात। विंडोजवर शेअरिंग वैशिष्ट्य दोन्ही पायऱ्या करते, पण ते LAN अ‍ॅडॉप्टरला स्थिर सबनेटवर पुन्हा पत्ता देते आणि त्याचा गेटवे पुसते, ज्यामुळे स्थिर पत्ता आणि पोर्ट फॉर्वर्डिंग तुटते। शेअरिंग अयशस्वी झाली असा निष्कर्ष काढण्यापूर्वी राउटरचा होस्टकडे जाणारा मार्ग त्याच्या नवीन पत्त्यावर पुनर्संचयित करा। नंतर दुसरे डिव्हाइस रहदारी पाठवत असताना नियमाचे काउंटर वाढताना पहा।

LAN ला रीबूटनंतर टिकणारा मार्ग द्या

इतर डिव्हाइसना दूरच्या प्रिफिक्सकडे मार्ग आवश्यक आहे, आणि तो देण्याच्या दोन पद्धती प्रभावाच्या व्याप्तीत भिन्न आहेत।

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

क्लायंटचा डीफॉल्ट गेटवे होस्टकडे वळवल्यास त्याची सर्व रहदारी होस्टमधून जाते, स्थानिक छपाई आणि फाइल शेअरिंगसह, त्यामुळे होस्ट झोपल्यावर असंबंधित गोष्टी थांबतात। राउटरवर दूरच्या प्रिफिक्ससाठी विशिष्ट मार्ग जोडणे अधिक अरुंद आहे: टनेलच्या मागील गंतव्येच जोडलेल्या मशीनकडे जातात, आणि उर्वरित LAN काम करत राहते। वरील सबनेट फक्त उदाहरणे आहेत, म्हणून ते तुमच्या स्वतःच्या LAN आणि टनेल श्रेणींनी बदला। कोणत्याही परिस्थितीत, दुसऱ्या डिव्हाइसवरून टनेल सुरू आणि नंतर बंद स्थितीत चाचणी करा।

टनेलला दोष देण्यापूर्वी MTU कडे लक्ष द्या

टनेल उपयुक्त पॅकेट आकार कमी करतात, आणि दुसऱ्या डिव्हाइसला त्याबद्दल काहीही माहीत नसते। मोठे हस्तांतरण आणि TLS हस्तांदोलने अडकतात, तर लहान विनंत्या यशस्वी होतात।

ping -M do -s 1400 10.8.0.5

उत्तर हे सिद्ध करते की तो आकार मार्गात न तुकडे होता ओलांडतो; वेळ संपणे म्हणजे एन्कॅप्स्युलेशनचा भार पॅकेटला टनेलच्या MTU च्या पलीकडे ढकलला। शेअरिंग इंटरफेसवर MTU कमी करा किंवा पुढे पाठवणाऱ्या डिव्हाइसवर कमाल सेगमेंट आकार मर्यादित करा, नंतर तीच चाचणी पुन्हा करा। प्रथम तोच आकार LAN बाजूला तपासा, कारण स्थानिक अयशस्वीता टनेलकडे नव्हे तर LAN कडे निर्देश करते। कार्यरत आकार नोंदवा, कारण नंतरचा पुरवठादार किंवा टनेल बदल तो हलवू शकतो।

एका अतिरिक्त डिव्हाइससाठी होस्टपासून शेअरिंग पुरेसे आहे। घरासाठी मार्ग राउटरवर ठेवा। लॅपटॉप तुमच्यासोबत गेल्यावरही प्रवेश टिकून राहिला पाहिजे असेल, तर टनेल स्वतः समर्पित गेटवेवर असावा।