PPTP વિભાજિત ટનલિંગ કામ કરતું નથી: પહેલાં GRE માર્ગ સુધારો

PPTP કનેક્શન ઉપર આવતું જુઓ અને માનવું સહેલું છે કે મુશ્કેલ ભાગ પૂરો થઈ ગયો: ક્લાયન્ટ પ્રમાણીકરણ કરે છે, ppp0 એડાપ્ટર અથવા WAN Miniport દેખાય છે, અને સ્થિતિ વિન્ડો લીલી થઈ જાય છે. પછી આંતરિક હોસ્ટ માટે પહેલી વિનંતી સમયસીમા વટાવે છે, અને પ્રોફાઇલને દોષ આપવામાં આવે છે. વ્યવહારમાં બે સ્વતંત્ર સ્તરો સાફ કરવાના હોય છે: બહારનું પરિવહન જે TCP 1723 અને GRE વહન કરે છે, અને આંતરિક નીતિ જે નક્કી કરે છે કે કઈ ગંતવ્યો PPP ઇન્ટરફેસ વાપરે. લીલી સ્થિતિ ફક્ત સાબિત કરે છે કે પહેલું સ્તર વાટાઘાટમાં આવ્યું; બીજા વિશે તે કંઈ કહેતું નથી.

પ્રોફાઇલથી કંટ્રોલ સોકેટ સુધી ક્લાયન્ટને અનુસરો

ક્લાયન્ટ લોગ ખોલો અને જ્યાં તે સર્વરનો સંપર્ક કરે છે તે બિંદુ શોધો. PPTP પહેલાં પોર્ટ 1723 પર TCP કનેક્શન ખોલે છે અને તે ચેનલ પર ટનલ પરિમાણોની વાટાઘાટ કરે છે. જો આ પગલું નિષ્ફળ જાય, તો પછીનું કંઈ મહત્વનું નથી, અને ભૂલ સામાન્ય રીતે સર્વર સરનામું અથવા સમયસીમા જણાવે છે.

કોઈપણ માર્ગને સ્પર્શ કરતા પહેલાં વાયર પર કંટ્રોલ કનેક્શનની પુષ્ટિ કરો. ક્લાયન્ટ પર અથવા મિરર પોર્ટ પર, એક કનેક્શન પ્રયાસ માટે TCP 1723 કેપ્ચર કરો:

sudo tcpdump -ni any 'tcp port 1723' -c 20

પૂર્ણ હેન્ડશેક અને સ્થાપિત સત્રનો અર્થ છે કે બહારની કંટ્રોલ ચેનલ કામ કરે છે. જે SYN ને ક્યારેય SYN-ACK મળતું નથી તે ફાયરવોલ, ખોટું સર્વર સરનામું અથવા પોર્ટ ફિલ્ટર કરતા પ્રદાતા તરફ નિર્દેશ કરે છે. હેન્ડશેક પછી તરત જ રીસેટ આવવો ઘણી વાર એમ બતાવે છે કે સર્વરે ઓળખપત્રો અથવા ટનલનો પ્રકાર નકાર્યો છે.

GRE બીજો પ્રોટોકોલ છે, પોર્ટ નથી

PPTP વિસ્તૃત GRE, IP પ્રોટોકોલ 47 ની અંદર PPP પેલોડ વહન કરે છે, જેમાં રાઉટર ટ્રેક કરી શકે એવો કોઈ પોર્ટ નંબર નથી. એટલે જ TCP 1723 ને મંજૂરી આપતો નિયમ પણ ટનલને ડેટા માર્ગ વિના છોડી શકે છે. સ્ટેટફુલ NAT ઉપકરણોએ જવાબો પાછા મેપ કરવા GRE ની અંદરનું કૉલ ID સમજવું પડે છે, અને ઘણા એમ કરતા નથી. PPTP સ્પષ્ટીકરણ કંટ્રોલ ચેનલ અને GRE પેલોડને અલગ ભાગો તરીકે રાખે છે, અને તમારી પરીક્ષણ યોજનાએ પણ એમ જ કરવું જોઈએ.

એ જ કેપ્ચરમાં પ્રોટોકોલ 47 જુઓ, પછી જે બહાર જાય છે અને જે પાછું આવે છે તેની સરખામણી કરો:

sudo tcpdump -ni any 'proto gre' -c 20

TCP 1723 સ્વસ્થ રહેતાં જવાબ વિના પેકેટ બહાર જવા એ અવરોધિત-GRE ની ઉત્તમ નિશાની છે. ગ્રાહક રાઉટર પર PPTP પાસથ્રુ તે ચોક્કસ ફર્મવેરનું લક્ષણ છે, તેથી કામ કરતું હોટેલ નેટવર્ક આગલા વિશે કંઈ સાબિત કરતું નથી. જો રાઉટર પાસથ્રુ આપતું નથી અને તમે તેને બદલી શકતા નથી, તો સમસ્યા રૂટ ટેબલ નહીં, પ્રોટોકોલની પસંદગી છે.

ટનલ એક પેકેટ ખસેડે છે તે સાબિત કરો

GRE વહેવા લાગે ત્યારે PPP વાટાઘાટ ક્લાયન્ટ ઇન્ટરફેસને સરનામું સોંપે છે. ધારવાને બદલે સોંપણી વાંચો:

ip -4 addr show ppp0

પોઇન્ટ-ટુ-પોઇન્ટ લિંકના ગંતવ્ય તરીકે દેખાતા પીઅર સરનામાને પિંગ કરો. આ તબક્કે જવાબ સાબિત કરે છે કે એન્કેપ્સ્યુલેટેડ માર્ગ શરૂઆતથી અંત સુધી કામ કરે છે અને સર્વર ટનલની અંદર જવાબ આપે છે. જો પીઅર જવાબ આપે પણ આંતરિક હોસ્ટ નહીં, તો બહારનું પરિવહન ઠીક છે અને નિષ્ફળતા અંદર ખસી ગઈ છે.

કોઈપણ વિભાજિત માર્ગ ઉમેરતા પહેલાં આ કરો. પરિવહન તૂટેલું હોય ત્યારે કરેલો માર્ગ ફેરફાર બીજું ચલ બનાવે છે અને પહેલાને છુપાવે છે.

વિભાજિત નીતિ લખો, DNS સહિત

વિભાજિત રૂટિંગ નિર્ણયોની યાદી છે, ચેકબોક્સ નહીં. ટનલ પાર કરવી પડે એવા દરેક ખાનગી પ્રીફિક્સને PPP ઇન્ટરફેસ દ્વારા માર્ગ જોઈએ, અને સ્થાનિક રહેવું પડે એવા દરેક પ્રીફિક્સ તેમાં ગેરહાજર હોવું જોઈએ. એપ્લિકેશન સબનેટ માટે તેના ખાનગી રિઝોલ્વર સુધીનો મેળ ખાતો માર્ગ વિના માર્ગ બનાવવો એ તૂટેલી એપ જેવું દેખાતું વિક્ષેપ ઊભું કરવાની સામાન્ય રીત છે.

દરેક શ્રેણીમાં એક સરનામા માટે કર્નલ જે નિર્ણય લે છે તે તપાસો:

ip route get 10.20.5.10
ip route get 203.0.113.25

પહેલાએ ppp0 અને બીજાએ સામાન્ય ગેટવેનું નામ આપવું જોઈએ. જો બંને એક જ ઇન્ટરફેસનું નામ આપે, તો નીતિ બિલકુલ વિભાજિત નથી. DNS સર્વરનું પોતાનું સરનામું ટનલ યાદીમાં ઉમેરો, નહીં તો આંતરિક હોસ્ટ માટે નામ ઉકેલ સ્થાનિક રિઝોલ્વર દ્વારા બહાર જાય છે અને કંઈ કામનું પાછું આપતું નથી.

પાંચ પગલાંમાં પુનરાવર્તનીય તપાસ

સ્તરો ક્રમમાં ચલાવો અને પહેલા નિષ્ફળ સ્તર પર અટકો: કંટ્રોલ ચેનલ, GRE દૃશ્યતા, PPP પીઅર જવાબ, એક આંતરિક સરનામા માટે વિભાજિત માર્ગ, અને ટનલ પર એપ્લિકેશન વિનંતી. દરેક પગલાનો પોતાનો આદેશ છે, તેથી નિષ્ફળતા રહસ્યમય નહીં પણ નિયુક્ત કરી શકાય તેવી છે.

Linux ક્લાયન્ટ માટે સંક્ષિપ્ત આવૃત્તિ આવી દેખાય છે:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Windows માં એ જ ક્રમ route print અને ક્લાયન્ટમાં દેખાતી એડાપ્ટર સ્થિતિ સાથે લાગુ પડે છે. PPTP જૂનો પ્રોટોકોલ છે, અને જો સર્વર SSTP અથવા IKEv2 આપે, તો દરેક હોપ પર પ્રોટોકોલ 47 પસાર થવા પર આધારિત માર્ગ ટ્યુન કરવા કરતાં ખસી જવું સામાન્ય રીતે સમયનો સારો ઉપયોગ છે. જૂની પ્રોફાઇલને નવી આવૃત્તિમાં કોપી કરવાને બદલે અવેજીનું પ્રમાણપત્ર અને પ્રમાણીકરણ કરાર તપાસો.