કેવી રીતે NAT ટ્રાવર્સલ ESP ને UDP ની અંદર લપેટે છે

એક જ રાઉટર પાછળના બે ક્લાયન્ટ એક IPsec ગેટવે સાથે વાત કરે છે, અને એક વારંવાર જોડાણ ગુમાવે છે જ્યારે બીજું ચાલુ રહે છે. મૂળ ESP એ 50 નંબરનો IP પ્રોટોકોલ છે જેમાં પોર્ટ નથી, તેથી એક જ સરનામું ઘણા ક્લાયન્ટ વહેંચે ત્યારે અનુવાદક પાસે મેપિંગ માટે પકડવા જેવું કંઈ નથી. NAT ટ્રાવર્સલ 4500 પર ESP ને UDP ની અંદર લપેટીને એ ખાલી જગ્યા ભરે છે, અને એ હેડર પછીના મોટા ભાગના લક્ષણો સમજાવે છે. તે કયું ઉપકરણ બદલવું તે પણ બતાવે છે.

ડેટા પ્લેન 4500 પોર્ટ પર કેમ જાય છે

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

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

બે તબક્કા ક્રમમાં તપાસો

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

tcpdump -ni any 'udp port 500 or udp port 4500' વડે બંને પોર્ટ જુઓ, અને સત્ર ચાલુ હોય ત્યારે રાઉટર પરનું અનુવાદ કોષ્ટક વાંચો. એ કોષ્ટક ગેટવે ખરેખર જે સ્રોત પોર્ટ જોશે તે બતાવે છે, અને લેપટોપ પરનું કેપ્ચર રચનાથી જ અલગ પડે છે: લેપટોપ 500 માને છે જ્યારે ગેટવે અનુવાદિત સ્રોત પોર્ટ સાથે 4500 જુએ છે, અને બંને સાચા છે. એ જ પ્રવાહ, અનુવાદ પહેલાં અને પછી:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

લપેટો જે લક્ષણો સમજાવે છે, અને જે બે સમજાવતો નથી

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

એકસાથે બે ક્લાયન્ટ માટે મેપિંગ કોષ્ટક વાંચો: જો બંને એક જ અનુવાદિત પોર્ટ બતાવે, તો ઉપકરણ ગેટવેની જરૂરિયાત મુજબ તેમને અલગ કરતું નથી. જે પાસથ્રુ મોડ ફક્ત એક હોસ્ટને મૂળ ESP આપે છે તે ઘણા અનુવાદિત ક્લાયન્ટને સેવા આપવા સમાન નથી, છતાં વેચાણકર્તા બંનેને IPsec-મૈત્રીપૂર્ણ કહે છે. બમણું NAT મેપિંગ સ્તર અને બીજું સમાપ્તિ બિંદુ ઉમેરે છે, પણ બહાર જતા જોડાણોને આપમેળે તોડતું નથી.

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

મેપિંગનો માલિક બદલો, પછી ફરી પરીક્ષણ કરો

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

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