OpenVPN રૂટ strongSwan XFRM નીતિ સામે કેમ હારે છે

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

બે નિર્ણય, એક નહીં

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

પહોળું IPsec સિલેક્ટર સામાન્ય કારણ છે. 172.16.0.0/12 ને સુરક્ષિત કરતી નીતિ 172.20.8.0/24 ને પણ આવરે છે, જ્યાં વ્યવસ્થાપક કદાચ OpenVPN ટનલ દ્વારા પહોંચવાનો ઇરાદો ધરાવે છે. ઇરાદો ફક્ત રાઉટિંગ કોષ્ટકમાં જ છે, અને નીતિ ડેટાબેઝને તેની ક્યારેય જાણ થઈ નથી.

તેને બે રૂપરેખાંકિત સુરક્ષા માર્ગો વચ્ચેના સંઘર્ષ તરીકે ગણો, બે મેટ્રિક વચ્ચેની સ્પર્ધા તરીકે નહીં. સુધારો તે ઘટકમાં જવો જોઈએ જે ખોટા વ્યાપ સાથે રૂપરેખાંકિત થયું હતું.

કર્નલ ખરેખર કયો રૂટ પસંદ કરે છે તે વાંચો

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

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

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

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

જે નીતિ પણ લાગુ પડે છે તે વાંચો

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

ip -s xfrm policy
swanctl --list-sas

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

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

જ્યારે બંને માર્ગ કાયદેસર હોય ત્યારે ત્રણ વિકલ્પ

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

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

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

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

બાકીનાને નબળું ન કરતાં અપવાદ સાબિત કરો

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

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