strongSwan ESP-in-UDP: જ્યારે શોધવા માટે કોઈ NAT ન હોય

NAT શોધ એ સરનામાંનું ભાષાંતર શોધે છે, ફાયરવૉલ નીતિ નહીં. NAT વગરનું સાઇટ કનેક્શન તોપણ સ્પષ્ટ ESP-in-UDP પસંદગીની જરૂર પડી શકે છે.

NAT શોધ એક પ્રશ્નનો જવાબ આપે છે: શું રસ્તામાં સરનામાં કે પોર્ટ બદલાયા છે? એ એનો જવાબ આપતું નથી કે ફાયરવૉલ IP પ્રોટોકોલ 50 ને મંજૂરી આપે છે કે નહીં. કોઈ ભાષાંતર વગરના સાઇટ ગેટવે હજુ પણ એવી નીતિ પાછળ હોઈ શકે છે જે native ESP ને કાઢી નાખે છે, અને એ જરૂરિયાત શોધવાને બદલે ગોઠવવી પડે છે. પદ્ધતિ ESP-in-UDP છે, અને એ નિર્ણય છે, પોતાની મેળે આવતો વૈકલ્પિક રસ્તો નહીં.

શોધ એ સરનામાં પરનું અંકગણિત છે, ફાયરવૉલ પ્રોબ નહીં

IKEv2 NAT-શોધ પેલોડ વહન કરે છે જેમાં સ્રોત અને લક્ષ્ય સરનામાં તથા પોર્ટના હેશ હોય છે. દરેક પક્ષ પોતાને મળેલાને સ્થાનિક રીતે દેખાતા સાથે સરખાવે છે, અને અસંગતિ તેને કહે છે કે કંઈકે પેકેટનું ભાષાંતર કર્યું છે. એ વિનિમયમાં કંઈ પણ ચકાસતું નથી કે વચ્ચેનો રાઉટર પ્રોટોકોલ 50 આગળ મોકલે છે કે નહીં.

વ્યવહારુ પરિણામ સીધું કહેવા જેવું છે. native ESP સાથે કામ કરતી ટનેલ પોતાની મેળે નવો પ્રતિબંધક ફાયરવૉલ શોધશે નહીં, અને IKE સફળ થતું રહેતાં તેનો આગળનો પ્રયાસ ડેટા તબક્કે નિષ્ફળ જશે. તમે સ્થાપિત IKE સુરક્ષા સંગઠનો જોશો અને કોઈ સુરક્ષિત ટ્રાફિક નહીં, જે વાયર પર કેપ્ચર ન કરો ત્યાં સુધી રાઉટિંગ ખામી જેવું લાગે છે.

તેથી એન્કેપ્સ્યુલેશન એ તમે ગોઠવો છો તે કનેક્શનનો ગુણધર્મ છે, નેટવર્કના વર્તન પરથી પક્ષો વાટાઘાટ કરતું પરિણામ નહીં.

encap વિનિમયને કેવી રીતે બદલે છે

આધુનિક strongSwan જમાવટમાં, જે swanctl.conf દ્વારા સંચાલિત થાય છે, કનેક્શન પર encap = yes સેટિંગ NAT-શોધ વિનિમયને અસર કરે છે જેથી બંને પક્ષ ESP માટે UDP એન્કેપ્સ્યુલેશન વાપરે. સુરક્ષિત પેકેટ પછી UDP ની અંદર, સામાન્ય રીતે પોર્ટ 4500 પર મુસાફરી કરે છે, અને બંને છેડાએ એ ગોઠવણી પર સહમત થવું પડે છે.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

strongSwan ની NAT-traversal માર્ગદર્શિકા આ વર્તનનું વર્ણન કરે છે, જેમાં MOBIKE વપરાય ત્યારે પોર્ટ ફ્લોટિંગ સાથેની ક્રિયાપ્રતિક્રિયાનો સમાવેશ થાય છે.

તમારા બેકએન્ડની પોતાની સેટિંગ વાપરો

strongSwan માં બે કન્ફિગરેશન બેકએન્ડ છે, અને કી તેમની વચ્ચે અલગ છે. એક swanctl.conf કનેક્શન encap લે છે, જ્યારે જૂનું ipsec.conf કનેક્શન forceencaps લે છે. એક બેકએન્ડનો કીવર્ડ બીજામાં નાખવાથી એવી કન્ફિગરેશન બને છે જે ફરિયાદ વગર લોડ થાય છે અને કંઈ બદલતી નથી, જે ભૂલ કરતાં પણ ખરાબ છે.

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

કનેક્શનના માલિક દ્વારા ફેરફાર લાગુ કરો અને નિયંત્રિત વિન્ડોમાં સંગઠન ફરી સ્થાપિત કરો. પહેલેથી સ્થાપિત child બદલાય નહીં ત્યાં સુધી તેનું વર્તમાન એન્કેપ્સ્યુલેશન રાખે છે, તેથી ફક્ત ફાઇલ સંપાદન નવી ગોઠવણી વપરાય છે તે સાબિત કરતું નથી.

વીંટાયેલા ડેટાની ચકાસણી કરો, ફક્ત પોર્ટની નહીં

સુરક્ષિત ટ્રાફિક વહેતો હોય ત્યારે ગેટવે પર કેપ્ચર કરો, પછી તેને strongSwan ના પોતાના દૃશ્ય સાથે સરખાવો:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP IP પ્રોટોકોલ 50 તરીકે દેખાય છે અને UDP જેવું બિલકુલ લાગતું નથી. વીંટાયેલો ESP 4500 પર UDP ડેટાગ્રામ તરીકે દેખાય છે જેનો પેલોડ IKE નથી. એ જ પોર્ટ પરનો IKE ટ્રાફિક એન્કેપ્સ્યુલેશનનો પુરાવો નથી, કારણ કે MOBIKE IKE ને ત્યાં ખસેડી શકે છે જ્યારે ડેટા માર્ગ native રહે છે, તેથી પોર્ટ નંબર નહીં, પેલોડ વાંચો.

પાથ MTU પણ ધ્યાનમાં રાખો. આવરણ વધારાનો ખર્ચ ઉમેરે છે, અને native ESP વહન કરતો માર્ગ પેકેટ મોટા થાય ત્યારે ગોઠવણની જરૂર પડી શકે છે. જરૂરી ICMP હેન્ડલિંગ પહેલેથી ડિઝાઇનનો ભાગ હોવું જોઈએ; એન્કેપ્સ્યુલેશન એ નિર્ભરતા દૂર કરતું નથી.

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

સંબંધિત લેખો