WireGuard पूर्ण टनल: AllowedIPs 0.0.0.0/0 पुरेसे नाही

पीअरच्या AllowedIPs मध्ये 0.0.0.0/0, ::/0 टाकणे हे सर्वांना आठवणारे पाऊल आहे, आणि ते फक्त पीअरला कोणती रहदारी वाहून नेण्याची परवानगी आहे हे ठरवते। हे प्रीफिक्स कोणतेही मार्ग तयार करत नाहीत, दुसऱ्या बाजूला काहीही फॉरवर्ड करत नाहीत, आणि प्रत्येक अनुप्रयोगाचा रिझॉल्व्हर जिथे होता तिथेच ठेवतात। संपूर्ण टनल खरोखर संपूर्ण होण्यासाठी चार वेगवेगळ्या गोष्टी एकाच वेळी खऱ्या असल्या पाहिजेत, आणि त्या खालील क्रमाने तपासणे उत्तम, कारण नंतरची तपासणी आधीची तपासणी वाचवू शकत नाही। खालील प्रत्येक तपासणी ही यंत्रावरून वाचता येणारी वस्तुस्थिती आहे, लागू झाली असेल अशी आशा करणारी सेटिंग नाही।

पीअर प्रीफिक्स काय निवडते, आणि काय नाही

AllowedIPs एकाच वेळी निवडक आणि अधिकृत करणारा आहे। तो स्थानिक बाजूला कोणत्या गंतव्यस्थानांना या पीअरकडे पाठवता येते हे सांगतो, आणि प्राप्त करणाऱ्या बाजूला हा पीअर कोणते स्रोत पत्ते सादर करू शकतो हे सांगतो। हेच संपूर्ण काम। त्या वर्णनात काहीही होस्टवर मार्ग तयार करत नाही, दूरच्या बाजूला फॉरवर्डिंग सुरू करत नाही, किंवा नाव निराकरणाला हात लावत नाही।

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

क्लायंटला मार्गस्थ करणे, फक्त पीअर यादी नाही

उदाहरणार्थ wg-quick सारखे मॅनेजर होस्टची मार्ग सारणी तुमच्या वतीने प्रोग्राम करतात, म्हणूनच दोन समान कॉन्फिगरेशन फाइल्स इंटरफेस कसा वर आला यावर अवलंबून वेगळ्या पद्धतीने वागतात। किमान प्रोफाइल एका दमात वाचण्याइतकी लहान आहे:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

काम दोन तपशील उचलतात। Address फील्ड क्लायंट स्वतःचे मानतो असे सबनेट नाही, तर एकच होस्ट प्रीफिक्स आहे, आणि डीफॉल्ट AllowedIPs ला खऱ्या डीफॉल्ट मार्गात बदलणारा मॅनेजरच आहे। तीच फाइल ip link आणि wg setconf ने वर आणा आणि कोणताही मार्ग दिसणार नाही, जे तुटलेल्या टनलसारखे दिसते आणि प्रत्यक्षात मार्गस्थता पाऊल वगळलेली निरोगी टनल आहे। wg-quick पुस्तिका मार्गस्थता आणि Table वर्तनाचे दस्तऐवजीकरण करते, जे ते मॅनेजर जोडतात।

फाइल नाही, निकाल वाचा: ip route get 1.1.1.1 टनल इंटरफेसचे नाव दिले पाहिजे, आणि wg show हलणाऱ्या हस्तांतरण काउंटरसह अलीकडील हँडशेक नोंदवले पाहिजे। मार्गाशिवाय हँडशेक म्हणजे मॅनेजर कधीच चालला नाही, आणि प्रोफाइल पुन्हा संपादित केल्याने ते सुधारणार नाही। वापरकर्ता जसा सुरू करेल तसाच इंटरफेस सुरू करा, नाहीतर चाचणी तैनातीऐवजी तुमचे शेल मोजते।

एंडपॉइंट टनलबाहेर ठेवणे

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

एंडपॉइंट अनेक पत्त्यांवर किंवा तुम्ही वाहत नसलेल्या कुटुंबावर निराकरण होणारे होस्टनेम असेल, तर अपवाद वाईटपणे जुना होतो आणि नियमित वाटलेल्या पुनर्जोडणीनंतर टनल अयशस्वी होऊ शकते। एंडपॉइंट तुम्ही नियंत्रित करता त्या पत्त्यावर पिन करा, किंवा मॅनेजर त्याचे पुनर्मूल्यांकन करतो याची खात्री करा, आणि प्रत्येक नेटवर्क बदलानंतर होस्ट मार्ग पुन्हा वाचा।

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

गेटवेवर फॉरवर्डिंग आणि परतीचा मार्ग

गेटवेवर, तुम्ही वाहत असलेल्या कुटुंबासाठी फॉरवर्डिंग सुरू करा, भाषांतर करताना forward साखळीला दोन्ही दिशांना परवानगी द्या, आणि स्रोत-विशिष्ट शोधाने परतीचा मार्ग निश्चित करा। यातील काहीही यशस्वी हँडशेकमधून येत नाही, कारण हँडशेक फक्त दोन पीअर UDP ची देवघेव करू शकतात हे सिद्ध करतो। डीकॅप्स्युलेट झालेल्या पॅकेटला नंतर काय होते याबद्दल तो काहीही सांगत नाही।

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

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

DNS आणि अयशस्वी स्थिती, स्वतंत्रपणे तपासलेली

प्रोटोकॉल स्वतः कोणत्याही अनुप्रयोगाचा रिझॉल्व्हर कॉन्फिगर करत नाही। wg-quick वितरणाच्या रिझॉल्व्हर एकात्मतेद्वारे ओळ DNS लागू करते, स्वतःचे स्टॅक असलेली कंटेनर आणि ब्राउझर ती दुर्लक्षित करू शकतात, आणि म्हणून टनल पॅकेट अगदी व्यवस्थित वाहत असतानाही नाव अयशस्वी होऊ शकते। पत्त्याऐवजी होस्टनेमने चाचणी करा, आणि प्रोफाइलमधील सर्व्हरने उत्तर दिले असे गृहीत धरण्याऐवजी कोणत्या सर्व्हरने उत्तर दिले ते नोंदवा।

पत्ता कुटुंबे वेगळ्या उत्तरासह वेगळी चाचणी आहेत। v4 डीफॉल्ट कोणत्याही अनुप्रयोगाच्या v6 जोडणीचे काय होईल याबद्दल काहीही सांगत नाही, आणि दुसरे कुटुंब शांतपणे गळणारी टनल मोठ्याने अयशस्वी होणाऱ्या टनलपेक्षा वाईट आहे। प्रत्येक कुटुंबावर नाव विचारा, प्रत्येक विनंतीने वापरलेला इंटरफेस वाचा, आणि भाषांतर काउंटर आधी व नंतर तपासा, कारण कशाशीही जुळणारा नसलेला नियम गहाळ नियमासारखाच दिसतो।

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