OpenVPN வழியாக இரண்டு பலகைகளுக்கு இடையே தனிமைப்படுத்தப்பட்ட TAP பாலம்

இரண்டு மேம்பாட்டு பலகைகள் ஒரு Ethernet பிரிவைப் பகிர வேண்டும், அதே நேரத்தில் அவற்றின் பெஞ்சுகள் வெவ்வேறு கட்டிடங்களில் உள்ளன. சுரங்கப்பாதை ஏற்கனவே உள்ளது மற்றும் ஏற்கனவே Ethernet ஐ எடுத்துச் செல்கிறது, எனவே மீதமுள்ள வேலை மூன்று கட்டளைகள் போலத் தெரிகிறது, ஆனால் அப்படி இல்லை. ஹோஸ்ட் பாலமிட்ட பிரேமுடன் என்ன செய்கிறது, கணினியின் சொந்த முகவரி எங்கே உள்ளது, மற்றும் பாலம் எந்த எல்லையை உருவாக்கவில்லை என்பது மூன்று தனித்தனி உண்மைகள், இரண்டாவதில் தவறு செய்வதே ஆய்வகம் இடைவிடாமல் இயங்குவதற்கும் அதன் நிர்வாக அணுகல் அமைதியாக மோசமாவதற்கும் வழக்கமான காரணம். இந்த மூன்று உண்மைகளில் எதுவும் டோபாலஜி வரைபடத்தில் தெரியவில்லை.

கீழே உள்ள பாதை இரண்டு Linux கணினிகளுக்கு இடையே அங்கீகரிக்கப்பட்ட TAP இணைப்பு, ஒவ்வொரு பெஞ்சிற்கும் ஒரு பிரத்யேக கம்பி துறை, மற்றும் சோதனையின் பகுதியாக இல்லாத நிர்வாக இடைமுகம் ஆகியவற்றைக் கருதுகிறது. வரிசை முக்கியம்: முதலில் பிரேம்கள், பின்னர் முகவரிகள், கடைசியாக எல்லை.

பாலம் உண்மையில் என்ன நகர்த்துகிறது

பாலம் என்பது மென்பொருளில் செயல்படுத்தப்பட்ட சுவிட்ச். எந்த MAC முகவரி எந்த உறுப்பினர் துறைக்கு பின்னால் தோன்றுகிறது என்பதைக் கற்றுக்கொண்டு, IP ரூட்டிங் அட்டவணையைப் பார்க்காமல் உறுப்பினர்களுக்கு இடையே பிரேம்களை அனுப்புகிறது. அந்த விளக்கத்தில் சப்நெட், கேட்வே அல்லது இயல்புநிலை பாதை இல்லை, அதனால்தான் IP அனுப்புதலை இயக்குவது இந்த இணைப்பை உருவாக்காது, மேலும் ping வெற்றிபெறும்போது மற்ற டிராஃபிக் தோல்வியடைகிறது. பலகை எந்த இயல்புநிலை பாதையும் இல்லாமல் அதன் துணைக்கு சென்றடைய முடியும், இது அடுக்கு இரண்டு அடுக்கு மூன்று போல நடந்துகொள்ளும் என எதிர்பார்ப்பவர்களை ஆச்சரியப்படுத்துகிறது.

ஒவ்வொரு கணினியும் பாலத்திற்கு ஒரு கம்பி துறையையும் TAP சாதனத்தையும் அதே பாலத்திற்கு வழங்குகிறது, எனவே பலகையிலிருந்து ஒரு பிரேம் உள்ளூர் துறைக்குள் நுழைந்து, TAP சாதனத்திற்கு அனுப்பப்பட்டு, சுரங்கப்பாதையைக் கடந்து, துணையின் TAP சாதனத்தை அடைந்து துணையின் பலகைக்கு அனுப்பப்படுகிறது. சுரங்கப்பாதை மற்ற எந்த உறுப்பினர் துறையையும் போலவே உள்ளது, மேலும் பாலம் அதன் பின்னால் VPN உள்ளது என்பதை அறியாது, கவலைப்படாது. இந்த சமச்சீர்மையே உதாரணத்தைப் புரிந்துகொள்வதை எளிதாக்குகிறது: ஒவ்வொரு பக்கமும் ஆய்வகத்தை நோக்கிய ஒரு துறையும் ஒரு சுரங்கப்பாதை துறையும் கொண்டுள்ளது, எந்தப் பக்கமும் சிறப்பானது அல்ல.

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

இரு கணினிகளிலும் உள்ள ஒரே பெயர்கள் உள்ளூர் பெயர்கள், பகிரப்பட்ட பொருட்கள் அல்ல. பெஞ்சுகளுக்கு இடையே ஒரு Ethernet பாதை உள்ளது, இரண்டாவது கேபிள் மற்றும் சுழற்சியை மூடும் இரண்டாவது சுரங்கப்பாதை இல்லாமல்; ஒரே MAC இரண்டு துறைகளில் வருவதைக் காணும் பாலம் மகிழ்ச்சியுடன் வட்டமாக அனுப்பும்.

பாலத்திற்கு முகவரி கொடுங்கள், அதன் உறுப்பினர் துறைகளுக்கு அல்ல

ஆய்வகப் பிரிவில் கணினியின் அடையாளம் பாலம் சாதனத்திற்கு உரியது. உறுப்பினர் துறைகள் எண் இல்லாமல் இருக்கும், ஏனெனில் துறை என்பது அனுப்பும் உறுப்பினர், அதன் மேல் ஒரு முகவரி அதே பிரிவின் இரண்டாவது, போட்டியிடும் உரிமையாளரை உருவாக்கும். இதுவே பெரும்பாலான கையால் எழுதப்பட்ட செய்முறைகள் தவறாகச் செய்யும் திருத்தம்: அவை TAP சாதனத்திற்கும் பாலத்திற்கும் முகவரி கொடுத்து, பின்னர் துணை உண்மையில் எதை அடைகிறது என்று யோசிக்கின்றன.

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

துணை வேறு ஹோஸ்ட் முகவரியுடன் அதே வடிவத்தைப் பயன்படுத்துகிறது, பலகைகள் அதே வரம்பில் முகவரிகளை எடுத்து, தேவைப்பட்டால் கணினியின் பாலம் முகவரியை அடுத்த தாவலாகப் பயன்படுத்துகின்றன. திட்டம் ஒப்புக்கொள்ளப்படும் வரை ஆவண வரம்புகளைப் பயன்படுத்தவும், அலுவலகம் ஏற்கனவே வழிநடத்தும் எதனுடனும் மோதாமல் இருக்க வரம்பை ஒதுக்கவும். எதையும் இயக்கும் முன், உறுப்பினர் துறைகளில் மீதமுள்ள முகவரி, DHCP கிளையண்ட் மற்றும் மற்றொரு பாலத்தில் உறுப்பினர் நிலை இல்லை என்பதை உறுதிப்படுத்தவும், மேலும் TAP சாதனத்தின் முகவரியிடலை சுரங்கப்பாதை உள்ளமைவைக் கொண்டிருப்பதன் மூலம் ஒத்திசைக்கவும், பின்னர் முகவரியை மீட்டெடுக்காதபடி.

ஒவ்வொரு பெஞ்சிற்கும் ஒரு பிரத்யேக துறை ஏன்

பிரத்யேக கம்பி துறையே சோதனையை முழு அலுவலக மாற்றமாக மாறுவதைத் தடுக்கிறது. நிர்வாக இடைமுகம் SSH, இயல்புநிலை பாதை மற்றும் வெளிப்புற VPN இணைப்பை எடுத்துச் செல்கிறது, அவற்றில் எதுவும் ஆய்வக பிரேம்களை நகர்த்துவதே நோக்கமாகக் கொண்ட பாலத்திற்கு சொந்தமானது அல்ல.

நிர்வாக அடாப்டரை இணைப்பது அலுவலக LAN ஐ மேம்பாட்டு பலகையிலிருந்து ஒரு அனுப்புதல் முடிவு தூரத்தில் வைக்கிறது, அடுக்கு இரண்டில் மோசமாக நடந்துகொள்ளும் பலகை அந்தப் பிரிவில் நீங்கள் விரும்பாத சாதன வகையே. Wi-Fi அடாப்டர் இன்னும் மோசம்: உள்கட்டமைப்பு பயன்முறையில் கம்பியற்ற இடைமுகத்தை பாலமிடுவது Ethernet ஐ பாலமிடுவது போல நடந்துகொள்ளாது, தோல்வி சுத்தமாக இல்லாமல் குழப்பமாக உள்ளது.

ஆய்வக வரம்பை எந்த உற்பத்தி DHCP எல்லைக்கும் வெளியே வைத்திருங்கள். பலகைகளுக்கு பின்னர் மாறும் முகவரியிடல் தேவைப்பட்டால், ஒரு குளத்துடன் ஒரு அதிகாரமளிக்கப்பட்ட ஒதுக்கீட்டாளர் மட்டுமே கணிக்கக்கூடியதாக இருக்கும்; ஒரே பிரிவில் பதிலளிக்கும் இரண்டு தளங்களின் சாதாரண ரவுட்டர்கள் யாரும் விளக்கமுடியாத முகவரிகளை உருவாக்குகின்றன.

பாலம் உருவாக்காத எல்லை

பாலமிடுவது ரூட்டிங் அல்ல, அது தனிமைப்படுத்தலும் அல்ல. பாலத்தைக் கடக்கும் பிரேம்கள் நிறுவப்பட்ட bridge-netfilter பாதையைப் பொறுத்து ஹோஸ்டின் வடிகட்டி கொக்கிகளை இன்னும் அடையலாம், எனவே பயனுள்ள கொள்கையை ஊகிக்காமல் ஆய்வு செய்ய வேண்டும். ஒரு பிரேம் தொலைந்ததால் ஃபயர்வாலை முடக்குவது ஒரு குறிப்பிட்ட பிழையை பொதுவான பிழையுடன் மாற்றுகிறது.

பாலத்திற்கும் ஒவ்வொரு நிர்வாக அல்லது அப்லிங்க் இடைமுகத்திற்கும் இடையே IP அனுப்புதல் அணைக்கப்பட்டிருக்க வேண்டும் அல்லது வெளிப்படையாக மறுக்கப்பட வேண்டும், இது பால உறுப்பினர் நிலையிலிருந்து தனி கட்டுப்பாடு. கணினியின் ஆய்வக முகவரியை தன் கேட்வேயாகத் தேர்ந்தெடுக்கும் பலகை இதைத்தான் சோதிக்கிறது: நிர்வாக கடத்தல் வெற்றிபெற்றால், நீங்கள் நினைத்த எல்லை ஒருபோதும் இல்லை.

மேலும் இரண்டு குடும்பங்கள் தெளிவான முடிவுக்குத் தகுதியானவை. முகவரி திட்டம் பாலத்தை IPv4 மட்டுமாக மாற்றாது, எனவே IPv6 மற்றும் பிற EtherType களுக்கு அவற்றின் சொந்த திட்டம் அல்லது வடிகட்டி தேவை. மேலும் வெற்றிகரமான ping, பலகையின் கண்டுபிடிப்பு ஒளிபரப்புகள், மல்டிகாஸ்ட் குழுக்கள் அல்லது ஜம்போ பிரேம்கள் பாதையைக் கடக்குமா என்பதைப் பற்றி எதுவும் கூறாது, ஏனெனில் அவை வெவ்வேறு இயல்புநிலைகளைக் கொண்ட வெவ்வேறு டிராஃபிக் வகுப்புகள்.

இறுதியாக, போக்குவரத்தும் ரகசியத்தன்மையும் இரண்டு வெவ்வேறு கொள்முதல்கள். TAP Ethernet ஐ எடுத்துச் செல்கிறது; OpenVPN சேவை அதைச் சுற்றியுள்ள பாதுகாப்பை வழங்குகிறது. VXLAN மேலடுக்கும் Ethernet ஐ எடுத்துச் செல்கிறது மற்றும் தானாக எந்த ரகசியத்தன்மையையும் வழங்காது, எனவே ஒன்றை மற்றொன்றால் மாற்றுவது டோபாலஜி வரைபடம் ஒரே மாதிரியாகத் தோன்றினாலும் பாதுகாப்பு பண்புகளை மாற்றுகிறது.

நிலைத்தன்மை மற்றும் அதை நிரூபிக்கும் சோதனைகள்

இணைந்த பிறகு ஒருமுறை தட்டச்சு செய்யப்பட்ட கட்டளை உள்ளமைவு அல்ல. பாலம், துறை உறுப்பினர் நிலை மற்றும் ஒரே ஹோஸ்ட் முகவரியை கணினியின் தற்போதைய நெட்வொர்க் மேலாளர் மூலம் நிலைத்தன்மையாக்கி, மீண்டும் இணைவது உறுப்பினர் காணாமல் போன பாலத்தை விட்டுச் செல்லாதபடி இணைப்பை TAP சாதனத்தின் தோற்றத்துடன் பிணைக்கவும்.

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

பின்னர் பலகைகளுக்கு இரு திசைகளிலும் உண்மையில் என்ன தேவை என்பதைச் சோதிக்கவும், சுரங்கப்பாதையை மீண்டும் இணைக்கவும், அங்கீகரிக்கப்பட்ட மீட்புத் திட்டத்தின்படி ஒரு கணினியை மீண்டும் இயக்கவும். பின்னர் மூன்று விஷயங்களை உறுதிப்படுத்தவும்: நிர்வாக அணுகல் இன்னும் சுயாதீனமாக இயங்குகிறது, நகல் ஆய்வக முகவரி தோன்றவில்லை, எதிர்பாராத உற்பத்தி இடைமுகம் பாலத்தில் சேரவில்லை. அந்தக் கலவையே சோதனை அதன் பெஞ்சிற்குள் இருந்தது என்பதற்கான சான்று.