આવતું IPsec પીઅર કોઈ પ્રોફાઇલ સાથે મેળ ખાતું નથી? ચાર ક્ષેત્રો તપાસો

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

ફાઇલથી નહીં, પેકેટથી શરૂ કરો

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

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

પ્રથમ ક્ષેત્ર-જૂથ: ખરેખર લોડ થયેલી વ્યાખ્યા

ચાલતી સ્થિતિ ડેમન ધરાવતા સાધનથી તપાસો: લોડ થયેલા કનેક્શનની યાદી આપતો સ્થિતિ આદેશ, સંપાદક બફર નહીં. ખાતરી કરો કે અપેક્ષિત નોંધ હાજર છે, તમે ઇચ્છો તે પ્રારંભિક વર્તન માટે સક્ષમ છે, અને તમારા છેલ્લા સંપાદન પછી લોડ થઈ છે. સાચવેલી પણ ફરી લોડ ન કરેલી ફાઇલ એ “મેં ઠીક કર્યું અને કંઈ બદલાયું નહીં” નું સૌથી સામાન્ય કારણ છે.

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

બીજું ક્ષેત્ર-જૂથ: અંતિમ બિંદુઓ ઓળખ નથી

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

અંતિમ બિંદુઓની સરખામણીમાં NAT દૃશ્ય પણ હોઈ શકે: નેટવર્ક પર દેખાતું સરનામું પીઅર પોતાનું માને છે તે સરનામાથી અલગ હોઈ શકે છે. libreswan ના કનેક્શન મોડેલમાં left અને right બે સહભાગીઓના લેબલ છે, સ્થિર સ્થાનિક-દૂરસ્થ ક્રમ નહીં, તેથી બીજી સાઇટની કાર્યકારી ગોઠવણી નકલ કરીને સરનામાં બદલવા એ વિશ્વસનીય અનુવાદ નથી.

બંને બાજુઓની અપેક્ષિત ઓળખ અને તેની ચકાસણી કરતું ઓળખપત્ર લખી રાખો. જો એ બે લીટીઓ ન મળે, તો સરનામાંની કોઈ પણ ગોઠવણ મેળ ઊભો નહીં કરે.

ત્રીજું ક્ષેત્ર-જૂથ: જે ટ્રાફિક સુરક્ષિત થાય છે

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

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

ચોથું ક્ષેત્ર-જૂથ: તમે એક અમલીકરણ વાંચી રહ્યા છો

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

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

સંકલિત સુધારા પછી પસંદ કરેલી પ્રોફાઇલ અને સંગઠનની પુષ્ટિ કરો, પછી ખરેખર મંજૂર સેવા અને તેના પ્રતિસાદ માર્ગનું પરીક્ષણ કરો. પ્રોફાઇલ મેળ વાટાઘાટ શક્ય બનાવે છે, અને વાટાઘાટ અંતિમ પ્રવેશ-તપાસ નથી.