TCP પર IKE 4500: પોર્ટ નિયમ પહેલાં બંને છેડા તપાસો
TCP એન્કેપ્સ્યુલેશન બંને છેડા વાટાઘાટ કરે છે, ફાયરવોલ નિયમ આપતું નથી. લિસનર તપાસ, કેપ્ચર અને ચાર સ્વીકૃતિ તબક્કા ક્રમમાં ચલાવો.
સપોર્ટ ટિકિટ ઘણી વાર ત્યારે આવે છે જ્યારે ફાયરવોલ ફેરફાર પહેલેથી મંજૂર હોય અને ટનલ હજી ઉપર આવવાનું નકારે. જ્યારે ફક્ત એક છેડે આ સુવિધા હોય ત્યારે આ જ અપેક્ષિત પરિણામ છે: RFC 9329 મુજબનું TCP એન્કેપ્સ્યુલેશન બંને છેડે અમલમાં મૂકવું અને ગોઠવવું પડે છે, અને કોઈ પણ સુરક્ષિત ટ્રાફિક ખસે તે પહેલાં કનેક્શનની અંદર જ સંમતિ થાય છે. પોર્ટ ખોલવો એ એવા લિસનરની જાહેરાત છે જે કદાચ ન હોય, અને બીજી બાજુએ મેળ ખાતી ગોઠવણી વગરનો લિસનર કનેક્શન સ્વીકારીને પછી શાંત થઈ જાય છે. નીચેનો ક્રમ સસ્તી તપાસને પહેલાં મૂકે છે.
આ વિકલ્પ ખરેખર શું ઉમેરે છે તે જાણો
મૂળ IPsec એન્ક્રિપ્ટેડ પેલોડને આ રીતે વહન કરે છે: IP પ્રોટોકોલ 50, પરવાનગી આપવા માટે કોઈ પોર્ટ નંબર વગર. NAT ટ્રાવર્સલ તે પેકેટને UDP માં લપેટીને પોર્ટ 4500 પર મોકલે છે, અને તેથી જ આટલા બધા ફાયરવોલ નિયમો તે પોર્ટનો ઉલ્લેખ કરે છે. RFC 9329 સ્ટ્રીમ રજૂઆત ઉમેરે છે: IKE અને IPsec પેકેટ બંને એક જ TCP કનેક્શનની અંદર મુસાફરી કરે છે, સામાન્ય રીતે પોર્ટ 4500 પર.
આ સ્ટ્રીમ વેબ સેવા નથી. 4500 પરનું TCP કનેક્શન HTTP, TLS કે પ્રોક્સી-મૈત્રીપૂર્ણતા વિશે કંઈ કહેતું નથી, અને માર્ગમાંનું HTTP પ્રોક્સી સામાન્ય રીતે ફ્રેમિંગ તોડી નાખશે, વહન નહીં કરે.
ફાયરવોલને સ્પર્શ કરતા પહેલાં પૂર્વ-તપાસ
ધોરણ TCP ને UDP માર્ગ છોડી દેતા નેટવર્ક માટે બેકઅપ તરીકે મૂકે છે, તેના બદલી તરીકે નહીં. દરેક વેન્ડર પાસેથી બે હકીકત મેળવો: સુવિધાનું ચોક્કસ નામ અને એવી આવૃત્તિ જે માલિકી હકવાળા પ્રકારને બદલે RFC 9329 અમલમાં મૂકે. IPsec over TCP જેવા લેબલ અસંબંધિત ડિઝાઇન માટે વપરાયા છે, તેથી દસ્તાવેજ સંદર્ભ અને તેને ચાલુ કરતી ગોઠવણી કી માંગો. બંને જવાબ વગર વાયર સુસંગતતા વિશે કંઈ ધારશો નહીં.
તે એવી લેબમાં સાબિત કરો જ્યાં બંને છેડા તમારા હોય. TCP 4500 પર જવાબ આપે પણ IKE ક્યારેય પૂર્ણ ન કરે તેવું ગેટવે બીજી બાજુએ મેળ ખાતા એન્કેપ્સ્યુલેશન વગરના લિસનરની નિશાની છે, અને ત્યાં શોધવું ફેરફાર વિન્ડો દરમિયાન શોધવા કરતાં ઘણું સસ્તું છે.
રિસ્પોન્ડર પર: કંઈ સાંભળે છે
સોકેટથી શરૂ કરો. ss -ltnp | grep 4500 દર્શાવે છે કે TCP લિસનર છે કે નહીં અને કઈ પ્રક્રિયા તેની માલિક છે. લીટી ન હોવી તપાસને નેટવર્ક પર નહીં, ગેટવે ગોઠવણી પર પૂરી કરે છે.
જો સોકેટ હાજર હોય, તો ક્લાયન્ટ બાજુથી અનુમાન કરવાને બદલે હેન્ડશેક જુઓ: tcpdump -ni any 'tcp port 4500'. પૂર્ણ થયેલા ત્રણ-માર્ગી હેન્ડશેક પછી મૌનનો અર્થ છે કે સ્ટ્રીમ સ્વીકારાઈ અને તેની અંદરનું IKE વિનિમય નિષ્ફળ ગયું, જ્યારે જવાબ વગરનું SYN ફિલ્ટરિંગ કે ખોટા સરનામા તરફ ઇશારો કરે છે.
બંને ભેગા ન થાય તે માટે એ જ કેપ્ચર વિન્ડોમાં UDP માર્ગ સાથે સરખામણી કરો: tcpdump -ni any 'udp port 4500 or proto 50'. TCP વપરાય છે એમ માનો છો ત્યારે પ્રોટોકોલ 50 કે UDP પોર્ટ 4500 પર ટ્રાફિક હોવો એટલે બંને છેડા બેકઅપ પર ક્યારેય સંમત ન થયા. જો શક્ય હોય તો ગેટવે પર પણ કેપ્ચર કરો, કારણ કે ક્લાયન્ટ-બાજુનું કેપ્ચર દૂરના છેડે શું મોકલ્યું તે બતાવી શકતું નથી.
ચાર અલગ તબક્કામાં સ્વીકારો
ઉપર આવવાને ચાર પરિણામ તરીકે ગણો. દરેક અલગ કારણે નિષ્ફળ જઈ શકે, અને એક જ પાસ કે ફેલ કયું હતું તે છુપાવે છે, તેથી જે પહેલો તબક્કો નિષ્ફળ જાય ત્યાં થોભો અને ફરીથી ઉપરથી શરૂ કરો.
| Stage | What you check | What it proves |
|---|---|---|
| 1 | TCP connection established to 4500 | A listener exists and the path permits it |
| 2 | IKE_SA authenticated in the gateway log | Both peers agreed on the encapsulation |
| 3 | CHILD_SA installed, visible with ip xfrm state | Keys exist for the protected traffic |
| 4 | A new application exchange succeeds | The data path works, not just the control path |
ચોથો તબક્કો એ છે જે છોડી દેવાય છે. હાલનું સત્ર કેશ થયેલી સ્થિતિ પર કામ ચાલુ રાખી શકે છે, તેથી ફેરફાર બંધ કરતા પહેલાં ગેટવે પાછળના યજમાન સાથે નવું કનેક્શન ખોલો. જો બીજો તબક્કો નિષ્ફળ જાય અને પહેલો પાસ થાય, તો મતભેદ પ્રસ્તાવ કે એન્કેપ્સ્યુલેશન સેટિંગમાં છે, ફાયરવોલમાં નહીં.
રોલબેક, અને તેને ચાલુ રાખવાની કિંમત
ફેરફાર પહેલાં પૂર્વવત્ કરવાની યોજના કરો: બંને છેડે એન્કેપ્સ્યુલેશન વિકલ્પ બંધ કરો અને ખાતરી કરો કે ટનલ UDP પર પાછી આવે છે. જો ફરી બેકઅપની જરૂર પડે તો એક સમીક્ષા ચક્ર માટે TCP નિયમ રાખો, પછી તેને દૂર કરો. 4500 પરનું ન વપરાયેલું લિસનર કોઈ પણ કાર્યકારી મૂલ્ય વગરનું સપાટી ક્ષેત્ર છે.
જ્યારે તે વાસ્તવિક કામ વહન કરે ત્યારે પ્રદર્શનની નિશાની જુઓ. TCP ની અંદર TCP એક જ નુકસાન પર અટકી જતા સ્વીકૃતિ સ્તર ઉમેરે છે, અને એક કનેક્શન વહેંચતા સ્ટ્રીમ એકબીજાને અવરોધી શકે છે, તેથી ping ને બદલે ટનલ વાપરનાર એપ્લિકેશન માપો.
સ્વીકૃતિ યાદી
બંને છેડે સુવિધાનું નામ અને આવૃત્તિ, રિસ્પોન્ડર પરનું લિસનર, પૂર્ણ હેન્ડશેક દર્શાવતું કેપ્ચર, અને સમય-છાપ સાથે નોંધાયેલા ચાર તબક્કા પુષ્ટિ કરો. આગલા ઇજનેરને TCP કેમ છે તે જાણવા માટે ફેરફાર રેકોર્ડમાં બેકઅપનું કારણ ઉમેરો. જરૂર પડે તે પહેલાં રોલબેકની તાલીમ લો.
જો કોઈ તબક્કો નિષ્ફળ જાય, તો ફક્ત એ જ તબક્કો સુધારો. ટ્રાન્સપોર્ટ સમસ્યા પાછળ દોડવા સાઇફર સ્યુટ કે ઓળખ સેટિંગ બદલવાથી સામાન્ય રીતે પહેલા ઉપર બીજી, અસંબંધિત નિષ્ફળતા ઉમેરાય છે.