સ્થાનિક એપ, VPN નિયમ: તમારી FORWARD ચેઇન કેમ ક્યારેય સક્રિય થતી નથી
મશીન પરની પ્રક્રિયા OUTPUT વાપરે છે, FORWARD નહીં. યોગ્ય namespace માં hook પસંદ કરો, પછી નક્કી કરો કે mark કે સાદો રૂટ પૂરતો છે.
તમે FORWARD ચેઇનમાં VPN ટ્રાફિક માટે નિયમ ઉમેરો છો, એ જ Linux બોક્સમાંથી વિનંતી ચલાવો છો, અને કાઉન્ટર શૂન્ય જ રહે છે. નિયમ કદાચ સાચો છે. પેકેટ ક્યારેય એ માર્ગે ગયું જ નહીં, કારણ કે મશીન પર જ ઉત્પન્ન થયેલી વિનંતી તેના દ્વારા ફોરવર્ડ થતી નથી. સોકેટથી વાયર સુધી પેકેટનું જીવન ટ્રેસ કરવાથી સમજાય છે કે એવું કેમ છે, અને નિયમ ખરેખર ક્યાં હોવો જોઈએ.
પેકેટ ક્યાં જન્મ્યું તે શોધો
Netfilter નો hook ક્રમ ત્રણ કેસ અલગ પાડે છે, અને તેમાંથી ફક્ત એકમાં FORWARD આવે છે:
| Origin | Path | Hook that sees it |
|---|---|---|
| Local process | OUTPUT then POSTROUTING | OUTPUT, POSTROUTING |
| Addressed to a local service | PREROUTING then INPUT | PREROUTING, INPUT |
| Received for another host | PREROUTING, FORWARD, POSTROUTING | FORWARD |
સ્થાનિક એપ્લિકેશન OUTPUT માર્ગમાં શરૂ થાય છે, કારણ કે કર્નલ પહેલેથી જ નક્કી કરી ચૂક્યું છે કે પેકેટ અહીં ઉદ્ભવે છે અને તે ક્યારેય ફોરવર્ડિંગ માટે ઉમેદવાર નથી. ટનલ બનાવવાથી એ વર્ગીકરણ બદલાતું નથી; ટનલ એ ઉપકરણ છે જેમાંથી પેકેટ બહાર જઈ શકે છે, સ્થાનિક આઉટપુટને ટ્રાન્ઝિટમાં ફેરવતું તબક્કો નહીં.
બે પેકેટ, એક વાર્તા
ટનલ ચાલુ થયા પછી એપનું આંતરિક પેકેટ અને એન્ક્રિપ્ટ થયેલું બાહ્ય પેકેટ બે અલગ વસ્તુઓ છે. આંતરિક પેકેટ એપે પસંદ કરેલું ગંતવ્ય અને પેલોડ વહન કરે છે. બાહ્ય પેકેટ સાઇફરટેક્સ્ટને પીઅરના સરનામા અને પોર્ટ પર લઈ જાય છે, અને ભૌતિક ઇન્ટરફેસ ખરેખર એ જ પસાર કરે છે.
તમારી નીતિ તેમાંથી એક સાથે સંબંધિત છે, અને ખોટું પસંદ કરવું એ સામાન્ય કારણ છે કે નિયમ કંઈ કરતો નથી એવું લાગે. પીઅરના બાહ્ય સરનામા સાથે મેળ ખાતો નિયમ દરેક ટનલ પેકેટને સમાન રીતે જુએ છે, અંદરની એપ શું કરે છે તે ધ્યાનમાં લીધા વિના. આંતરિક ગંતવ્ય સાથે મેળ ખાતો નિયમ તમને જરૂરી ટ્રાફિક જુએ છે, અને તે ત્યારે જ સક્રિય થશે જ્યારે એ પેકેટ તમે નિયમ સ્થાપિત કર્યો હોય તે hook સુધી પહોંચશે.
namespace સીમા ખસેડે છે
કન્ટેનર સિદ્ધાંત બદલ્યા વિના આને વધુ મુશ્કેલ બનાવે છે. એપની વિનંતી કન્ટેનરના નેટવર્ક namespace ની અંદરનું સ્થાનિક આઉટપુટ છે. હોસ્ટ એ ટ્રાફિક વર્ચ્યુઅલ Ethernet ઇન્ટરફેસ પર મેળવે છે અને તેને ફોરવર્ડ કરી શકે છે, તેથી હોસ્ટ પરનો FORWARD નિયમ અર્થપૂર્ણ હોઈ શકે છે, છતાં વિનંતી ઉત્પન્ન કરનારી પ્રક્રિયાએ હોસ્ટની OUTPUT ચેઇનને ક્યારેય અડી નથી.
hook પસંદ કરતા પહેલા નક્કી કરો કે નિયમસમૂહ અને ટનલ ખરેખર ક્યાં રહે છે. કન્ટેનરની અંદર ટનલ, હોસ્ટ પર ટનલ અને કન્ટેનરને તેમાંથી રૂટ કરવું, અને અલગ namespace માં ટનલ એ ત્રણ અલગ ટોપોલોજી અને ત્રણ અલગ નિયમ-સ્થાન છે. જે namespace ઉપકરણનો માલિક છે તેની અંદરના નિયમો વાંચો, ફક્ત ડિફોલ્ટમાં નહીં.
પૂછો કે તમને mark ની જરૂર છે કે નહીં
જો ધ્યેય એક ગંતવ્ય પ્રિફિક્સ ટનલ દ્વારા મોકલવાનો હોય, તો એ પ્રિફિક્સ માટે રૂટ પૂરતો હોઈ શકે. પહેલા અસરકારક રૂટ તપાસો, સર્વરે ધકેલેલી કોઈપણ વસ્તુ સહિત: રીડાયરેક્ટ થયેલું ડિફોલ્ટ તમે ધારેલી સાંકડી નીતિ કરતાં ઘણું વધુ ટ્રાફિક VPN દ્વારા મોકલે છે, અને કેટલુંય mark કરો તો પણ પરિણામ ઉદ્દેશ સાથે મેળ ખાશે નહીં.
વર્ગીકરણ ત્યારે જરૂરી છે જ્યારે નિર્ણય એવી કોઈ વસ્તુ પર આધારિત હોય જે રૂટ વ્યક્ત કરી શકતું નથી, જેમ કે સ્રોત, વપરાશકર્તા કે પ્રક્રિયા. પ્રાપ્ત ટ્રાફિક માટે PREROUTING માં mark કામ કરે છે. સ્થાનિક ટ્રાફિક માટે mark એ આઉટપુટ તબક્કામાં થવું જોઈએ જે mark સેટ થયા પછી નવી રૂટ શોધ શરૂ કરી શકે. nftables માં તે આઉટપુટ hook પર route પ્રકારની ચેઇન છે; સામાન્ય આઉટપુટ ફિલ્ટર ચેઇન મૂલ્ય સેટ કરશે અને રૂટ અબદલ રાખશે.
iptables માં સમાન ચીજ mangle OUTPUT ગોઠવણીમાં રહે છે, અને એ જ શરત લાગુ પડે છે: mark અસ્તિત્વમાં આવ્યા પછી રૂટિંગ નિર્ણય ફરી જોવો જોઈએ. પછી નીતિ-નિયમે mark વાપરવો જોઈએ અને ઉપયોગી રૂટ ધરાવતા કોષ્ટક તરફ નિર્દેશ કરવો જોઈએ. conntrack mark સેટ કરવું ત્રીજું, અલગ ઑપરેશન છે; તે ફ્લો પર મૂલ્ય સંગ્રહે છે અને પોતાની રીતે એ મૂલ્ય વર્તમાન પેકેટ પર મૂકતું નથી જેથી રૂટિંગ તેને વાંચી શકે.
શોધ અને કાઉન્ટર સાથે ચકાસો
nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1સરનામું અને mark ઉદાહરણરૂપ છે, અને બે રૂટ પ્રશ્નો બે અલગ પ્રશ્નોના જવાબ આપે છે. બીજો પૂછે છે કે પેકેટમાં એ mark હોત તો કર્નલ શું કરત; તે સાબિત કરતું નથી કે તમારો નિયમસમૂહ કોઈ mark આપે છે. તેને પરિકલ્પના-કસોટી તરીકે લો, નીતિ કામ કરે છે તેના પુરાવા તરીકે નહીં.
પછી એક નિર્દોષ વિનંતી ચલાવો અને એક સાથે બે વસ્તુઓ જુઓ: તમે પસંદ કરેલા hook પરનું કાઉન્ટર, અને પેકેટે ખરેખર લીધેલો નિર્ગમ માર્ગ. કાઉન્ટર વધે અને પેકેટ બીજે જ બહાર નીકળે તો mark કે કોષ્ટક ખોટું છે. બંમાંથી કંઈ ન વધે તો પેકેટ એ hook સુધી પહોંચતું જ નથી, અને આગળનો પ્રશ્ન namespace કે માર્ગ છે.
અંતે, પરીક્ષણને જે માળખું વ્યક્ત કરી શકે તે પૂરતું મર્યાદિત રાખો. એક સરનામા માટેનો એક રૂટ, સરનામાં બદલાતા રહેતી સેવા માટે કાયમી નીતિ બનતો નથી. પહેલા પેકેટનો વ્યાપ નક્કી કરો, પછી ચકાસો કે રૂટિંગ અને mark રચના ફરી જોડાણ પછી પણ એ વ્યાપ ટકાવી શકે છે કે નહીં.