உங்கள் 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 க்கு முகவரியிடப்பட்ட போக்குவரத்து forward அல்ல, input க்கு வருகிறது, forward இல் உள்ள விதி நீங்கள் எந்தக் குடும்பத்தைத் தேர்ந்தெடுத்தாலும் அதை ஒருபோதும் பார்க்காது. மூன்று நிலைகள், இரண்டு குடும்பங்கள், ஒரு பாடம்: பாதை கொக்கியைத் தீர்மானிக்கிறது, கொக்கி உங்கள் விதி இருக்கிறதா இல்லையா என்பதைத் தீர்மானிக்கிறது.