ટનલ ઇન્ટરફેસ પર લેવાયેલા કેપ્ચર ક્યારેય શાખાનું VLAN ID દર્શાવશે નહીં, અને આ ટૂલની ખામી નહીં પણ ડિઝાઇનની લાક્ષણિકતા છે. રૂટેડ TUN ટનલ IP પેકેટ વહન કરે છે, તેથી જે ટેગ કરેલી Ethernet ફ્રેમ તેમને શાખાની લિંક પર લઈ જતી હતી તે જ રાઉટર પર સમાપ્ત થાય છે જેણે તેમને રૂટ કર્યા હતા. જો તમારી નીતિનો પ્રશ્ન સેગમેન્ટ વિશે હોય, તો કેપ્ચર શરૂ થાય તે પહેલાં તે પ્રશ્ન માટે સેન્સરની સ્થિતિ પસંદ કરવી પડશે. તમે અપેક્ષા રાખેલું VLAN ક્ષેત્ર એવા સંદર્ભથી બદલવું પડશે જેનો તમે બચાવ કરી શકો.

ટનલ ઇન્ટરફેસ ખરેખર શું વહન કરે છે તે જુઓ

TUN હોસ્ટને IP પેકેટ પહોંચાડે છે; TAP Ethernet ફ્રેમ પહોંચાડે છે. રૂટેડ ડિઝાઇન પહેલું વાપરે છે, એટલે કે ડિક્રિપ્શન પછી આવતા પેકેટમાં કોઈ લિંક-લેયર હેડર જ હોતું નથી, અને તેથી વાંચવા માટે કોઈ 802.1Q ટેગ હોતું નથી. માર્ગમાં કંઈ દૂર કરવામાં આવ્યું નથી, કારણ કે ટેગ ક્યારેય ટનલમાં દાખલ થયું જ નહીં. અંદરનું પેકેટ તેના IP હેડરથી શરૂ થાય છે, તેથી VLAN-જાગરૂક નિયમ જે દરેક ક્ષેત્રની અપેક્ષા રાખે છે તે ફક્ત ગેરહાજર છે.

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

ip -d link show tun0
tcpdump -i tun0 -nn -e -c 20

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

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

ત્રણમાંથી એક જગ્યાએ ઊભા રહો અને તે શું જોઈ શકે તે સ્વીકારો

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

તે ત્રણ સ્થિતિઓ ત્રણ અલગ પ્રશ્નોના જવાબ આપે છે, અને એક કેપ્ચર એક સાથે ત્રણેય હોઈ શકતું નથી.

tcpdump -i eth0 -nn -e 'vlan' -c 10
tcpdump -i tun0 -nn -c 10

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

ગુમ થયેલા ટેગને એવા મેપિંગથી બદલો જેનો તમે બચાવ કરી શકો

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

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

ip route get 10.20.30.40
ip -br addr show

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

પરિણામ પર ભરોસો રાખતા પહેલાં પરત માર્ગ અને પેલોડ તપાસો

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

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

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

સંબંધિત લેખો