L2TP NO_PROPOSAL_CHOSEN: ખરેખર કયો તબક્કો નિષ્ફળ ગયો?
સૂચના કહે છે કે એક પ્રસ્તાવ નકારવામાં આવ્યો, પરંતુ કયો તે નહીં. તબક્કા માટે બેકએન્ડનો લોગ વાંચો, પછી ગેટવે ચલાવનાર સાથે સેટની સરખામણી કરો.
NO_PROPOSAL_CHOSEN કોઈપણ PPP વપરાશકર્તાનામની તપાસ થાય તે પહેલાં આવે છે, જે ઉપયોગી હકીકત છે અને તે જ કારણ છે કે સંદેશ ગેરમાર્ગે દોરે છે. તે જણાવે છે કે એક પક્ષે પ્રસ્તાવ નકાર્યો; તે જણાવતું નથી કે કયો પરિમાણ અસહમત હતો, અને IKE જોડાણ બનાવતી વખતે નકાર થયો કે પછી ટ્રાફિક સંરક્ષણની વાટાઘાટ દરમિયાન, તે વિશે પણ કંઈ કહેતું નથી. આ બે શક્યતાઓ પાછળ બે જુદા સુધારા છે, અને તેમાંથી ફક્ત એક જ PFS ચેકબોક્સ સાથે સંબંધિત છે જે તરફ લોકો પહેલાં જાય છે.
એક સંદેશ, પ્રસ્તાવોના બે સેટ
IKEv1 L2TP/IPsec ગોઠવણીમાં ક્રમિક રીતે બે વાટાઘાટો છે. તબક્કો 1 એન્ક્રિપ્શન અલ્ગોરિધમ, સંકલિતતા અલ્ગોરિધમ અને Diffie-Hellman જૂથમાંથી IKE સુરક્ષા જોડાણ બનાવે છે. પછી તબક્કો 2 ટ્રાફિક કેવી રીતે સુરક્ષિત થશે તેની વાટાઘાટ કરે છે, અને PFS ની આવશ્યકતા તે બીજી વાતચીતની છે.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
તબક્કા ક્રમિક હોવાથી, નિષ્ફળતાનું સ્થાન તમને કહે છે કે કઈ યાદીની સરખામણી કરવી. સંદેશનું આખું નિદાન મૂલ્ય આમાં જ છે, અને કોઈપણ સેટિંગને અડવા પહેલાં તેને બહાર કાઢવા યોગ્ય છે.
PFS ચેકબોક્સ તબક્કો 1 ને કેમ સુધારી શકતું નથી
PFS બંધ કરવાથી તબક્કો 2 ની એક ગુણધર્મ બદલાય છે. જો પક્ષો ક્યારેય તબક્કો 1 પર સહમત ન થયા હોય, તો ESP વાતચીત ક્યારેય થતી નથી, તેથી ચેકબોક્સની નકાર પર કોઈ અસર થતી નથી, અને તેથી જ તેને ટૉગલ કરવાથી અલગ સમયછાપ સાથે એ જ ભૂલ આવે છે.
ઊલટી ભૂલ પણ એટલી જ સામાન્ય છે. સફળ IKE જોડાણ સાબિત કરતું નથી કે ESP પ્રસ્તાવ સ્વીકાર્ય છે, અને તે ચોક્કસપણે સાબિત કરતું નથી કે તબક્કો 2 નું જૂથ મેળ ખાય છે. સ્થાપિત મેનેજમેન્ટ ટનલને ફક્ત તબક્કો 1 વિશેનો પુરાવો ગણો. લોકો લીલી લાઈનને «ટનલ ચાલુ છે» તરીકે વાંચે છે, પછી ખોટા તબક્કા પર કલાક ગુમાવે છે કારણ કે બીજી વાટાઘાટ શરૂ થઈ ન હતી તે કંઈએ તેમને કહ્યું ન હતું.
અલ્ગોરિધમ પસંદ કરતા પહેલાં લોગ વાંચો
નકારની તરત પહેલાંના સંદેશા તે બેકએન્ડ પાસેથી એકઠા કરો જે ખરેખર કનેક્શન સંભાળે છે, અને તેમને એ જ પ્રયાસ સાથે સહસંબંધિત કરો. તે સહસંબંધ વિના તમે બીજા કનેક્શનનો ઇતિહાસ વાંચી રહ્યા છો અને તેમાંથી તારણ કાઢી રહ્યા છો.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanતે લાઈનોમાંથી બે પ્રશ્નોના જવાબ આપો: તબક્કો 1 નું જોડાણ સ્થપાયું કે નહીં, અને કઈ આપલે નિષ્ફળ ગઈ. તે બે જવાબ શોધને એક લક્ષણ-યાદી સુધી સંકુચિત કરે છે. આસપાસના સંદર્ભ વિનાની નક્કર સૂચના તે કરી શકતી નથી, ભલે ફોરમની થ્રેડમાંથી પ્રસ્તાવ અજમાવવો કેટલો લલચાવનારો હોય. અલગ બેકએન્ડ ધરાવતી મશીનમાંથી કામ કરતી શબ્દમાળા નકલ કરવાથી સામાન્ય રીતે એક નકાર બીજા નકાર દ્વારા બદલાય છે, થોડી વાર પછી.
બેકએન્ડની વાક્યરચના પ્રવાસ કરતી નથી
કંઈપણ સરખાવતા પહેલાં NetworkManager-l2tp ની આવૃત્તિ અને IPsec બેકએન્ડની આવૃત્તિ નોંધો. Libreswan અને strongSwan પ્રસ્તાવ-વાક્યરચના કે સમાન અલ્ગોરિધમ-સેટ વહેંચતા નથી, તેથી એકમાં કામ કરતી શબ્દમાળા બીજામાં વાક્યરચનાની ભૂલ છે. સ્થાપિત બેકએન્ડ નીતિ અનુસાર IKEv1 ને પણ નકારી શકે છે, અને પછી કોઈ પ્રસ્તાવ ક્યારેય સ્વીકારાશે નહીં.
પ્રોજેક્ટનું README તે બેકએન્ડ તફાવતોનું દસ્તાવેજીકરણ કરે છે અને તબક્કો 1 તથા તબક્કો 2 ના ક્ષેત્રો અલગ રાખે છે. તેને રચનાના દસ્તાવેજ તરીકે વાંચો, દરેક ઐતિહાસિક સાઇફર અને નબળું જૂથ ચાલુ કરવાના આમંત્રણ તરીકે નહીં, કારણ કે ફક્ત એમ કરીને સફળ થતું કનેક્શન એ કનેક્શન નથી જે તમને બનાવવા કહેવાયું હતું.
સેટ પર સહમત થાઓ, પછી તબક્કાઓ ચકાસો
ગેટવે ઓપરેટરને પૂછો કે કયા IKE અને ESP સેટ સમર્થિત અને મંજૂર છે, પછી તે જવાબની સરખામણી ક્લાયન્ટના વાસ્તવિક પ્રસ્તાવો સાથે કરો, તેની રૂપરેખાંકન ફાઇલ સાથે નહીં. જો મતભેદ ખાસ કરીને તબક્કો 2 ના PFS વિશે હોય, તો સમર્થિત જૂથ અથવા સ્પષ્ટપણે મંજૂર કરાયેલી PFS-મુક્ત નીતિ પર નિર્ણય કરો. ભૂલના નામ પરથી નીતિ અનુમાન કરશો નહીં.
જ્યારે એકમાત્ર સામ્યતા એવી ક્રિપ્ટોગ્રાફી માગે છે જે સંસ્થા હવે સ્વીકારતી નથી, ત્યારે નિર્ણય ગેટવેનો કે પ્રોટોકોલ સ્થાનાંતરણનો છે. ક્લાયન્ટ શબ્દમાળાને ત્યાં સુધી પહોળી કરવી કે જ્યાં સુધી કંઈક વાટાઘાટ ન કરે, એ જાણીતી નબળાઈને બાજુમાં લીલી ટિક સાથે મોકલવાનો રસ્તો છે.
સાચી અસંગતિ સુધાર્યા પછી, L2TP અને PPPની તપાસ પહેલાં IPsec સ્થાપના પુષ્ટિ કરો, અને પછીના કોઈપણ પ્રમાણીકરણ નકારને આગલા તબક્કાનું ગણો. પછી મંજૂર પરીક્ષણ પ્રક્રિયામાં નવીકરણ ચકાસો, કારણ કે પ્રથમ જોડાણની સ્થાપના તેના બાકીના આયુષ્ય વિશે કંઈ કહેતી નથી.