PPTP અને L2TP/IPsec વપરાશકર્તાનામની પૂછપરછ પહેલાં કેમ અટકે છે?
વપરાશકર્તાનામની પૂછપરછ ન આવવાનો અર્થ છે કે PPP ક્યારેય શરૂ થયું નહીં, તેથી ખામી પરિવહન, કીની અદલાબદલી કે ટનલ ગોઠવણીમાં છે. ફરી ઇન્સ્ટોલ કરતાં પહેલાં તબક્કાનો ક્રમ તપાસો.
વપરાશકર્તાનામની પૂછપરછ ન આવવી એ નિદાનની ભેટ છે: PPP હજી શરૂ થયું નથી, તેથી ખાતું, પાસવર્ડ અને ડોમેન નીતિ હજી પૂછવામાં આવ્યાં નથી. PPTP કે L2TP/IPsec જોડાણમાં ક્લાયન્ટ પ્રમાણપત્રો માગે છે ત્યારે જ, જ્યારે ટનલ અસ્તિત્વમાં હોય અને સર્વરે PPP સત્ર શરૂ કર્યું હોય. તે ક્ષણ પહેલાં જે નિષ્ફળ જઈ શકે તે પરિવહન, કીની અદલાબદલી કે ટનલ ગોઠવણી છે, જે «VPN બગડેલું છે» કરતાં ઘણું નાનું ક્ષેત્ર છે.
ખૂટતી પૂછપરછ ખામીને ત્રણ તબક્કામાં સંકોચે છે
છેલ્લો તબક્કો લખી રાખો જે દેખીતી રીતે સફળ થયો, કારણ કે દરેકનો માલિક અને ઉપાય અલગ છે. બે તબક્કા પહેલાં અટવાયેલા હોવ ત્યારે ખાતાની ગોઠવણીનો અંદાજ કાઢવો એ બપોર કેમ ખોવાય છે તેની રીત છે.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
પૂછપરછ વગર સમય પૂરો થતાં ક્લાયન્ટને ક્યારેય IPsec સંકલન મળ્યું નહીં, તેથી ખામી IKEમાં છે અથવા તમારા પેકેટ ગેટવે સુધી પહોંચે છે કે નહીં તેમાં. જે ક્લાયન્ટ પ્રમાણપત્રો ચકાસવાનું કહીને પછી પડી જાય છે તે સંદેશ સૂચવે તેનાથી આગળ ગયો હતો. પૂછપરછ પછી અસ્વીકાર આવે તો તે PPP પ્રમાણીકરણ છે, અને તેનું સ્થાન ખાતા વિશેના લેખમાં છે, આ લેખમાં નહીં.
પ્રથમ તબક્કો: જે પ્રોટોકોલ ફાયરવોલ ચૂપચાપ ફેંકી દે છે
PPTPને તેના નિયંત્રણ ચેનલ માટે TCP 1723 અને ડેટા માર્ગ માટે IP પ્રોટોકોલ 47 જોઈએ, અને બંને અલગ મુસાફરી કરે છે. ઘણા નેટવર્ક 1723 આગળ મોકલે છે અને પ્રોટોકોલ 47 ફેંકી દે છે, જે એવી ટનલ બનાવે છે જે વાટાઘાટ કરે અને પછી કંઈ જ વહન ન કરે. NAT કરતા રાઉટરને GRE-સક્ષમ પસારથી પણ જરૂર હોય છે, અને ફક્ત IPv6 આધારિત એક્સેસ માર્ગ કોઈ પણ ગોઠવણીમાં PPTP વહન કરી શકતો નથી.
IPsec પરનું L2TP IKE માટે પોર્ટ 500 અને NAT ઓળંગવા માટે પોર્ટ 4500 વાપરે છે, પછી L2TP ટ્રાફિકને જ 1701માં લપેટે છે, જ્યારે સંકલન બન્યા પછી ESP સુરક્ષિત પેલોડ વહન કરે છે. બે નિયંત્રણ પોર્ટની પરવાનગી આપો પણ ESPની નહીં, અને તમને બરાબર શીર્ષકનું લક્ષણ મળશે: દેખાતી પ્રગતિ, પછી કોઈ પણ પ્રમાણપત્ર સંવાદ પહેલાં મૃત ક્લાયન્ટ. ફોન હોટસ્પોટથી પરીક્ષણ કરવું ક્લાયન્ટની સમસ્યાને માર્ગની સમસ્યાથી અલગ પાડવાનો સસ્તો રસ્તો છે.
બીજો તબક્કો: જે કી કી નથી, જે દરખાસ્ત આપવામાં આવતી નથી
ન મળતી પૂર્વ-શેર કરેલી કી ઝડપથી અને ચૂપચાપ નિષ્ફળ જાય છે, અને સામાન્ય સ્વરૂપ એ કી છે જે સ્ક્રીન પર સાચી લાગે છે પણ પેસ્ટ કરેલો લાઇન બ્રેક કે અંતે સ્પેસ ધરાવે છે. Linux ક્લાયન્ટ પર સંવાદ એ જરૂરી નથી કે સત્યનો સ્રોત હોય: NetworkManagerનું L2TP પ્લગઇન રહસ્યોને /etc/ipsec.d/ નીચેની ફાઇલોમાં રાખે છે, અને /etc/ipsec.secrets હજી ધરાવતી જૂની પ્રતિ-જોડાણ ફાઇલ તમે હમણાં ટાઇપ કરેલી ફાઇલને બદલે વપરાશે. તે ફાઇલને સુરક્ષિત જગ્યાએ નકલ કરો, સમાવેશ માર્ગમાંથી બહાર કાઢો, અને પછી કી હાથે ફરી ટાઇપ કરો.
આ તબક્કાનો બીજો અડધો ભાગ દરખાસ્ત છે. બંને છેડાએ સમાન 1લી ફેઝના અલ્ગોરિધમ સમૂહ — એન્ક્રિપ્શન, અખંડિતતા અને Diffie-Hellman જૂથ — અને 2જી ફેઝ માટે મેળ ખાતા ESP રૂપાંતરણો પર સહમત થવું પડે, નહીં તો સંકલન બિલકુલ બનતું નથી. જે ગેટવે ફક્ત 3DES, SHA1 અને MODP1024 આપે છે તે મજબૂત અલ્ગોરિધમ માટે ગોઠવાયેલા ક્લાયન્ટને નકારશે, અને તેનો લોગ નકારેલા રૂપાંતરણનું નામ આપે છે. સેવાને ફરી શરૂ કરવાને બદલે લોગ વાંચો તો લોગ જ અસંગતિનું નામ આપે છે. ફોરમ થ્રેડમાંથી અલ્ગોરિધમ શબ્દમાળા નકલ કરવાને બદલે ગેટવેને પૂછો કે તે ખરેખર કયા રૂપાંતરણોની વાટાઘાટ કરશે: તેના સરનામા પર તાકેલું ike-scan વાટાઘાટ કરશે તે રૂપાંતરણો પરત આપે છે. જો એકમાત્ર ઓફર એવી ક્રિપ્ટોગ્રાફી હોય જે તમારી નીતિ હવે પરવાનગી આપતી નથી, તો સુધારો ગેટવે પર છે, ક્લાયન્ટને નીચું ઉતારવામાં નહીં.
Windowsમાં કી અને પ્રમાણીકરણ પદ્ધતિ VPN પ્રોફાઇલમાં રહે છે, અને અસંગતિ પ્રમાણપત્રની પૂછપરછ પછી નહીં પણ પહેલાં દેખાય છે. જ્યાં પ્રાપ્તકર્તા Windows Server હોય ત્યાં ખાતરી કરો કે દૂરસ્થ એક્સેસ ભૂમિકા સ્થાપિત છે, પ્રમાણપત્ર એ નામ સાથે મેળ ખાય છે જેના પર ક્લાયન્ટ જોડાય છે, અને કોઈ પોર્ટ ફિલ્ટર ઉપરના પ્રોટોકોલ કરતાં સાંકડું નથી.
ત્રીજો તબક્કો: ટનલ છે અને PPP શરૂ થતું નથી
IKE પૂરું થયા પછી પણ પૂછપરછ ન આવે તો ફાયરવોલ નહીં, ટનલ ડિમન તપાસો. L2TPને UDP 1701 પર સાંભળતું કંઈક જોઈએ — Linuxમાં xl2tpd કે kl2tpd, Windowsમાં દૂરસ્થ એક્સેસ સેવા — અને સ્થાપિત પણ બંધ સેવા ક્લાયન્ટની બાજુથી ફેંકાયેલા પેકેટ જેવી જ દેખાય છે. તમે પહેલેથી ચકાસેલા નિયમો ફરી ખોલતાં પહેલાં શ્રોતાને તપાસો. પછી PPPએ વાટાઘાટ કરવી પડે, અને પ્રથમ LCP અદલાબદલી એ જ જગ્યા છે જ્યાં શાંત નિષ્ફળતા સામાન્ય રીતે ઉતરે છે.
આ તબક્કાનો એક છટકું બિલકુલ નેટવર્ક ખામી નથી: Windows એક સમયે આપેલા VPN પ્રકારનું ફક્ત એક જ જોડાણ મંજૂર કરે છે, તેથી બીજો પ્રયાસ ભૂલ 937 આપે છે, «આ પ્રકારનું બીજું જોડાણ વપરાશમાં છે». તે સ્થાનિક નિયમ છે, અને તેની આસપાસનો રસ્તો બીજું ઉપકરણ, બીજો ટનલ પ્રકાર, કે પહેલેથી અસ્તિત્વમાં રહેલા એક જ જોડાણને વહેંચવો છે.
અંદાજ કાઢવાને બદલે તબક્કાના ક્રમમાં લોગ વાંચો
ક્લાયન્ટ બંધ કરો, ફરી શરૂ કરો, અને ઘટકોને જે ક્રમમાં લોગ લખે છે તે ક્રમમાં વાંચો. એટલે પહેલાં IPsec ડિમન — strongSwan કે Libreswan, અને ipsec --version કહે છે કયું — પછી L2TP ડિમન, પછી pppd. નિષ્ફળતા પહેલાં જે ઘટકે છેલ્લે લખ્યું તે તપાસવાનો તબક્કો દર્શાવે છે, કારણ કે ક્રમમાં તેના પછી આવતું કંઈ જ ચાલ્યું નથી.
સાચવેલા સત્રને બદલે નવા જોડાણથી ચકાસો, કારણ કે કેશમાંથી ફરી જોડાતો ક્લાયન્ટ અદલાબદલીના ભાગ છોડી દઈને જૂનું પરિણામ પુનરુત્પન્ન કરી શકે છે. પહોંચ, કીની અદલાબદલી, ટનલ અને PPP એક પછી એક, તે જ ક્રમમાં ખાતરી કરો. ત્યારે ખૂટતી પૂછપરછ રહસ્ય રહેવાનું બંધ કરે છે અને એવી યાદીની બીજી લાઇન બને છે જેના પર ખરેખર કામ કરી શકાય. તે યાદી જ તમે નેટવર્ક ટીમને આપો છો, જેને નહીં તો એવી ખામી માટે ફાયરવોલ તપાસવાનું કહેવાય જે ચાલુ ન થયેલા ડિમનમાં રહે છે.