તપાસો ક્રમમાં કરો: નિયંત્રણ જોડાણ ખૂલે છે કે નહીં, GRE માર્ગ પર ટકે છે કે નહીં, સર્વર કૉલ સ્વીકારે છે કે નહીં, અને પ્રમાણીકરણ પૂર્ણ થાય છે કે નહીં. PPTP ક્લાયન્ટને 1723 પર TCP સેશન અને માહિતી વહન કરતો GRE માર્ગ બંને જોઈએ, અને હોટસ્પોટ એકને પસાર કરીને બીજાને પડતું મૂકી શકે છે. તેમને ક્રમમાં કરવાથી અનુમાન કરવાને બદલે કઈ સીમા તપાસવી તે ખબર પડે છે. Windows ના ભૂલ નંબર તમારા માટે એ કરતા નથી.

GRE એ IP પ્રોટોકોલ 47 છે. તે TCP કે UDP પોર્ટ 47 નથી, અને એ ભેદ ફાયરવોલ વિશેની મોટાભાગની ગૂંચવણ સમજાવે છે.

બે માર્ગ, એક જોડાણ

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

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

હોટસ્પોટ વધુ બે સીમા ઉમેરે છે

ક્લાયન્ટ ટ્રાફિક સામાન્ય રીતે ફોનના પોતાના શેરિંગ NAT અને પછી સર્વર સુધી પહોંચતા પહેલાં ઓપરેટર-સ્તરના અનુવાદમાંથી પસાર થાય છે. ઑફિસ રાઉટર પરનો નિયમ બીજા કોઈના માલિકીના મધ્ય-બૉક્સને સુધારી શકતો નથી, તેથી ઘરની બાજુનું પોર્ટ ફોરવર્ડિંગ ભાગ્યે જ મદદ કરે છે. બહાર જતા ક્લાયન્ટને અંદર આવતું પોર્ટ ખોલવાની પણ જરૂર નથી; અનુવાદિત જોડાણના જવાબ ગેટવેએ બનાવેલી સ્થિતિ દ્વારા પાછા આવે છે. NAT પાછળ હોસ્ટ કરેલા સર્વરની જરૂરિયાતો સંપૂર્ણપણે અલગ છે.

PPTP passthrough નામની મેનુ આઇટમ, જ્યાં હોય ત્યાં, તે ઉપકરણ આ પ્રોટોકોલને કેવી રીતે સંભાળે છે તે નક્કી કરે છે. તે ફોન પર VPN હોસ્ટ કરવા કે દરેક પ્રોટોકોલને બિનશરતી ફોરવર્ડ કરવાની સમાન સુવિધા નથી, અને તેને સક્ષમ કરવું GRE પસાર કરવાની સામાન્ય પરવાનગી નથી.

807 ને ચુકાદો નહીં, અવરોધ તરીકે વાંચો

Windows 807 ને અવરોધિત જોડાણ તરીકે જણાવે છે, જે કારણને બદલે પરિણામનું વર્ણન કરે છે. તેનું ભૂલ કોષ્ટક 806 ને GRE-સંબંધિત શ્રેણી તરીકે અલગ ગણે છે, અને સિદ્ધાંત બનાવતા પહેલાં એ ભેદ જાણવા યોગ્ય છે. બંનેમાંથી કોઈ નંબર એ જાહેર કરતું નથી કે ઓપરેટરે પ્રોટોકોલ 47 ફિલ્ટર કર્યો, સર્વરની ક્ષમતા ખતમ થઈ, કે ઓળખપત્રો સાચા હતા. ભૂલ કહે છે કે સેશન સમાપ્ત થયું; માર્ગ કહે છે ક્યાં.

હોટસ્પોટ પર સફળ બ્રાઉઝર પરીક્ષણ ફક્ત એ પુરવાર કરે છે કે સામાન્ય એપ્લિકેશન માર્ગ કામ કરે છે. તે GRE વિશે કંઈ કહેતું નથી.

નિષ્ફળ ગયેલો તબક્કો અલગ કરો

લેપટોપ, સર્વર અને પ્રોફાઇલ સ્થિર રાખો, પછી ફક્ત ઍક્સેસ નેટવર્કને બીજા મંજૂર નેટવર્કમાં બદલો. પરિણામ બદલાય તો, તમે નિયંત્રિત કરો છો તે સીમાઓ પર TCP અને GRE વિનિમય કેપ્ચર કરો અને સૌથી વહેલો તબક્કો શોધો જે ક્યારેય થતો નથી: નિયંત્રણ સ્થાપના, કૉલ સેટઅપ, માહિતી વિતરણ, કે PPP પ્રમાણીકરણ. દરેક કેપ્ચરમાં અલગ હસ્તાક્ષર છોડે છે. કાર્યકારી નેટવર્કની નિષ્ફળ જતા નેટવર્ક સાથે સરખામણી ભૂલનું લખાણ ફરી વાંચવા કરતાં ઘણી વધુ માહિતીપ્રદ છે.

આ બધું પહેલેથી અસ્તિત્વમાં રહેલી તૈનાતીનું નિદાન કરે છે. તે નવી PPTP સેવા ઊભી કરવા માટેની દલીલ નથી, અને પ્રોટોકોલને વાટાઘાટ કરીને ટાળી શકાતો નથી: અલગ ક્લાયન્ટ સ્થાપિત કરવાથી અપરિવર્તિત સર્વર બીજું કંઈ બોલતું નથી.

સતત ઍક્સેસ માટે, VPN ના માલિક સાથે સમર્થિત સ્થળાંતર પર સંમત થાઓ. ચેકલિસ્ટ કોઈ ઉપાયને બદલે નિર્ણય સાથે પૂરી થાય છે.

સંબંધિત લેખો