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 लिंक काय करते ते स्पष्ट करते, आणि पुढे क्लायंटना आधुनिक बोगद्यावर हलवल्यास तोच तर्क लागू होतो.