PPTP પાસથ્રુ ખૂટે છે: Windows VPN ની ભૂલ 807 સુધારો

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

પોર્ટ ટેબલમાં પ્રોટોકોલ નંબર માટે કોઈ પંક્તિ નથી

PPTP બે વાતચીતો વાપરે છે જે અલગ રીતે નિષ્ફળ જાય છે. TCP 1723 પરની વાતચીત કૉલ શરૂ કરે છે, લિંકની માહિતી પસાર કરે છે અને વપરાશકર્તા ડિસ્કનેક્ટ થાય ત્યારે તેને બંધ કરે છે. પેલોડ બાજુ GRE ની અંદર ચાલે છે, જેને IP હેડર પ્રોટોકોલ નંબર 47 થી ચિહ્નિત કરે છે, અને તે ટનલની અંદર PPP લિંક પર વાટાઘાટ કરે છે જ્યારે MS-CHAPv2 ઓળખપત્રો ચકાસે છે.

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

ડેટા માર્ગ મરે ત્યારે Windows શું જણાવે છે

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

પાસવર્ડને અડકતા પહેલાં પરિવહન પર કામ કરો. 807 નો પીછો કરવા ઓળખપત્રો બદલવાથી ખરી ખામી જ્યાં છે ત્યાં જ રહે છે અને આગળનો પ્રયાસ વાંચવો વધુ અઘરો બને છે.

બીજો ક્લાયન્ટ કાર્યરત ટનલને કેમ તોડે છે

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

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

કયો અડધો ભાગ નિષ્ફળ જાય છે તે સાબિત કરો

રાઉટર પર કંઈપણ બદલતા પહેલાં ખાતરી કરો કે TCP 1723 આવે છે, કારણ કે એ જ જવાબ નક્કી કરે છે કે તમે કયો અડધો ભાગ ચકાસી રહ્યા છો. આ Windows ક્લાયન્ટથી તમારા પોતાના સર્વર નામ સામે ચલાવો. પહેલું છાપે છે કે પોર્ટે જવાબ આપ્યો કે નહીં, અને બીજું કોઈ સંવાદ વિના ડાયલ કરે છે, જે વારંવારના પ્રયાસોને તુલનાત્મક બનાવે છે.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

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

tcpdump -ni any proto 47

Wireshark માં તેનું સમકક્ષ ડિસ્પ્લે ફિલ્ટર ip proto 47 છે, જે કમાન્ડ લાઇનમાં સગવડ ન હોય તેવા કોઈને આપવું સહેલું છે. જવાબમાં કંઈ બહાર ન જતું હોય તેમ GRE આવે તો અર્થ એ છે કે પરત માર્ગ સુધારવો પડશે.

એ ભૂલ ખરેખર શું સુધારે છે

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

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP ને બદલવો એ બીજો વિકલ્પ છે અને ઘણી વાર સસ્તો પણ છે. જે રાઉટર પોતે VPN સમાપ્ત કરે છે તે આવતા ક્લાયન્ટ માટે બેવડા NAT ટાળે છે, અને પોર્ટ-આધારિત NAT પહેલેથી સંભાળે છે તેવા પ્રોટોકોલને પાસથ્રુની જરૂર જ નથી: UDP પર OpenVPN, TCP 443 પર SSTP, અથવા NAT-T સાથે L2TP/IPsec જે ESP ને UDP 4500 માં લપેટે છે. PPTP MS-CHAPv2 પર પણ આધાર રાખે છે, જેની દસ્તાવેજી નબળાઈઓ ભૂલ દૂર થયા પછી પણ તેને નવા ડિપ્લોયમેન્ટ માટે ખરાબ પસંદગી બનાવે છે.

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