VPNનું કયું તબક્કો નિષ્ફળ ગયું: IPsec, L2TP નિયંત્રણ કે PPP પ્રમાણીકરણ
છેલ્લો સફળ થયેલો તબક્કો શોધો અને ફક્ત તે સ્તર સુધારો: IPsec, L2TP નિયંત્રણ ચેનલ, PPP પ્રમાણીકરણ અથવા સરનામાની ફાળવણી.
તમે પાસવર્ડ બદલ્યો અને કંઈ ખસ્યું નહીં, કારણ કે નિષ્ફળતા ક્યારેય PPPમાં નહોતી. L2TP/IPsec પાંચ સાવ અલગ હેન્ડઓફ માટે એક જ કનેક્શન ભૂલ જણાવે છે, અને દરેક હેન્ડઓફનું પોતાનું સમારકામ છે. ઊલટું કામ કરો: છેલ્લો સફળ થયેલો તબક્કો શોધો અને ફક્ત તેના પછી આવતું બદલો. નીચેનો ક્રમ પણ નક્કી કરે છે કે પહેલાં કયા પુરાવા એકઠા કરશો.
ચાર પ્રશ્નોના જવાબ ક્રમમાં આપો
નવો પ્રયાસ ફરજિયાત કરો, કારણ કે કેટલાક ક્લાયન્ટ પ્રોફાઇલ ડિસ્કનેક્ટ અને ફરી કનેક્ટ ન થાય ત્યાં સુધી અગાઉની ભૂલ બતાવતા રહે છે. પછી આનો જવાબ આપો: IPsec સુરક્ષા સંલગ્નતા હતી કે નહીં, L2TP નિયંત્રણ જોડાણ અને કૉલ દેખાયા કે નહીં, PPP પ્રમાણીકરણના નિર્ણય સુધી પહોંચ્યું કે નહીં, અને IPCPએ ક્લાયન્ટને સરનામું આપ્યું કે નહીં? પહેલું ના એ જ તબક્કો છે જે તમે સુધારો છો. તેના પછીનું બધું કસોટી વગરનું છે, તેથી સંલગ્નતા ક્યારેય ન હોય તો નકારાયેલું વપરાશકર્તાનામ કંઈ સાબિત કરતું નથી.
તુલના કરતાં પહેલાં બંને છેડે ઘડિયાળો સિંક્રનાઇઝ કરો. જે પુનઃપ્રયાસ IPsec સાફ કરીને PPP પર નિષ્ફળ ગયો, તે એક જ નિષ્ફળતા જેવો લાગે છે જ્યારે ક્લાયન્ટ ફક્ત અંતિમ સંદેશ બતાવે અને સર્વર લોગ હજી અગાઉનો પ્રયાસ રાખે. સૌથી મોટા અવાજવાળી લાઇન પ્રમાણે નહીં, ટાઇમસ્ટેમ્પ પ્રમાણે વાંચો.
જ્યારે તમારી પાસે ફક્ત વપરાશકર્તાનો સ્ક્રીનશોટ હોય, ત્યારે સૌથી સસ્તા વિભાજન પર આધાર રાખો: ખોટી પૂર્વ-શેર કરેલી કી અને ક્યારેય જવાબ ન આપતું xl2tpd Windows સંવાદમાં એક જ લખાણ ઉત્પન્ન કરે છે, છતાં એકને બંને છેડે બદલાયેલું રહસ્ય જોઈએ અને બીજાને સર્વર પર જ ડેમન શરૂ કરવો કે ફાયરવોલ નિયમ જોઈએ. વચ્ચેનું ઉપકરણ આંતરિક 1701 કાઢી નાખી શકતું નથી, પછી ભલે ટ્રાન્સપોર્ટ-મોડ IPsecએ તેને લપેટ્યું હોય, તેથી ન હોય તેવું પથ-ફિલ્ટર શોધવા ન જાઓ.
દરેક સ્તર ખરેખર શું ધરાવે છે
IPsec બે પીઅર વચ્ચે પેકેટ સુરક્ષિત કરે છે; L2TP તે સુરક્ષિત પથની અંદર PPP સત્ર વહન કરે છે, તેથી જ RFC 3193 પોતાના ટનલને બદલે ટ્રાન્સપોર્ટ મોડ નિર્દિષ્ટ કરે છે. ક્લાયન્ટનું લેબલ L2TP કહે છે, તેથી ટનલ અને લોગિન એક જ મિકેનિઝમ લાગે છે. એવું નથી: L2TP નિયંત્રણ જોડાણ જ્યાં તૈનાતી તેને સક્ષમ કરે ત્યાં ટનલના અંતિમ બિંદુઓનું પ્રમાણીકરણ કરે છે, અને PPP સર્વર નીતિ હેઠળ CHAP, PAP કે MS-CHAPv2 વડે વપરાશકર્તાનું અલગથી પ્રમાણીકરણ કરે છે.
એ વિભાજન એ બે રહસ્યો સમજાવે છે જે લોકો વારંવાર ગૂંચવે છે. પૂર્વ-શેર કરેલી કી IPsec પીઅરનું પ્રમાણીકરણ કરે છે. વપરાશકર્તાનામ અને પાસવર્ડ PPP સમક્ષ વપરાશકર્તાને ઓળખે છે. જે પ્રોફાઇલ પ્રમાણપત્રો સાથે પ્રમાણીકરણ કરે તેના પર Windowsનું શેર કરેલું રહસ્ય ફરી ટાઇપ કરવાથી નિષ્ફળ તબક્કે કંઈ બદલાતું નથી, અને PPP પાસવર્ડ સંપાદિત કરવાથી ખૂટતી સુરક્ષિત ચેનલ મળી શકતી નથી. એ જ સંયમ ઓળખ-તપાસને લાગુ પડે છે: ટનલ મેળવવા પીઅર ઓળખ કે પ્રમાણપત્ર માન્યતા બંધ ન કરો, કારણ કે ત્યારે જોડાતો પથ છે, પીઅર નહીં.
પ્રમાણીકરણ એ PPPનો અંત પણ નથી. વપરાશકર્તા સ્વીકારાયા પછી IPCP ક્લાયન્ટનું સરનામું અને સર્વર જે DNS તથા WINS વિકલ્પો આપવા તૈયાર છે તેની વાટાઘાટ કરે છે. ક્લાયન્ટ CHAP કે MS-CHAPv2 પાસ કરીને પણ સરનામા વગર રહી શકે, જે રાઉટિંગ સમસ્યા નહીં પણ PPPની અંદરની નિષ્ફળતા છે. IPsec વગરનું સાદું L2TP માન્ય અને અસુરક્ષિત રહે છે, તેથી સફળ કનેક્શન ક્યારેય સાબિત કરતું નથી કે ટ્રાફિક સુરક્ષિત છે; સર્વર શું માગે છે તે તપાસો, ક્લાયન્ટનું લેબલ નહીં.
પહેલા ખૂટતા તબક્કા પરથી નક્કી કરો
કોષ્ટકને પહેલા ખૂટતા મદદ પ્રમાણે ડાબેથી જમણે વાંચો. જમણી કૉલમ એ જ સમયે કરવા લાયક એકમાત્ર કામ છે; તેની ડાબી બાજુનું બધું પહેલેથી સાબિત છે, અને તેને ફરી ચકાસવાથી માહિતી ઉમેરાયા વગર વિક્ષેપની વિન્ડો બળી જાય છે.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
ત્રણ પંક્તિઓ ચેતવણીને લાયક છે. 1701 પંક્તિ એ છે જ્યાં NAT પાછળના Windows ક્લાયન્ટ સામાન્ય રીતે ઉતરે છે: સંલગ્નતા પૂર્ણ થાય, પછી કંઈ આવતું નથી, અને કારણ ખરાબ પાસવર્ડ નહીં પણ એન્કેપ્સ્યુલેશન છે. IPCP પંક્તિ એ છે જેને ભૂલથી રાઉટ સમસ્યા તરીકે વાંચવામાં આવે છે, કારણ કે Windows ખૂટતા સરનામાને ભૂલ 720માં લપેટે છે અને ટ્રે આઇકન ફક્ત કહે છે કે કનેક્શન નિષ્ફળ ગયું; એ નિષ્ફળતા પ્રમાણીકરણ પછી અને રાઉટિંગ પહેલાં બેસે છે. છેલ્લી પંક્તિ બિલકુલ IPsec નિષ્ફળતા નથી, છતાં ટ્રે આઇકન ડિસ્કનેક્ટેડ કહે છે.
સ્તરોને અલગ કરતા આદેશો
strongSwan ચાલતા Linux સર્વર પર, swanctl --list-sas સ્થાપિત સંલગ્નતાઓને તેમની પીઅર ઓળખ સાથે સૂચિબદ્ધ કરે છે, અને ipsec statusall જૂનાં strongSwan તથા libreswan હોસ્ટને આવરી લે છે. તેની નીચે ip xfrm state કર્નલની વાસ્તવિક સંલગ્નતાઓ બતાવે છે, જ્યારે ss -lunp | grep 1701 સાબિત કરે છે કે xl2tpd ક્યાં બંધાયેલું છે. નિયંત્રણ જોડાણો અને કૉલ આવતા જોવા xl2tpd -D અગ્રભાગમાં ચલાવો, અને રજૂ કરાયેલી પદ્ધતિ તથા જવાબ જોવા માટે /etc/ppp/options.xl2tpd ફાઇલમાં pppd ડિબગ ચાલુ કરો.
લોગ સફળ પ્રમાણીકરણ બતાવે પછી, આગળનો પ્રશ્ન એ છે કે IPCP પૂર્ણ થયું કે નહીં. તપાસો કે /etc/xl2tpd/xl2tpd.conf ફાઇલની [lns default] વિભાગમાં ip range માં હજી મુક્ત સરનામાં છે અને ક્લાયન્ટ અપેક્ષા રાખે તો /etc/ppp/options.xl2tpd ખરેખર ms-dns અને ms-wins ધરાવે છે. ખાલી થયેલું પૂલ અને ખૂટતો DNS વિકલ્પ તાર પર જુદા દેખાય છે: પહેલું ક્લાયન્ટને સરનામા વગર અને 720 સાથે છોડે છે, બીજું સરનામું આપે છે પણ રિઝોલ્વર નહીં, તેથી નામ નિષ્ફળ જાય છે જ્યારે કાચા સરનામા પર ping કામ કરે છે. બંનેમાંથી કોઈ પાસવર્ડ ફરી દાખલ કરવાથી સુધરતું નથી.
ક્લાયન્ટ પર NetworkManagerનું L2TP પ્લગઇન pppdની વાતચીત જર્નલમાં લખે છે, તેથી journalctl -u NetworkManager -b સામાન્ય રીતે ટનલ ઉપર, પ્રમાણીકરણ નકાર્યુંને બિલકુલ ટનલ નથીથી અલગ કરે છે. Windows પર Get-VpnConnection પ્રોફાઇલની વાસ્તવિક પ્રમાણીકરણ સેટિંગ્સ જણાવે છે, અને Event Viewerમાં Application હેઠળના RasClient ઇવેન્ટ નિષ્ફળ ઘટકનું નામ આપે છે. સંવાદ ખૂબ અસ્પષ્ટ હોય ત્યારે netsh ras set tracing * enable સક્ષમ કરો.
કેપ્ચરને એક સાવધાની જોઈએ. ટ્રાન્સપોર્ટ-મોડ IPsec સાથે આંતરિક UDP 1701 એન્ક્રિપ્ટ થયેલું હોય છે, તેથી બહારના ઇન્ટરફેસ પરનું કેપ્ચર ESP બતાવે છે, અથવા NAT-T હેઠળ UDP 4500, અને L2TP બિલકુલ નહીં. કેપ્ચરમાં 1701 ન હોવું અપેક્ષિત છે અને અવરોધિત પોર્ટનો પુરાવો નથી; ESP કે 4500 કાઉન્ટર ખસે છે કે નહીં તે જુઓ.
NAT, MTU અને રૂટ: જ્યાં સ્ટેક તમને ભ્રમિત કરે છે
કંઈ પ્રમાણીકૃત થાય તે પહેલાં NAT ધારણાઓ તોડે છે. ESP પોતાનું IP પ્રોટોકોલ છે, તેથી ભાષાંતર કરતું ઉપકરણ તેને ફેંકી દે છે સિવાય કે પીઅર એન્કેપ્સ્યુલેટ કરે; UDP 4500 એ જ પ્રદાન કરે છે. જે Windows સર્વર પોતે ઘરેલું રાઉટર કે ક્લાઉડ NAT ગેટવે પાછળ હોય, ત્યાં IPsec તબક્કો ભૂલ 789 સાથે નિષ્ફળ જાય છે જ્યાં સુધી PolicyAgent કી હેઠળ AssumeUDPEncapsulationContextOnSendRule 2 પર સેટ ન થાય અને મશીન રીસ્ટાર્ટ ન થાય, અને નિષ્ફળતા બંધ પોર્ટથી અલગ પડતી નથી. NAT પાછળના ક્લાયન્ટ સરળ છે: સર્વર પર જાહેર સરનામું હોય તો UDP 4500 પરનું NAT-T તેમને વહન કરે છે અને એ મૂલ્ય સંડોવાયેલું નથી.
PPP ઉપર આવે પછી, કાળા છિદ્રવાળું MTU મૃત ટનલની નકલ કરે છે: નાના પેકેટ પસાર થાય, TLS હેન્ડશેક કે પૃષ્ઠ લોડ અટકી જાય, અને ક્લાયન્ટ હજી કનેક્ટેડ બતાવી શકે. સર્વરને દોષ આપતાં પહેલાં ઇન્ટરફેસ MTU ઘટાડો અથવા ગેટવે પર MSS ક્લેમ્પ કરો. સ્પ્લિટ-ટનલ રાઉટિંગ બીજો છેતરપિંડીકર્તા છે; ખોટા માસ્ક સાથે મોકલાયેલું સબનેટ ટનલને સ્વસ્થ અને એક એપ્લિકેશનને અગમ્ય રાખે છે. ખાનગી હોસ્ટનામ પોતાનું પગલું ઉમેરે છે: જો ક્વેરી સ્થાનિક રિઝોલ્વર થઈને નીકળે, તો કોઈ પણ રૂટ ચકાસાય તે પહેલાં નામ ઉકેલાવામાં નિષ્ફળ જાય છે.
ઓળખપત્રોને સ્પર્શ કરતાં પહેલાંની ચેકલિસ્ટ
યાદી ક્રમમાં કરો અને પહેલા નિષ્ફળ મદદ પર થોભો. દરેક પગલું સસ્તું છે, અને દરેક સંપાદનોનો આખો વર્ગ બાકાત કરે છે.
- બંને છેડે સંલગ્નતા છે તેની પુષ્ટિ કરો, કનેક્ટેડ લેબલને બદલે પીઅર ઓળખ દ્વારા મેળવેલી.
- UDP 1701 xl2tpd સુધી પહોંચે તેની પુષ્ટિ કરો; કૉલ વગરની સંલગ્નતા તમારી નિષ્ફળતા છે.
- પાસવર્ડ ખોટો છે તેમ ધારવા પહેલાં PPPનો નિર્ણય, અને પ્રમાણીકૃત થયું હોય તો IPCPનું પરિણામ વાંચો.
- હવે જ ઓળખપત્રો સર્વર જે ફોર્મેટમાં અપેક્ષા રાખે તેમાં ફરી દાખલ કરો, કારણ કે ડોમેન પૂર્વગ્રહ ખાતું બદલે છે.
- હજી નિષ્ફળ જાય તો બંને છેડા સંરેખિત ટાઇમસ્ટેમ્પ સાથે કેપ્ચર કરો અને તબક્કાવાર સરખાવો.
બીજા પગલે થોભવું એટલે પથ કે એન્કેપ્સ્યુલેશન સમસ્યા, અને પાસવર્ડનું કોઈ સંપાદન તેને ખસેડશે નહીં. ત્રીજા પગલે થોભવું એટલે લોગ પહેલેથી જ સુધારવાની પદ્ધતિ કે સરનામા-પૂલનું નામ આપે છે. બંને સ્થિતિમાં આગળનો ફેરફાર એવો છે જેને તમે વાજબી ઠેરવી શકો, અને તમે એવી સેટિંગ્સમાં ફરવાનું બંધ કરો છો જે ક્યારેય સંડોવાયેલી નહોતી.