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 લિંક શું કરે છે, અને જો પછી ક્લાયન્ટને આધુનિક ટનલ પર ખસેડો તો એ જ તર્ક લાગુ પડે છે.