ike-scan કાર્યરત IPsec ગેટવે તરફથી કોઈ જવાબ મેળવતું નથી

ગેટવે દરરોજ ફોન અને લેપટોપને સેવા આપે છે, તો પણ ike-scan જણાવે છે કે કોઈ હોસ્ટે જવાબ આપ્યો નથી. આ આઉટપુટ એવા પુરાવા જેવું લાગે છે કે ઉપકરણમાં IPsec નથી. સામાન્ય રીતે એનો અર્થ એ છે કે ઉપકરણે પ્રોબમાંના દરેક પ્રસ્તાવને ફગાવી દીધો અને કંઈ જ જવાબ ન આપવાનું પસંદ કર્યું. મૌન પણ એક જવાબ છે, અને તે સાધન તમને આપી શકે એવો સૌથી ઓછી માહિતી ધરાવતો જવાબ છે.

ત્રણ અલગ પ્રશ્નો પર કામ કરો: પેકેટ પહોંચ્યું, કોઈ પ્રસ્તાવ મેળ ખાધો, અને બીજું કંઈકે પીઅરને નકાર્યો?

પગલું 1: સાધન જે પ્રસ્તાવ મોકલે છે તે વાંચો

મુખ્ય મોડ SA પેલોડથી શરૂ થાય છે જે ઇનિશિએટર સ્વીકારશે તેવા ટ્રાન્સફોર્મની સૂચિ આપે છે, અને ike-scan એ સૂચિને કમ્પાઇલ કરેલા ડિફૉલ્ટમાંથી ભરે છે. ડિફૉલ્ટ સેટ ઇરાદાપૂર્વક જૂનો છે: એન્ક્રિપ્શન માટે DES અને 3DES, હેશિંગ માટે MD5 અને SHA1, કી એક્સચેન્જ માટે જૂથ 1 અને 2, પ્રમાણીકરણ માટે પૂર્વ-વહેંચાયેલ કી. AES નથી, SHA-2 નથી, જૂથ 14 નથી. AES-256 સાથે SHA-256 અને modp2048 માટે ગોઠવાયેલો ગેટવે તેની સાથે કંઈ પણ વહેંચતો નથી.

કેટલાક અમલીકરણો અસંગત પ્રોબનો જવાબ NO-PROPOSAL-CHOSEN સૂચનાથી આપે છે. અન્ય લોકો તેને ફક્ત કાઢી નાખે છે, જે અજાણ્યા પીઅરને ઘોંઘાટ ગણતા ઉપકરણોમાં સામાન્ય છે. કોઈ પણ રીતે સ્કેન કંઈ છાપતું નથી, અને એ કંઈ નથી બહારથી ફિલ્ટર કરેલા UDP 500 જેવું દેખાય છે તેની સાથે બરાબર સમાન છે, જેમ ike-scan પ્રોજેક્ટનું દસ્તાવેજીકરણ ડિફૉલ્ટ સેટ વિશે સ્પષ્ટ કરે છે.

પગલું 2: એક આધુનિક પ્રસ્તાવ આપો

ડિફૉલ્ટ સેટને --trans સાથે બદલો. એટ્રિબ્યુટ ફોર્મ IKE એટ્રિબ્યુટ નંબર સીધા લે છે: એન્ક્રિપ્શન માટે 1, હેશ માટે 2, પ્રમાણીકરણ માટે 3, જૂથ માટે 4, અને જ્યારે અલ્ગોરિધમ લંબાઈ લે ત્યારે કી લંબાઈ માટે 14. જે બહાર આવે છે તે એક લીટી છે જે તમે ફેરફાર સમીક્ષામાં મોટેથી વાંચી શકો છો.

સ્થિતિ ફોર્મ એ જ મૂલ્યો ક્રમમાં લે છે અને કૌંસ ટાળે છે, જે કમાન્ડ શેલમાંથી પસાર થાય ત્યારે મહત્ત્વનું છે.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

ગણતરી કરતી વખતે પેકેટ દીઠ એક પ્રસ્તાવ ધીમો છે, તેથી સંભવિત મૂલ્યો પર લૂપ કરો: એન્ક્રિપ્શન 5, 7/128, 7/192, 7/256; હેશ 1, 2, 5, 6, 7; જૂથ 1, 2, 5, 14, 15, 19, 20, 21; પૂર્વ-વહેંચાયેલ કી માટે પ્રમાણીકરણ 1 અને RSA સહીઓ માટે 3. ચલાવતા પહેલા દરેક કમાન્ડ છાપો જેથી ટ્રાન્સક્રિપ્ટ બતાવે કે શું અને કયા ક્રમમાં પ્રસ્તાવ મૂકવામાં આવ્યો.

પગલું 3: જવાબનું અર્થઘટન કરો

જવાબ બરાબર બે વસ્તુઓ સાબિત કરે છે: તે સરનામા પર IKE પ્રત્યુત્તર આપનાર પહોંચી શકાય તેવો છે, અને પ્રસ્તાવિત એક પ્રસ્તાવ સ્વીકાર્ય હતો. તે પૂર્વ-વહેંચાયેલી કી, L2TP સ્તર અથવા વપરાશકર્તા ખાતું અસ્તિત્વમાં છે કે નહીં તે વિશે કંઈ કહેતું નથી. સફળ સ્કેન દરેક પછીના તબક્કાની નિષ્ફળતા સાથે સંપૂર્ણપણે સુસંગત છે.

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

પગલું 4: મૌનનું અર્થઘટન કરો

મૌન દેખાય છે તેના કરતાં નબળો પુરાવો છે. દરેક પ્રસ્તાવ નકારવામાં આવ્યો હોઈ શકે, UDP 500 અને 4500 ફિલ્ટર થયા હોઈ શકે, સ્રોત ફટાકા પછી દર-મર્યાદિત હોઈ શકે, અથવા સેવા તમે સ્કેન કરેલા સરનામા કરતાં અલગ સરનામા પર સાંભળતી હોઈ શકે. બોક્સ વિશે કંઈ પણ નિષ્કર્ષ કાઢતા પહેલા ગેટવેના IKE લોગની સરખામણી એવા ક્લાઇન્ટ સાથે કરો જે પહેલેથી માન્ય ઓળખપત્રો સાથે જોડાય છે.

ફટાકા વર્તન તે સૂચિમાં આવે છે કારણ કે ગણતરી ટૂંકી વિન્ડોમાં ઘણા પેકેટ બનાવે છે. પ્રથમ પ્રયાસોનો જવાબ આપીને પછી શાંત થઈ જતો ગેટવે તેના પ્રસ્તાવ સેટને બદલે તેની anti-DoS નીતિનું વર્ણન કરે છે.

પગલું 5: તમે શું સાબિત કર્યું તે નોંધો

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

જે પ્રોબે ક્યારેય જવાબ આપ્યો નથી તેણે પણ કંઈક જવાબ આપ્યો છે: તે બતાવે છે કે આ ઉપકરણ કયા પ્રસ્તાવ પર ચર્ચા કરવા તૈયાર છે, અને કયા તેને જમીન પર પડવા દેવા વધુ ગમે છે.