strongSwan trap મોડ: IPsec ટનલ ટ્રાફિક માટે કેમ રાહ જુએ છે

સ્ટેટસ આઉટપુટમાં કોઈ CHILD SA દેખાતું નથી, ટનલ મૃત લાગે છે, અને પછી દૂરના સબનેટ પરનું ping તેને ઉપર લાવે છે. ઑન-ડિમાન્ડ IPsec સેટઅપમાં આ ક્રમ એ ડિઝાઇન છે, ખામી નથી. trap નીતિ સિલેક્ટર ઇન્સ્ટોલ કરે છે અને રાહ જુએ છે, અને તેની સાથે મેળ ખાતું પ્રથમ પેકેટ જ IKE અને CHILD SA વાટાઘાટ શરૂ કરે છે.

ગૂંચવણનો એક ભાગ શબ્દભંડોળ છે: “up” બે જુદી સ્થિતિઓ માટે વપરાય છે. રૂપરેખાંકન લોડ થયું છે અને કર્નલ નીતિ અસ્તિત્વમાં છે, પણ ડેટા સંગઠન નથી. ફક્ત સક્રિય SA ગણતું મોનિટર સ્વસ્થ સાઇટને ડાઉન તરીકે જણાવશે જ્યાં સુધી કોઈ ત્યાં ટ્રાફિક મોકલતું નથી.

નિષ્ક્રિય ઑન-ડિમાન્ડ ટનલ પાસે બતાવવા માટે કોઈ CHILD SA નથી

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

આ ક્રમ જ લોગને વાંચવા યોગ્ય બનાવે છે. પહેલા acquisition આવે છે, પછી IKE_SA_INIT અને IKE_AUTH, પછી CHILD SA. જો લોગ acquisition પછી તરત જ પૂરો થાય, તો ટ્રિગર કામ કરી ગયું. વાટાઘાટ નિષ્ફળ ગઈ, અને આગળનો પ્રશ્ન ઓળખપત્રો, પ્રસ્તાવો કે પહોંચ વિશે છે, trap વિશે નહીં.

Linux કર્નલ બેકએન્ડ સાથે તમે કોઈપણ SA અસ્તિત્વમાં આવે તે પહેલાં નીતિ જોઈ શકો છો. ચલાવો ip xfrm policy અને out દિશા અને જોડાણ તરફ ઇશારો કરતા ટેમ્પલેટવાળું સિલેક્ટર શોધો. તે એન્ટ્રી જ ઑન-ડિમાન્ડ સ્થિતિ છે, અને તેની હાજરી પ્રથમ પુષ્ટિ કરવાની વસ્તુ છે.

start_action નક્કી કરે છે કે કંઈપણ રાહ જોશે કે નહીં

દરેક child swanctl.conf માં start_action. start રૂપરેખાંકન લોડ થાય ત્યારે શરૂ કરે છે, trap નીતિ ઇન્સ્ટોલ કરે છે અને રાહ જુએ છે, અને none શરૂઆત બીજા કોઈને સોંપે છે. ફક્ત trap ઉપર વર્ણવેલું “ping અને ઉપર આવે” વર્તન ઉત્પન્ન કરે છે.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

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

અહીં swanctl.conf સંદર્ભ સ્વીકૃત મૂલ્યોની યાદી આપે છે, સાથે અલગ close અને DPD ક્રિયાઓ જે SA અસ્તિત્વમાં આવ્યા પછી શું થાય તે નિયંત્રિત કરે છે.

ટ્રિગર બિલકુલ ચાલ્યું કે નહીં તે શોધો

શરૂ કરો swanctl --list-conns થી અને ખાતરી કરો કે child તમે ઇચ્છેલી ક્રિયા સાથે લોડ થયું છે. પછી local_ts ની અંદરના હોસ્ટથી remote_ts ની અંદરના સરનામે એક પેકેટ મોકલો અને swanctl --list-sas જુઓ. જો આઉટપુટ બદલાય નહીં, તો કોઈ acquisition ડિમન સુધી પહોંચ્યું નથી.

શાંત trap માટે બે સામાન્ય કારણ: પેકેટ નીતિ સુધી પહોંચે તે પહેલાં source-NAT થઈ ગયું અને હવે local_ts સાથે મેળ ખાતું નથી, અથવા સિન્ટેક્સ કે ઓળખપત્રની ભૂલને કારણે જોડાણ ક્યારેય લોડ થયું નથી. ફરી ચલાવો swanctl --load-all અને સિલેક્ટરને સ્પર્શતા પહેલાં તેનું આઉટપુટ વાંચો. જે જોડાણ લોડ ન થયું તે કોઈ નીતિ ઇન્સ્ટોલ કરતું નથી, તેથી ટ્રાફિક પાસે ચાલુ કરવા જેવું કંઈ નથી.

દિશા પણ મહત્વની છે: બહાર જતા ટ્રાફિક માટે ઇન્સ્ટોલ કરેલું trap અંદર આવતા પેકેટ પર શરૂ થતું નથી. જો દૂરની બાજુએ ટનલ ઉપર લાવવાની હોય, તો તેને પોતાનું trap જોઈએ, અથવા આ બાજુને start.

પ્રથમ પેકેટની રાહ જોવી હંમેશા યોગ્ય સોદો નથી

ઇન્ટરેક્ટિવ સત્રો સેટઅપ ખર્ચ અનુભવે છે. પ્રથમ વિનંતી IKE વિનિમય અને CHILD વાટાઘાટની કિંમત ચૂકવે છે, અને ટૂંકી સમયમર્યાદાવાળો ક્લાયન્ટ SA અસ્તિત્વમાં આવે તે પહેલાં હાર માની શકે છે. સક્રિય start તે પ્રથમ-પેકેટ વિલંબ દૂર કરે છે. પરંતુ તે એવા ટ્રાફિક માટે ટનલ ખુલ્લી રાખે છે જે કદાચ ક્યારેય ન આવે.

ત્રણ તથ્યો નિર્ણય લે છે: માર્ગ કેટલી વાર વપરાય છે, પ્રથમ વિનંતીની સમયમર્યાદા કેટલી ચુસ્ત છે, અને બૂટ વખતે પીઅર પહોંચી શકાય છે કે નહીં. પ્રસંગોપાત્ત બેચ ટ્રાફિક અને બૂટ વખતે ઑફલાઇન હોઈ શકે તેવો પીઅર બંને trap તરફેણમાં છે. વિલંબ-સંવેદનશીલ ક્લાયન્ટ અને હંમેશા પહોંચી શકાય તેવો પીઅર start તરફેણમાં છે. જો બંને બાજુઓ શરૂ કરી શકે, તો નક્કી કરો કે ટ્રિગર કોનો છે જેથી બમણી વાટાઘાટો ન થાય.

ઇન્સ્ટોલ કરેલી નીતિ પણ લીક-પ્રૂફ બાંયધરી નથી. જો જરૂરિયાત fail-closed હોય, તો ફાયરવોલે SA વગરનો ટ્રાફિક કાઢી નાખવો પડે, અને તે નિયમ child વ્યાખ્યાની બહાર રહે છે.

આગળની દલીલ પૂરી કરતી ત્રણ લીટીઓ લખો

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

એવા હોસ્ટથી પરીક્ષણ કરો જે ખરેખર સિલેક્ટરની અંદર છે. રાઉટરમાંથી જ કરેલું ping ઘણી વાર અલગ માર્ગ લે છે અને તેની પાછળના સબનેટની રક્ષા કરતી નીતિ વિશે કંઈ સાબિત કરતું નથી.