તમારો iptables નિયમ બ્રિજ થયેલ VPN ટ્રાફિક ક્યારેય કેમ જોતો નથી
બ્રિજ થયેલ ફ્રેમ તમે જોઈ રહ્યા છો તે IP ચેઇનને ટાળી શકે છે. બીજો નિયમ ઉમેરતા પહેલા મૂળ bridge કુટુંબની જૂના br_netfilter સાથે તુલના કરો.
એક જ હોસ્ટ પરની બે વર્ચ્યુઅલ મશીનો બ્રિજ દ્વારા LAN સુધી પહોંચે છે, અને ip forward ચેઇનમાં મૂકેલો નિયમ એવો કાઉન્ટર દર્શાવે છે જે ક્યારેય ખસતો નથી. ફ્રેમ વાસ્તવિક છે, ટ્રાફિક પસાર થઈ રહ્યો છે, અને નિયમ ફક્ત તેના માર્ગ પર નથી. Linux બ્રિજ ટ્રાફિકને જાહેર કરવાની બે રીતોની તુલના આ મૌનને સમજાવે છે, અને તે એ પણ સમજાવે છે કે એક જૂનું મોડ્યુલ લોડ કરવું જેટલું સરળ લાગે છે તેના કરતાં ખરાબ જવાબ કેમ છે.
એક હોસ્ટમાંથી બે માર્ગ
એક પેકેટ આ હોસ્ટને બે ખૂબ જ અલગ રીતે છોડી શકે છે, અને તે તફાવત નક્કી કરે છે કે કયા હૂક તેને જોશે. જો ગંતવ્ય ભૌતિક પોર્ટની બહાર હોય અને ફ્રેમ બ્રિજના બે પોર્ટ વચ્ચે સ્વિચ થાય, તો હોસ્ટ Ethernet ફ્રેમ ફોરવર્ડ કરે છે; રૂટિંગ કોડને પૂછવામાં આવતું નથી, અને કોઈ રૂટેડ હોપ થતું નથી. જો ગંતવ્ય હોસ્ટ પોતે હોય, અથવા ટનલ ઇન્ટરફેસ દ્વારા પહોંચાતું નેટવર્ક હોય, તો પેકેટ રૂટ થાય છે અને IP સ્તરના હૂક ખરેખર લાગુ પડે છે. આ ફાંટો યાદ રાખો, કારણ કે ચેઇન અને કુટુંબો વિશેનો દરેક પછીનો પ્રશ્ન ફ્રેમ બે માર્ગમાંથી કયો લે છે તેના પરથી આવે છે.
આ ભેદ એવા નિયમની પાછળની આખી વાર્તા છે જે કંઈ ગણતો નથી. veth9a1 થી enp3s0 સુધીની બ્રિજ થયેલ ફ્રેમ બ્રિજને પાર કરે છે, IP સ્ટેકને નહીં, તેથી ip forward ચેઇનને મેળવવા માટે કંઈ દેખાતું નથી. જૂના ઉદાહરણમાંના ઇન્ટરફેસ નામ નક્કી કરતા નથી કે તમારી પાસે કયો માર્ગ છે, અને તેથી પ્રથમ પગલું રૂલસેટને બદલે ટોપોલોજી તરફ જોવાનું છે.
ટનલ એક ત્રીજો કેસ ઉમેરે છે જે નામ આપવા યોગ્ય છે. TUN ઉપકરણ IP પેકેટ હોસ્ટને પહોંચાડે છે, તેથી તે રૂટ થાય છે અને ખરેખર IP ચેઇનમાંથી પસાર થાય છે, જ્યારે બ્રિજ સાથે જોડાયેલ TAP ઉપકરણ ફ્રેમ પહોંચાડે છે અને બ્રિજ કેસ જેવું વર્તન કરે છે. ઉપકરણનો પ્રકાર, ઉત્પાદનનું નામ નહીં, નક્કી કરે છે.
બ્રિજ થયેલ ફ્રેમ જોઈ શકતા બે કુટુંબોની તુલના કરો
Linux nftablesના bridge કુટુંબ દ્વારા મૂળ બ્રિજ ફિલ્ટરિંગને સમર્થન આપે છે, અને ઉડાનમાં ફ્રેમની તપાસ કરીને તેમને કાઢી નાખવા માટે તેને કોઈ જૂના મોડ્યુલની જરૂર નથી. કર્નલનું પોતાનું બ્રિજ દસ્તાવેજીકરણ સીધું આ ભલામણ કરે છે, જે સર્ચ પરિણામ તમને મોડ્યુલ લોડ કરવા કહે તે પહેલાં જાણવા જેવું છે.
| Observation point | What it sees | What it costs |
|---|---|---|
nftables bridge family chains | Ethernet frames forwarded between bridge ports, in both directions | Rules must be written in bridge syntax with link-layer matches |
Legacy br_netfilter plus an ip chain | Bridged IPv4 and IPv6 packets, re-exposed through IP-layer hooks | Existing host rules may begin matching traffic they never saw before |
inet chain for routed traffic | Packets the host routes, including traffic arriving from a TUN device | No visibility into purely switched frames |
iptablesને બદલે nft આદેશ વાપરવો, પોતાના આપમાં નિયમને યોગ્ય કુટુંબમાં મૂકતું નથી. bridge કુટુંબમાં ઘોષિત ચેઇન ફ્રેમ જુએ છે; ip, ip6 અથવા inetમાં ઘોષિત ચેઇન તેમને જોતી નથી, તેને કઈ બાઈનરીએ બનાવી હોય તે મહત્વનું નથી. કુટુંબ ચેઇનની ગુણવત્તા છે, તે ટાઇપ કરનાર સાધનની નહીં.
જૂનો માર્ગ અલગ રીતે કામ કરે છે, અને તેથી જ આદતવશ પક્ષ પસંદ કરવાને બદલે તુલના કરવી જોઈએ. br_netfilter લોડ કરવું અને bridge-nf-call સેટિંગ્સ સક્ષમ કરવાથી બ્રિજ થયેલ IPv4 અને IPv6 ટ્રાફિક ફરીથી IP સ્તરના હૂક દ્વારા જાહેર થાય છે, જેથી સામાન્ય iptables નિયમ છેવટે તેને મેળવી શકે. ફ્રેમ બદલાતી નથી; તેઓ જે હૂકમાંથી પસાર થાય છે તે સમૂહ બદલાય છે, જેનો અર્થ છે કે દરેક હાલના હોસ્ટ નિયમને હવે નવું પ્રેક્ષકગણ મળ્યું છે.
નિયમ ઉમેરતા પહેલા અસરકારક માર્ગ વાંચો
ત્રણ આદેશ નક્કી કરે છે કે તમે ક્યાં છો: બ્રિજ શેની સાથે જોડાયેલું છે, જૂનું મોડ્યુલ સક્રિય છે કે નહીં, અને bridge કુટુંબમાં કઈ ચેઇન પહેલેથી છે. કંઈ લખતા પહેલા તેમને ચલાવો, કારણ કે જવાબ નક્કી કરે છે કે તમે બે ડિઝાઇનમાંથી કઈ વિસ્તારી રહ્યા છો. આ પગલું છોડી દેવું એ જ રીતે સાચો નિયમ એવી ચેઇનમાં પડે છે જેમાંથી કંઈ પસાર થતું નથી.
bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"આઉટપુટ કેસોને સ્વચ્છ રીતે અલગ કરે છે. બ્રિજ નીચે સૂચિબદ્ધ પોર્ટ તમને કહે છે કે કઈ ઇન્ટરફેસ સ્વિચ થાય છે; ખાલી lsmod પરિણામનો અર્થ છે બ્રિજ થયેલ ફ્રેમની IP સ્તર પર કોઈ દૃશ્યતા નહીં; હાલની bridge કુટુંબની forward ચેઇનનો અર્થ છે કે નીતિનો માલિક પહેલેથી છે અને તમારો નિયમ પોતાની નવી ચેઇનમાં નહીં, ત્યાં જ આવે છે.
પછી પાછું વાંચવામાં સરળ એવો એક નિયમ ઉમેરો, કાઉન્ટર સાથે અને ચુકાદો બદલ્યા વિના, અને એક પ્રતિનિધિ ફ્લો બ્રિજમાંથી પસાર કરો. ખસતું કાઉન્ટર સાબિત કરે છે કે ફ્રેમ નિયમ સુધી પહોંચી. તેટલું જ તે સાબિત કરે છે, તેથી નકારાયેલા માર્ગ સાથે પણ આગળ વધો, કારણ કે બધું સ્વીકારતી નીતિ પણ ખસતું કાઉન્ટર બનાવે છે.
nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter acceptજૂનું મોડ્યુલ વર્તન ક્યાં બદલે છે
ચાલુ બ્રિજ પર જૂનો માર્ગ સક્ષમ કરવો એ દૃશ્યતા ઉમેરવાની તટસ્થ ક્રિયા નથી. પહેલાં બ્રિજ ટ્રાફિક માટે અગમ્ય રહેલા નિયમો ગમ્ય બને છે, જેમાં બીજા ઇન્ટરફેસ માટે લખાયેલા હોસ્ટ નિયમોનો સમાવેશ થાય છે, અને ip forward ચેઇનમાંની મૂળભૂત drop નીતિ અચાનક એવી ફ્રેમ પર લાગુ થઈ શકે છે જે પહેલાં અડ્યા વિના પસાર થતી હતી. જે હોસ્ટ તે બ્રિજ દ્વારા સંચાલિત થાય છે, ત્યાં પરિણામ કન્સોલ વિનાનું લોકઆઉટ છે. આ કાલ્પનિક નિષ્ફળતા મોડ નથી; આ તમે હમણાં જ પહોળો કરેલા માર્ગ દ્વારા પહોંચતા મશીન પર હૂકનો સમૂહ પહોળો કરવાનું સામાન્ય પરિણામ છે.
વધુ સુરક્ષિત ક્રમ એ છે કે કયું કુટુંબ નીતિનું માલિક છે તે નક્કી કરવું, નિયમો ત્યાં લખવા, અને કોઈપણ sysctl બદલતા પહેલા સ્વતંત્ર પુનઃપ્રાપ્તિ માર્ગ રાખવો. જો બે કુટુંબો નિયમો ધરાવે છે, તો કયું સત્તાવાર છે તે દસ્તાવેજ કરો; બે ઓવરલેપ થતી નીતિઓ એ જ રીતે પેકેટ એક જગ્યાએ સ્વીકારાય છે અને બીજે કાઢી નાખવામાં આવે છે, વાંચવા માટે એક પણ ફાઇલ વિના.
અલગતાને પોતે હજી સંપૂર્ણ ડિઝાઇનની જરૂર છે. એક સ્રોતને એક ગંતવ્ય સુધી મંજૂરી આપવી ફક્ત એ સાબિત કરે છે કે એક ફ્લો કામ કરે છે, જ્યારે જરૂરિયાત સામાન્ય રીતે એ હોય છે કે VM તેના પડોશીઓ કે હોસ્ટ સુધી પહોંચી ન શકે. નકાર નિયમો પરના કાઉન્ટર સ્વીકાર નિયમના કાઉન્ટર કરતાં વધુ મહત્વના છે, કારણ કે સ્વીકાર કાઉન્ટર એ છે જે ખસશે તેવી તમે પહેલેથી અપેક્ષા રાખી હતી.
છેલ્લે, હોસ્ટ-ઇનપુટ કેસને અલગ રાખો. બ્રિજના પોતાના IP પર સંબોધિત ટ્રાફિક input પર આવે છે, forward પર નહીં, અને forwardમાંનો નિયમ તમે કયું કુટુંબ પસંદ કરો તે ધ્યાનમાં લીધા વિના તેને ક્યારેય જોશે નહીં. ત્રણ કેસ, બે કુટુંબ, એક પાઠ: માર્ગ હૂક નક્કી કરે છે, અને હૂક નક્કી કરે છે કે તમારો નિયમ બિલકુલ છે કે નહીં.