Docker கொள்கலன் VPN பின்னால் உள்ள ஹோஸ்ட்களை அடையாதது ஏன்

கார்ப்பரேட் VPN-க்குப் பின்னால் எதையும் அடையாத கொள்கலன் வழக்கமாக சுரங்கப்பாதையிலிருந்து வேறுபட்ட நெட்வொர்க் பெயர்வெளியில் வாழ்கிறது. ஹோஸ்ட் கிளையண்டின் வழிகள், DNS சேவையகங்கள் மற்றும் ஃபயர்வால் குறிகள் ஹோஸ்ட்டின் ஸ்டாக்குக்கு உரியவை; பிரிட்ஜ் நெட்வொர்க் கொள்கலனுக்கு அதன் சொந்த ஸ்டாக் உள்ளது. இந்த ஒரு உண்மையே தளக் குழுவை அடையும் பெரும்பாலான அறிக்கைகளை விளக்குகிறது, மேலும் «VPN உடைந்துள்ளது» மற்றும் «Docker VPN-ஐத் தவிர்க்கிறது» இரண்டும் ஒரே நேரத்தில் தவறாக இருக்கக்கூடும் என்பதற்கான காரணமும் இதுவே. ஒரு அறிகுறிக்குப் பின்னால் இரண்டு முற்றிலும் வேறுபட்ட அமைப்புகள் மறைந்துள்ளன, எனவே எந்த அமைப்பையும் மாற்றுவதற்கு முன் உங்களிடம் எது இருக்கிறது என்பதைக் கண்டறியுங்கள்.

சுரங்கப்பாதை யாருடைய பெயர்வெளியில் உள்ளது என்பதைக் கண்டறியுங்கள்

macOS அல்லது Windows-க்கான Docker Desktop-ல் கொள்கலன்கள் Linux மெய்நிகர் இயந்திரத்திற்குள் இயங்குகின்றன. டெஸ்க்டாப்பில் நிறுவப்பட்ட VPN கிளையண்ட் டெஸ்க்டாப் இயக்க முறைமையில் ஒரு சுரங்கப்பாதையை உருவாக்குகிறது, மெய்நிகர் இயந்திரம் அதை ஒருபோதும் பார்ப்பதில்லை. எந்த கொள்கலன் கட்டமைப்பும் அதைச் சரிசெய்யாது, ஏனெனில் கொள்கலனுக்குத் தேவையான இடைமுகம் அதன் நெட்வொர்க் பெயர்வெளியில் இல்லவே இல்லை.

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

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

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

ஹோஸ்ட் நெட்வொர்க்கிங் ஒரு சோதனை, வடிவமைப்பு அல்ல

கொள்கலனை ஹோஸ்ட் நெட்வொர்க்கிங்குடன் இயக்குவது, அதை Docker ஹோஸ்ட்டின் நெட்வொர்க் பெயர்வெளியைப் பகிர்வதாக ஆவணப்படுத்துகிறது, சுரங்கப்பாதை இடைமுகத்தையும் அதன் வழிகளையும் நேரடியாக மரபுரிமையாகப் பெறச் செய்கிறது. அதே கோரிக்கை பின்னர் வெற்றி பெற்றால், வழிக் கோட்பாடு உறுதிசெய்யப்படுகிறது, தோல்வி பெயர்வெளித் தனிமை, சான்றுகள், DNS அல்லது அணுகல் விதி அல்ல.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

இதைக் கண்டறிதலாக வைத்திருங்கள். ஹோஸ்ட் நெட்வொர்க்கிங் துறை வெளியீட்டையும் கொள்கலனிடமிருந்து நீங்கள் விரும்பிய தனிமையின் பெரும்பகுதியையும் கைவிடுகிறது, Docker Desktop-ல் «host» என்பது மெய்நிகர் இயந்திரத்தைக் குறிக்கிறது, டெஸ்க்டாப்பை அல்ல, எனவே எந்த ஹோஸ்ட்டை அணுகுகிறீர்கள் என்பதை மறந்தால் அங்குள்ள வெற்றி அல்லது தோல்வி உங்களைத் தவறாக வழிநடத்தக்கூடும்.

tun சாதனம் மற்றும் அதனுடன் வரும் சிறப்புரிமைகள்

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

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

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

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

பிரிட்ஜ் NAT VPN பார்க்கும் மூலத்தை மாற்றுகிறது

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

macvlan அல்லது ipvlan அதற்குப் பதிலாக கொள்கலனுக்கு LAN முகவரியை வழங்குகிறது, இது LAN கண்டுபிடிப்புக்கு உதவுகிறது மற்றும் கொள்கலனைப் பிரிவில் சமமானதாகக் காட்டுகிறது. இது ஹோஸ்ட்டின் சுரங்கப்பாதையையும் முழுவதுமாகத் தவிர்க்கிறது, எனவே அத்தகைய கொள்கலன் VPN-மட்டும் முன்னொட்டுகளை அடையாது, அந்த LAN-லிருந்தும் VPN அணுகக்கூடியதாக இல்லாவிட்டால்.

இரண்டு வடிவங்களும் செல்லுபடியானவை; அவை வெவ்வேறு தேவைகளுக்குப் பதிலளிக்கின்றன. தேவை «இந்தக் கொள்கலன் VPN-மட்டும் சேவையை அடைய வேண்டும்» எனில், ஹோஸ்ட் வழியாக ரூட்டிங் செய்வதற்கும் கொள்கலனுக்குள் சுரங்கப்பாதையை முடிப்பதற்கும் இடையே தேர்வு செய்கிறீர்கள். அந்தத் தேர்வைப் பயன்படுத்துவதற்கு முன் எழுதுங்கள், முதல் தோல்வியடைந்த கோரிக்கைக்குப் பிறகு அல்ல. நீங்கள் எதைத் தேர்ந்தெடுத்தாலும், தொலை முனை பார்க்கும் மூல முகவரியைப் பதிவு செய்யுங்கள், ஏனெனில் அதன் அணுகல் விதிகளும் அதன் பதிவுகளும் அதைத்தான் காட்டும். அந்த முகவரியைக் கூற முடியாத வடிவமைப்பு முழுமையடையவில்லை.

DNS டீமனைப் பின்பற்றுகிறது, சுரங்கப்பாதையை அல்ல

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

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

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

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