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 लिङ्कले के गर्छ भनेर बताउँछ, र पछि क्लाइन्टहरूलाई आधुनिक सुरुङमा सार्नुभयो भने पनि त्यही तर्क लागू हुन्छ।