macvlan கொள்கலன் VPN வாடிக்கையாளருக்கு பதிலளிக்க முடியாதது ஏன்

VPN ஒன்றை முடித்து அதே நேரத்தில் macvlan வலையமைப்பில் கொள்கலனை இயக்கும் Linux புரவலனை கற்பனை செய்யுங்கள். LAN 192.168.60.0/24 ஆகும், கொள்கலனிடம் 192.168.60.210 உள்ளது, VPN வாடிக்கையாளர்கள் 10.95.0.0/24 இலிருந்து வருகிறார்கள். வாடிக்கையாளர் சேவையை அடைகிறார், பதில் ஒருபோதும் திரும்பி வருவதில்லை, புரவலனில் உள்ள ஒவ்வொரு ஃபயர்வால் விதியும் சரியாகத் தெரிகிறது. இந்த அறிகுறியை இரண்டு தனித்தனி கட்டுப்பாடுகள் உருவாக்குகின்றன, ஒன்றைச் சரிசெய்தால் மற்றொன்று அதன் இடத்திலேயே இருக்கும்.

இரண்டு கட்டுப்பாடுகள், ஒரு அறிகுறி

முதல் கட்டுப்பாடு தனிமைப்படுத்தல்: Docker இன் macvlan இயக்கி கொள்கலனை பெற்றோர் இடைமுகம் வழியாக அதன் சொந்த புரவலனுடன் பேச அனுமதிக்காது. புரவலன் ஸ்டாக்கிற்கும் கொள்கலனுக்கும் இடையே போக்குவரத்திற்கு வழி இல்லை, புரவலனில் உள்ள வழிகள் எப்படி எழுதப்பட்டிருந்தாலும்.

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

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

புரவலன் பக்க shim ஐ குறுகலாக உருவாக்குங்கள்

அதே பெற்றோருடன் பாலம் பயன்முறையில் இணைக்கப்பட்ட இரண்டாவது macvlan இடைமுகம் புரவலன் ஸ்டாக்கிற்கு அந்த LAN பகுதியில் அதன் சொந்த அடையாளத்தை அளிக்கிறது. அதற்கு DHCP குளத்திற்கு வெளியேயும் கொள்கலன் வரம்பிற்கு வெளியேயும் முகவரியை ஒதுக்கி வைத்து, கொள்கலனை மட்டும் அதன் வழியாக அனுப்புங்கள்.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

முதல் கட்டளை இடைமுகத்தை பாலம் பயன்முறையில் உருவாக்குகிறது, இது இந்த இயக்கிக்கான ஆவணப்படுத்தப்பட்ட இயல்புநிலை மற்றும் புரவலன்-கொள்கலன் போக்குவரத்திற்கு நீங்கள் விரும்பும் பயன்முறை. இரண்டாவது /32 ஐ ஒதுக்குகிறது, முகவரி LAN முன்னொட்டுடன் மோதாமல் இருக்க, நான்காவது shim வழியாக கொள்கலனின் முகவரியை மட்டும் அனுப்புகிறது.

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

இந்த கட்டளைகள் இயங்கும் புரவலனில் வலையமைப்பு அமைப்புகளை மாற்றுகின்றன. சாதனம் அல்லது நிர்வகிக்கப்பட்ட தளத்தில் அந்த தளம் ஆதரிக்கும் உள்ளமைவு முறையைப் பயன்படுத்துங்கள், ஏனெனில் root-shell இல் செய்யப்படும் ஊடாடும் மாற்றம் மேம்பாட்டிற்குப் பிறகு நீடிக்காமல் போகலாம்.

மூலம் எவ்வாறு பாதுகாக்கப்படுகிறது என்பதை முடிவு செய்யுங்கள்

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

அது செயல்பட, கொள்கலனின் வலையமைப்பு உள்ளமைவு இந்த வழிக்கு 10.95.0.0/24 இன் போக்குவரத்தை 192.168.60.250 க்கு அதன் நுழைவாயிலாக அனுப்ப வேண்டும். இது கொள்கலனின் சொந்த உள்ளமைவுக்குள் ஆதரிக்கப்படும் வழி அல்லது நுழைவாயில் அமைப்பு, புரவலன் பக்க தந்திரம் அல்ல. அமைப்பு நடைமுறைக்கு வந்துவிட்டது என கருதாமல் கொள்கலனின் உள்ளேயிருந்து அதை உறுதிப்படுத்துங்கள். இன்னும் LAN திசைவியை நோக்கியிருக்கும் இயல்புநிலை நுழைவாயில் பதில்களை அதே துளைக்கே தொடர்ந்து அனுப்பும்.

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

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

shim ஐ வெளியேறும் இடைமுகமாகப் பொருத்துங்கள், சுரங்கப்பாதையாக அல்ல. சுரங்கப்பாதையை வெளியேறும் இடைமுகம் எனக் கூறும் விதி கொள்கலனை நோக்கிச் செல்லும் பொட்டலத்துடன் பொருந்தாது, இந்த வகை அமைப்பில் பொதுவாக இருக்கும் தவறு அதுவே. விதியை மேலே உள்ள வாக்கியம் அளவுக்கு குறுகலாக வைத்திருந்து, குளம் மாறும்போது அதை மறுபரிசீலனை செய்யுங்கள்.

வாடிக்கையாளரிடமிருந்து சரிபாருங்கள், புரவலனிடமிருந்து அல்ல

புரவலனிலிருந்தே shim முகவரியில் பிணைக்கப்பட்ட கோரிக்கை shim கொள்கலனை அடைய முடியும் என்பதை நிரூபிக்கிறது. ஆனால் கொள்கலன் பாதுகாக்கப்பட்ட 10.95.0.x மூலத்திற்குப் போக்குவரத்தைத் திருப்பி அனுப்ப முடியும் என்பதை நிரூபிக்கவில்லை, ஏனெனில் அந்த சோதனையில் மூல முகவரி shim இனுடையதே.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

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

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

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