tun0 નથી? nftables માં ડિક્રિપ્ટ થયેલ IPsec ને meta ipsec સાથે મેળ કરો

તમે ટનલ ઇન્ટરફેસની અપેક્ષા રાખો છો, તેને શોધો છો, અને ફાયરવોલમાં મેળ કરવા જેવું કંઈ નથી. આ નીતિ-આધારિત ગેટવે માટે સામાન્ય છે: એન્ક્રિપ્ટેડ વિનિમય ભૌતિક ઇન્ટરફેસ પર આવે છે, અને પછી ફોરવર્ડ થતું ડિક્રિપ્ટ થયેલ આંતરિક પેકેટ પણ એ જ ઇન્ટરફેસ પર આવતું જોવા મળે છે. tun0 નથી, કારણ કે કોઈએ તેને બનાવ્યું નથી.

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

બે પેકેટ, એક ઇન્ટરફેસ

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

તેને અલગ પાડે છે પેકેટ સાથે જોડાયેલ આવતા સુરક્ષા માર્ગનો સંદર્ભ. nftables તેને meta ipsec exists તરીકે બતાવે છે, જે સાચું છે જ્યારે પેકેટ IPsec સુરક્ષા માર્ગ દ્વારા આવ્યું હોય. તેને ક્લાયંટ પૂલ, ગંતવ્ય અને સેવા સાથે જોડો, નિયમ સુરક્ષિત રહે તેટલો ચોક્કસ બની જાય છે.

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

ફોરવર્ડિંગ નિયમ લખો

ધારો કે 10.90.0.0/24 માં ક્લાયંટ સાથેની પ્રમાણિત IPv4 રિમોટ-એક્સેસ સેવા અને 203.0.113.40 પર એક મંજૂર ગંતવ્ય છે. તે પ્રવાહ માટે નિયમનો ટુકડો આવો દેખાય છે.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

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

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

આવતો સંદર્ભ જતો સંદર્ભ નથી

એ જ પ્રકારની અભિવ્યક્તિઓ બીજી દિશાને rt ipsec થી આવરી લે છે, જે પેકેટ વાપરશે તે જતા સુરક્ષા સંગઠનનું વર્ણન કરે છે. તે બીજા પ્રશ્નનો જવાબ આપે છે: આ પેકેટ ક્યાંથી આવ્યું તે નહીં, પણ તેની આગલી કડીમાં તે સુરક્ષિત રહેશે કે નહીં.

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

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

NAT ફાયરવોલ નિર્ણય નથી

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

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

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

ચોક્કસ આંતરિક સેવા ચકાસો

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

nftables સંદર્ભ meta ipsec, rt ipsec અને દિશા-વિશિષ્ટ અભિવ્યક્તિઓનું દસ્તાવેજીકરણ કરે છે, અને તમારી સ્થાપિત આવૃત્તિ સામે વાક્યરચના ચકાસવાનું સ્થળ એ જ છે. અને વ્યાપ સ્પષ્ટ રાખો: આ IPv4 ઉદાહરણ છે, તે IPv6 વિશે કંઈ કહેતું નથી, અને તે મનસ્વી જાહેર પોર્ટ ફોરવર્ડિંગને VPN સેવાનો ભાગ બનાવતું નથી.