MikroTik PPTP टूट रहा है? सर्वर तक का रूट ठीक करें

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

समाधान एक रूट है, या एक सेटिंग, जो सर्वर को भौतिक WAN से पहुँच योग्य रखती है। कौन सा, यह इस पर निर्भर करता है कि राउटर को पूरी सुरंग का गेटवे होना है या नहीं।

लक्षण: जुड़ता है, ट्रैफ़िक भेजता है, मर जाता है

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

PPTP इसे आसान बनाता है क्योंकि ट्रांसपोर्ट सर्वर के पते तक सादा IP है, कोई ऐसी सुरंग नहीं जिसका दूसरा सिरा किसी और सबनेट में हो। जो भी उस पते को मोड़ता है, ट्रांसपोर्ट को भी साथ मोड़ता है।

सुरंग अपने ही पैकेट क्यों निगल जाती है

जब क्लाइंट जुड़ता है, वह ऐसा रूट लगाता है जिसका गेटवे सुरंग का इंटरफ़ेस है। अगर प्रोफ़ाइल डिफ़ॉल्ट रूट भी लगाती है, तो बिना अधिक विशिष्ट मेल वाला हर गंतव्य, सर्वर का सार्वजनिक पता भी शामिल, सुरंग में जाकर हल होता है। राउटर पैकेट को एनकैप्सुलेट करता है, बाहरी पैकेट को सर्वर का पता देता है और फिर रूट खोजता है: वही गंतव्य, वही डिफ़ॉल्ट, वही सुरंग। रिलीज़ के अनुसार यह रिकर्सन गिरा दिया जाता है, कतार में डाल दिया जाता है, या तब तक लूप में घुमाया जाता है जब तक सामने वाला हार न मान ले और सत्र न काट दे।

उपकरण निर्माता अक्सर अपने सर्वर के लिए स्वचालित रूप से होस्ट रूट जोड़ते हैं, ठीक इससे बचने के लिए। RouterOS ऐसा नहीं मानता, इसलिए ऑपरेटर को अपवाद व्यक्त करना होता है या शुरू से ही डिफ़ॉल्ट रूट से बचना होता है।

सर्वर का पता WAN पर पिन करें

सबसे संकरा संभव रूट जोड़ें: सर्वर के सार्वजनिक पते के लिए /32, अगले हॉप के रूप में ISP गेटवे के साथ, उस इंटरफ़ेस पर जो इंटरनेट तक पहुँचता है। /32 प्रीफ़िक्स लंबाई से किसी भी डिफ़ॉल्ट को हरा देता है, और अगर उसी प्रीफ़िक्स के लिए पहले से दूसरा रूट है तो कम दूरी जीतती है। फिर दोबारा जुड़ें और पुष्टि करें कि रूट सक्रिय है, केवल सूची में मौजूद नहीं।

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

अगर ISP गेटवे DHCP से सीखा जाता है, तो वही गेटवे पता इस्तेमाल करें जो DHCP ने लगाया है, या अगर रिलीज़ समर्थन करती है तो रूट को इंटरफ़ेस से बाँध दें। अगली लीज़ पर बदलने वाला हार्डकोड किया गेटवे एक विलंबित विफलता है। WAN दोबारा जुड़ने के बाद पता जाँचें, क्योंकि तभी पुराना गेटवे सामने आता है और सुरंग फिर से टूटने लगती है।

या सुरंग को डिफ़ॉल्ट पर दावा करने से रोकें

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

पूरी सुरंग की अपनी माँगें हैं: चुने गए स्रोतों के लिए पॉलिसी रूटिंग, वापसी ट्रैफ़िक की योजना, और सुरंग गिरने पर क्या होगा इसका निर्णय। इनमें से कुछ भी होस्ट रूट हल नहीं करता, जो केवल ट्रांसपोर्ट को ज़िंदा रखता है।

परतों में जाँचें, फिर प्रबंधन का छेद बंद करें

परतों में परखें: जुड़ने से पहले सर्वर के सार्वजनिक पते पर पिंग करें, जुड़ने के बाद दूरस्थ गेटवे पर पिंग करें, फिर दूरस्थ LAN के किसी होस्ट पर पिंग करें। अगर राउटर के पीछे के होस्ट को जवाब इसी के ज़रिये वापस चाहिए, तो सुरंग इंटरफ़ेस पर masquerade जोड़ें।

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

फिर राउटर रीबूट करें या WAN का दोबारा जुड़ाव थोपें और तीनों पिंग दोहराएँ, क्योंकि केवल चल रही कॉन्फ़िग में मौजूद रूट नहीं टिकेगा। बैकअप फ़ाइल में निर्यात की गई और बाद में बहाल की गई कॉन्फ़िग वह दूसरी जगह है जहाँ यह टूटता है, क्योंकि रनटाइम में जोड़ा गया रूट निर्यात में न हो।

अंत में, कोई भी VPN या रूट बदलाव प्रकाशित करने से पहले Winbox और वेब प्रबंधन को ज्ञात स्रोत पतों तक सीमित करें। सुरंगें ख़त्म करने वाला राउटर प्रबंधन का लक्ष्य होता है, और पूरी दुनिया के लिए खुला पोर्ट 80 उस रूट से बड़ी खोज है जिसे आपने अभी ठीक किया।