tcpdump IPsec સાદો ટેક્સ્ટ ફક્ત એક જ દિશામાં કેમ બતાવે છે

તમે Linux IPsec ગેટવેના બહારના ઇન્ટરફેસ પર tcpdump ચલાવો છો અને એકસાથે બે વસ્તુઓ જુઓ છો: આવતા ESP ફ્રેમ્સ અને તરત જ તેમના પછી ડિક્રિપ્ટ થયેલા આંતરિક પેકેટ. જતી દિશામાં ફક્ત ESP દેખાય છે. સ્વાભાવિક નિષ્કર્ષ એ છે કે જવાબો મોકલાતા નથી અથવા IPsec એક દિશા એન્ક્રિપ્ટ કરે છે અને બીજી ભૂલી જાય છે. બંનેમાંથી કંઈ સાચું નથી.

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

કેપ્ચર પોઈન્ટ નક્કી કરે છે કે તમે શું જુઓ છો

સામાન્ય ઇન્ટરફેસ પર AF_PACKET સોકેટ ઉપકરણ સ્તરની નજીક બેસે છે. હોસ્ટ છોડતા પેકેટ પહેલાં IPsec આઉટપુટ પ્રોસેસિંગમાંથી પસાર થાય છે, જે આંતરિક TCP સેગમેન્ટને ESP અથવા UDP-4500 ડેટાગ્રામમાં ફેરવે છે, અને પછી જ તે સ્તરે પહોંચે છે. આવતા પેકેટ તારમાંથી આવતાં જ, હજી એન્ક્રિપ્ટેડ હાલતમાં, સોકેટમાં નકલ થાય છે, અને ડિક્રિપ્ટ થયેલું પરિણામ પછીથી દેખાય છે જ્યારે સ્ટેક તેને સ્થાનિક રીતે પહોંચાડે છે અથવા ફોરવર્ડ કરે છે.

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

તમે ધારેલા સ્તર સાથે ફિલ્ટર મેળવો

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

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

ફિલ્ટર તે જે પ્રશ્નનો જવાબ આપે છે તેની બાજુમાં લખો. «બોક્સમાંથી કેટલું ESP નીકળ્યું» અને «વેબ વિનંતી બોક્સમાંથી નીકળી» એ અલગ ફિલ્ટર સાથેનાં અલગ માપ છે, અને એક કેપ્ચર બંને નક્કી કરી શકતું નથી. એ નોંધ વગર બે વ્યક્તિઓ એવી સંખ્યાઓ સરખાવશે જે ક્યારેય એક જ વસ્તુ ગણતી ન હતી.

રૂપાંતર પહેલાં નિરીક્ષણ કરો, પછી નહીં

જો તમારે જતો સાદો ટેક્સ્ટ જોવો હોય, તો અવલોકન બિંદુને વહેલું, IPsec આઉટપુટ પ્રોસેસિંગ પહેલાં ખસેડો. NFLOG તમને Netfilter હૂક આપે છે જ્યાં નિયમ પસંદ કરેલા પેકેટને વપરાશકર્તા-અવકાશ સોકેટમાં નકલ કરી શકે છે, જે tcpdump વાંચી શકે છે. strongSwan ની ટ્રાફિક-ડમ્પ માર્ગદર્શિકા આ દૃષ્ટિકોણને એ જ કારણસર દસ્તાવેજ કરે છે.

નીતિ મેળ નિયમને ફક્ત એ ટ્રાફિક સુધી મર્યાદિત કરે છે જે ટનલમાં પ્રવેશવાના આરે છે. -m policy --pol ipsec --dir out જ નિયમને ચોક્કસ બનાવે છે, બોક્સ મોકલે તે દરેક પેકેટને લોગ કરવાને બદલે. પછી લોગ જૂથને મર્યાદિત કેપ્ચર સાથે વાંચો: નાની સ્નેપશોટ સંખ્યા અને કદ મર્યાદા નિદાનને ટ્રાફિક આર્કાઇવ બનતું અટકાવે છે. મર્યાદિત કેપ્ચર સમીક્ષકને સોંપવું પણ સરળ છે, અસંબંધિત પેલોડ ખેંચ્યા વગર. કેટલું આવ્યું તે જોયા પછી નહીં, શરૂ કરતાં પહેલાં સંખ્યા નક્કી કરો.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

પ્રવાહને અનુરૂપ હૂક પસંદ કરો. OUTPUT ગેટવે પોતે ઉત્પન્ન કરતા ટ્રાફિકને આવરે છે; LAN ક્લાયંટનું ટ્રાન્ઝિટ તેના બદલે FORWARD શૃંખલામાંથી પસાર થાય છે, અને OUTPUT પરનો નિયમ તેને ક્યારેય જોશે નહીં. ઉપરનું સરનામું અને પોર્ટ મંજૂર પરીક્ષણ ગંતવ્ય માટે પ્લેસહોલ્ડર છે.

અવલોકન શું સાબિત કરે છે

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

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

બીજી એક જાળ: આ સંદર્ભમાં «સાદો ટેક્સ્ટ» એટલે IPsec એન્ક્રિપ્શન સ્તરની બહાર. આંતરિક HTTPS સત્ર હજી પોતાનું TLS ધરાવે છે. ડિકેપ્સ્યુલેટેડ પેકેટ કેપ્ચર કરવાથી એપ્લિકેશનનું TLS ડિક્રિપ્ટ થતું નથી, અને ત્યાં વાંચી શકાય તેવું HTTP દેખાવાનો અર્થ એ છે કે એપ્લિકેશન શરૂઆતથી HTTPS વાપરતી ન હતી.

સાફ કરો અને બંને છેડા સરખાવો

અવલોકન પૂરું થતાં જ તમે દાખલ કરેલો બરાબર એ જ નિયમ, તેના માલિક પ્રમાણે, દૂર કરો. લોગિંગ નિયમ રહેવા દેવાથી દરેક મેળ ખાતા પેકેટ પર CPU ખર્ચ થાય છે અને ચૂપચાપ ડેટા જાળવણીની સમસ્યા ઊભી થાય છે. તમારી ન હોય તેવી શૃંખલા ફ્લશ કરવાને બદલે -D સાથે નિયમનું પુનરાવર્તન કરીને ભૂંસો.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

જો ડિપ્લોયમેન્ટ વપરાશકર્તા-અવકાશ IPsec, XFRM ઇન્ટરફેસ કે હાર્ડવેર ઓફલોડ વાપરે છે, તો અવલોકન બિંદુઓ ખસે છે અને આ રેસિપી બિલકુલ લાગુ ન પણ પડે. libipsec સાથે આંતરિક ટ્રાફિક જોવાનું દસ્તાવેજ કરેલું સ્થળ TUN ઉપકરણ છે. પહેલાં માર્ગ ઓળખો, પછી પ્રશ્નનો જવાબ આપતું બિંદુ પસંદ કરો, અને અપેક્ષા રાખો કે બંને દિશાઓ ફક્ત ત્યારે જ અલગ દેખાશે જ્યારે તમે રૂપાંતરની ખોટી બાજુ જોઈ રહ્યા હો.