DD-WRT पर PPTP क्लाइंट एक-दूसरे तक नहीं पहुँचते: पाँच जाँचें

दो लैपटॉप DD-WRT बॉक्स पर PPTP सर्वर पर डायल करते हैं, दोनों को एक पता मिलता है, और कोई भी दूसरे को पिंग नहीं कर सकता। साझा फ़ोल्डर कभी दिखाई नहीं देते और पहला विचार यही आता है कि राउटर जो 255.255.255.255 मास्क दे रहा है वह ज़रूर ग़लत है। यह दोष नहीं है, और इसे बदलने से एक भी नया पड़ोसी नहीं बनेगा। नीचे दी गई पाँच जाँचें क्रम से करें और जैसे ही कोई एक विफल हो वहीं रुकें, क्योंकि हर एक का इलाज अलग है।

जाँच एक: /32 कोई बग नहीं है

PPTP, PPP ले जाता है, और PPP लिंक ठीक दो सिरों को जोड़ता है: आपका क्लाइंट और सर्वर। नेटमास्क बताता है कि कौन से पते एक स्थानीय खंड साझा करते हैं, और यहाँ कोई खंड नहीं है, बस एक तार के दूसरे छोर पर पीयर है। सब-एक वाला मास्क ठीक यही कहता है, इसलिए DD-WRT इस लिंक प्रकार के लिए सही मान दे रहा है। यह पता पीयर का पता है, LAN पर किसी इंटरफ़ेस का पता नहीं।

255.255.255.0 मास्क सैकड़ों उपकरणों वाले साझा माध्यम का है, और इसे PPP इंटरफ़ेस पर रखने से टनल का दूसरा सिरा भी पड़ोसी नहीं बनेगा।

जाँच दो: PPTP सर्वर पेज के मान पढ़ें

जो भी सेटिंग मायने रखती है वह सेवाएँ, VPN, PPTP सर्वर में है। सर्वर चालू करें, सर्वर पता राउटर के LAN पते पर सेट करें, और क्लाइंट श्रेणी को DHCP पूल से बाहर रखें ताकि डायल-इन क्लाइंट और तार वाली मशीन को एक ही पता न मिले। CHAP-Secrets के अंतर्गत हर खाते के लिए username * password * के रूप में एक पंक्ति जोड़ें, नाम के भीतर कोई स्थान नहीं। लागू करें, फिर ऐसी प्रोफ़ाइल से जुड़ें जो राउटर और उन खातों में से एक का नाम लेती हो।

क्लाइंट कहाँ रुकता है यह बताता है कि कौन-सी परत देखनी है। जो क्लाइंट प्रमाणित होता है पर पता नहीं पाता वह पूल या सीक्रेट की समस्या है; जो क्लाइंट पता पाकर कहीं नहीं पहुँचता वह रूटिंग या फ़ायरवॉल की समस्या है।

जाँच तीन: दोनों पीयर के बीच रूट खोजें

राउटर पर समाप्त होने वाली हर टनल अपना अलग इंटरफ़ेस होती है, आम तौर पर ppp0, ppp1 इत्यादि। एक क्लाइंट से दूसरे तक का ट्रैफ़िक इन इंटरफ़ेस के बीच रूट होना चाहिए, और राउटर को उसे आगे भेजने के लिए तैयार होना चाहिए। राउटर पर ip route चलाएँ और हर जुड़े पीयर के लिए ऐसा होस्ट रूट खोजें जो मेल खाते PPP इंटरफ़ेस की ओर इशारा करे। अगर किसी पीयर के पास रूट नहीं है, तो क्लाइंट की स्थिति स्क्रीन कुछ भी कहे, टनल पूरी तरह ऊपर नहीं है।

दो अलग ppp इंटरफ़ेस की ओर दो होस्ट रूट वही आकार है जो आगे बढ़ने से पहले आप चाहते हैं।

जाँच चार: FORWARD चेन देखें, INPUT नहीं

क्लाइंट-से-क्लाइंट ट्रैफ़िक आगे भेजा जाता है, स्थानीय रूप से स्वीकार नहीं किया जाता, इसलिए INPUT चेन ग़लत जगह है। iptables -L FORWARD -v -n चलाएँ और PPP इंटरफ़ेस को पकड़ने वाला ड्रॉप नियम खोजें, साथ में पैकेट काउंटर जो दिखाते हैं कि चेन तक कुछ पहुँचता है या नहीं। टनल ट्रैफ़िक के लिए स्वीकृति नियम के बिना डिफ़ॉल्ट ड्रॉप नीति ठीक वही लक्षण पैदा करती है जिससे आपने शुरू किया था: हर क्लाइंट अकेला ठीक है, साथ में वे एक-दूसरे के लिए अदृश्य हैं।

अगर छोटे पिंग चलते हैं और बड़े स्थानांतरण अटकते हैं, तो टनल अवरुद्ध नहीं हो रही, खंडित हो रही है। PPP पर PPTP सामान्यतः लगभग 1450 का MTU और MRU चाहता है, और उन्हें 1500 पर छोड़ने से ऐसा लिंक मिलता है जो हैंडशेक पार कर जाता है और असली पेलोड पर विफल हो जाता है।

जाँच पाँच: तय करें कि इंटरनेट एक्सेस को क्या करना चाहिए

जो क्लाइंट दफ़्तर से होकर ब्राउज़ करेंगे उन्हें WAN इंटरफ़ेस की ओर स्रोत अनुवाद चाहिए। जिन्हें सिर्फ़ LAN तक पहुँचना है उन्हें एक रूट और कुछ नहीं चाहिए। ये अलग इरादे हैं अलग नियम-समूहों के साथ, और मास्क का सवाल इस दूसरे फ़ैसले को पूरी तरह छिपा देता है। एक भी नियम जोड़ने से पहले लिख लें कि आप कौन-सा व्यवहार चाहते थे, क्योंकि अचानक दफ़्तर की लाइन से बाहर निकलने वाला क्लाइंट ऐसा आश्चर्य है जो लॉग में नहीं, बैठक में सामने आता है।

आख़िरी बात, जो सुधार से असंबंधित है: PPTP पुराना है और उसका प्रमाणीकरण वर्षों से टूटा हुआ है। ऊपर की सूची फिर भी बताती है कि PPP लिंक क्या करता है, और वही तर्क लागू होता है अगर बाद में क्लाइंट को आधुनिक टनल पर ले जाएँ।