IPsec ટ્રાફિક સિલેક્ટર્સ: તેઓ શું આવરે છે અને શું નહીં

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

તેમને બંને છેડેથી વાંચો

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

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

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

સાંકડું કરવું એ રિસ્પોન્ડરનો નિર્ણય છે

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

તેથી ક્લાયન્ટમાં ઉમેરાયેલું સબનેટ કાર્યરત ટનલ બનાવી શકે છે જે હજી પણ નવા ગંતવ્યને નકારે છે. સર્વરે પ્રસ્તાવને પોતાની નીતિ પરવાનગી આપે ત્યાં સુધી સાંકડો કર્યો, જ્યારે ક્લાયન્ટની ફાઇલ હજી પણ વિશાળ શ્રેણીની યાદી આપે છે. ફક્ત વાટાઘાટ કરેલી સ્થિતિ જ સત્ય બતાવે છે: Linux પર, ip xfrm policy અને strongSwan ના IKEv2 દસ્તાવેજીકરણમાં child SA યાદી જે સ્થાપિત થયું તેની જાણ કરે છે, માંગવામાં આવ્યું તેની નહીં. જ્યારે બંને અસહમત થાય, ત્યારે રિસ્પોન્ડરની નીતિ જ બદલવાની હોય છે.

નકારાયેલો પ્રસ્તાવ સાંકડા કરાયેલા કરતાં અલગ લક્ષણ છે. નકાર વાટાઘાટ લોગમાં દેખાય છે અને કોઈ પણ child સંલગ્નતા છોડતું નથી.

એક ગંતવ્યને શરૂઆતથી અંત સુધી અનુસરો

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

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

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

જો એપ્લિકેશન હજી નિષ્ફળ થતી હોય જ્યારે child કાઉન્ટર ખસે, તો સમસ્યા ટનલની પાર છે. તે તપાસને સિલેક્ટર્સ તરફ નહીં, દૂરના હોસ્ટના શ્રોતા કે ફાયરવોલ તરફ ખસેડે છે.

બે ધ્યેયોને અલગ રાખો

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

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