Docker கொள்கலன் போக்குவரத்து ஹோஸ்ட் VPN-ஐத் தவிர்க்கிறது: எவ்வாறு சரிபார்ப்பது
ஹோஸ்ட் VPN ஹோஸ்டின் பிணைய பெயர்வெளியை மட்டுமே உள்ளடக்குகிறது. பாலத்தில் உள்ள கொள்கலன் போக்குவரத்து சுரங்கத்திற்குள் நுழைகிறதா அல்லது நேரடியாக வெளியேறுகிறதா என்பதை இந்த சரிபார்ப்புகள் மூலம் அறியுங்கள்.
ஹோஸ்டில் உங்கள் உலாவி VPN-இன் வெளியேறும் முகவரியைக் காட்டுகிறது, கொள்கலன் உங்கள் வீட்டு இணைப்பைத் தெரிவிக்கிறது, யாரோ அதைக் கசிவு என்று அழைக்கிறார். எதுவும் கசியவில்லை. ஹோஸ்ட் சுரங்கம் என்பது ஹோஸ்டின் பிணைய பெயர்வெளிக்குச் சொந்தமான இடைமுகங்கள், பாதைகள் மற்றும் விதிகளின் தொகுப்பு, பாலத்தில் உள்ள கொள்கலன் அதன் சொந்த இயல்புநிலை பாதையுடன் கூடிய மற்றொரு பெயர்வெளி. VPN வாடிக்கையாளர் வாரக்கணக்கில் இணைக்கப்பட்டிருந்தும் ஒரு கொள்கலன் பொதி கூட ஒருபோதும் அதற்குள் நுழையாத Compose அடுக்கில் நான் அமர்ந்திருக்கிறேன்.
தட்டு சின்னத்திற்கு முன் பெயர்வெளியைச் சரிபார்க்கவும்
பெயர்வெளிகளே முழு வாதம். Docker ஒரு பால பிணையத்தில் கொள்கலனைத் தொடங்கும்போது, அது ஒரு பிணைய பெயர்வெளியை உருவாக்கி, veth இணையின் ஒரு முனையை அதற்குள் இணைத்து, அந்த பெயர்வெளிக்கு ஒரு முகவரியையும் இயல்புநிலை பாதையையும் தருகிறது. சுரங்கத்தின் இடைமுகம், எந்தப் பெயரால் அழைக்கப்பட்டாலும், ஹோஸ்டின் பெயர்வெளியில் வாழ்கிறது. கொள்கலனுக்குள் உள்ள போக்குவரத்து அதைப் பார்க்க முடியாது, வெளியிலிருந்து எந்த வாடிக்கையாளர் அமைப்பும் அதை மாற்றாது.
தனிமைப்படுத்தலில் இருந்து வெளியேற இரண்டு ஆதரவு நடவடிக்கைகள் உள்ளன. --network host கொள்கலனை ஹோஸ்டின் பெயர்வெளிக்குள் வைக்கிறது, எனவே அது ஹோஸ்டின் பாதைகளையும் அதன் மூலம் சுரங்கத்தையும் மரபுரிமையாகப் பெறுகிறது. --network container:vpn மற்றொரு கொள்கலனின் பெயர்வெளியைப் பகிர்கிறது, பெரும்பாலான பக்க-கொள்கலன் வடிவமைப்புகள் பணிச்சுமையை VPN கொள்கலன் வழியாக அனுப்புவது இப்படித்தான். இரண்டும் வெளிப்படையான தேர்வுகள்; பொதுவாக அவற்றில் ஒன்று மட்டுமே பயன்படுத்துபவர் கருதியதாக இருக்கும்.
ஹோஸ்ட் பயன்முறை இலவச மேம்பாடு அல்ல. கொள்கலன் தனது சொந்த முகவரியைக் கொண்டிருக்காமல் போகிறது, துறைமுக வெளியீடு பொருந்தாது, அங்கு NET_ADMIN வைத்திருக்கும் செயல்முறை ஹோஸ்டின் வழித்தடத்தை மீண்டும் எழுதலாம். அதை ஏற்பது சரியான முடிவாக இருக்கலாம். ஏற்கனவே இயக்கத்தில் உள்ளது என்று கருதுவதே, பாதையில் ஒருபோதும் இல்லாத சுரங்கத்தை ஒரு மாலை முழுவதும் பிழைதிருத்தம் செய்யக் காரணம்.
பொதியைப் பாலத்திலிருந்து வெளியே பின்தொடரவும்
பால கொள்கலன் அதன் பொதியை அதன் இயல்புநிலை நுழைவாயிலுக்கு அனுப்புகிறது, அது ஹோஸ்டில் உள்ள பால இடைமுகம். பின்னர் ஹோஸ்ட் பொதியை அனுப்பி, இயல்புநிலை கட்டமைப்பில் பொதி வெளியேறும் முன் மூல முகவரியை தனது முகவரியாக மொழிபெயர்க்கிறது. அந்த மொழிபெயர்ப்பு படியே கொள்கையை அமைதியாக வீழ்த்துகிறது.
பொதி சுரங்கத்தின் இறுதி முனையை அடையும்போது ஹோஸ்டின் முகவரியைக் கொண்டுள்ளது. கொள்கலனின் அசல் முகவரியை அடிப்படையாகக் கொண்ட எந்த விதி, கொள்கை பாதை அல்லது பிளவு சுரங்க முடிவும் பொருந்தாமல் போகிறது, வெவ்வேறு வெளியேற்றங்கள் வழியாக வெளியேற வேண்டிய இரண்டு கொள்கலன்களை மூலத்தால் மட்டும் வேறுபடுத்த முடியாது. ஒவ்வொரு கொள்கலனுக்கும் வழித்தடம் தேவைப்பட்டால், முடிவு மொழிபெயர்ப்புக்கு முன் அல்லது நீங்கள் கட்டுப்படுத்தும் பெயர்வெளிக்குள் எடுக்கப்பட வேண்டும்.
Docker இந்த விதிகளைத் தானே பராமரிக்கிறது, டீமன் எந்த தீர்வரிசை பின்தளத்துடன் கட்டமைக்கப்பட்டதோ அதன் மூலம். அனுப்பப்படும் போக்குவரத்திற்கான ஆதரவு கொக்கிக்கு வெளியே கையால் எழுதப்பட்ட விதிகள், DOCKER-USER, டீமன் மீண்டும் தொடங்கும்போது அல்லது ஹோஸ்ட் மேம்படுத்தப்படும்போது மறுவரிசைப்படுத்தப்படலாம் அல்லது நீக்கப்படலாம். பொதி வடிகட்டுதல் பற்றிய Docker ஆவணம் சங்கிலிகளின் வரிசையைக் காட்டுகிறது; நடைமுறை விஷயம் என்னவென்றால், ஒவ்வொரு விதிக்கும் ஒரு உரிமையாளரும் நீங்கள் உண்மையில் சோதித்த மீள்ஏற்று பாதையும் தேவை.
இரண்டு அமைப்புகளையும் தனித்தனியாகச் சோதிக்கவும்
ஒரு பெயர்வெளியின் சான்று மற்றொன்றைப் பற்றி எதுவும் கூறாது. VPN கொள்கலனுக்குள் இயக்கப்பட்ட கோரிக்கை அந்த கொள்கலனுக்கு சுரங்கம் செயல்படுகிறது என்பதை நிரூபிக்கிறது. அது ஹோஸ்டைப் பற்றிய சான்று அல்ல, --network host கொள்கலனில் இருந்து இயக்கப்பட்ட அதே கட்டளை பாலத்தைப் பற்றிய சான்று அல்ல.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'பின்னர் சோதனையை ஒத்த படிமத்தில் அல்ல, உண்மையான பயன்பாட்டு கொள்கலனுக்குள் மீண்டும் செய்யவும். பயன்பாட்டில் கூடுதல் பாதை, ப்ராக்ஸி சூழல் மாறி அல்லது வேறு தீர்வி இருக்கலாம், அவற்றில் ஒவ்வொன்றும் பதிலை மாற்றுகிறது. ஒவ்வொரு முறையும் பெயர் தீர்வு மற்றும் இரண்டாவது முகவரி குடும்பத்தைச் சரிபார்க்கவும்: பயனர் வரையறுத்த பாலங்களில் உள்ள கொள்கலன்கள் Docker-இன் உள்ளமைந்த தீர்வி மூலம் 127.0.0.11 இல் தீர்க்கப்படுகின்றன, பாலத்தில் உள்ள IPv6 இயல்புநிலை பாதை நீங்கள் IPv4 மட்டும் சுரங்கத்தைச் சோதிப்பதில் மும்முரமாக இருக்கும்போது போக்குவரத்தை வெளியே எடுத்துச் செல்லலாம்.
சான்றுகளைத் தொடுவதற்கு முன் வடிவமைப்பைப் படியுங்கள்
ஹோஸ்ட் வேலை செய்து கொள்கலன் செயல்படாதபோது, காரணம் எப்போதும் கட்டமைப்புசார்ந்ததாகவே இருக்கும், விசைகளைச் சுழற்றுவது அல்லது வாடிக்கையாளரை மீண்டும் நிறுவுவது ஒரு பிற்பகலை வீணாக்குகிறது. முதலில் அறிகுறியை வகைப்படுத்துங்கள், திருத்தம் பொதுவாக தன்னைத்தானே பெயரிடும்.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
மேலிடல் வரிக்கு அதன் சொந்த வாக்கியம் தகும். 172.17.0.0/16 க்கு, அல்லது உங்கள் பால முன்னொட்டை தற்செயலாகக் கொண்ட 10.0.0.0/8 க்கு பாதையைத் தள்ளும் VPN விவரக்குறிப்பு சுரங்கத்தை கொள்கலன் துணைப்பிணையத்திற்கு உரிமை கோரச் செய்கிறது, மொழிபெயர்க்கப்பட்ட முகவரிகளுக்கான பதில்கள் தவறான திசையில் செல்லும் அல்லது மறைந்துவிடும். Docker பிணையத்தை மறுஎண்ணிடுவது பொதுவாக விதிவிலக்குகளைக் குவிப்பதை விட சுத்தமானது.
பரப்பளவை வெளிப்படையாக்கி, பின்னர் வேண்டுமென்றே உடையுங்கள்
இரண்டு வடிவமைப்புகள் மறுஆய்வில் நிலைத்திருக்கின்றன. VPN கொள்கலனின் பெயர்வெளியைப் பகிருங்கள், உள்ளடக்கப்பட்ட ஒவ்வொரு பணிச்சுமையும் ஒரு மறுதொடக்கம் எல்லையுடன் ஒரு சுரங்கத்தைப் பயன்படுத்துகிறது, ஒரு சேவைக்கு வேறு வெளியேற்றம் அல்லது அதன் சொந்த DNS பாதை தேவைப்படும் வரை இது எளிது. அல்லது கொள்கலன் பிணையத்தை ஹோஸ்டில் உள்ள VPN நுழைவாயிலுக்கு வழித்தடம் செய்யுங்கள்: அனுப்புதல் இயக்கப்பட்டது, பால முன்னொட்டு சுரங்கத்தை நோக்கி, திரும்பும் போக்குவரத்து வெளிப்படையாகக் கையாளப்பட்டது. அது ஒவ்வொரு பிணையத்திற்கும் கட்டுப்பாட்டை வாங்குகிறது, டீமன் மற்றும் வாடிக்கையாளர் மேம்பாடுகள் முழுவதும் பராமரிக்க வேண்டிய விதித்தொகுப்பை உங்களுக்கு செலவாக்குகிறது.
எப்படியிருந்தாலும், முக்கியமான சோதனை தோல்வி நிலை. கொள்கலன் கோரிக்கை காற்றில் இருக்கும்போது சுரங்கத்தை நிறுத்தி பொதி எங்கு செல்கிறது என்பதைப் பாருங்கள். அது நேரடி பாதைக்குத் திரும்பினால், பரப்பளவு ஒருபோதும் அமல்படுத்தப்படவில்லை, ஏனெனில் வாடிக்கையாளரின் kill switch வாடிக்கையாளரின் சொந்த போக்குவரத்தைக் கட்டுப்படுத்துகிறது, பாலத்திலிருந்து அனுப்பப்படும் பொதிகளை அல்ல. பின்னர் டீமன் மற்றும் ஹோஸ்டை மீண்டும் தொடங்கி முடிவை இரண்டாவது முறையாக உறுதிப்படுத்துங்கள்; கையால் எழுதப்பட்ட விதிகள் மறையும் தருணம் அதுவே.
அதை முடிந்தது என்று சொல்வதற்கு முன் நான்கு விஷயங்களை உறுதிப்படுத்துங்கள்: சுரங்க இடைமுகம் போக்குவரத்தின் அதே பெயர்வெளியில் உள்ளது, கொள்கலன் சோதனை உண்மையான கொள்கலனுக்குள் நடந்தது, பெயர் தீர்வு மற்றும் இரண்டு முகவரி குடும்பங்களும் சரிபார்க்கப்பட்டன, சுரங்க தோல்வி சோதனை இன்னும் மூடிய நிலையில் தோல்வியடைகிறது. பின்னர் தீர்வரிசை பின்தளம், வாடிக்கையாளர் பதிப்பு மற்றும் ஒவ்வொரு விதியின் உரிமையாளரை எழுதுங்கள். அந்தப் பதிவே அடுத்த மேம்பாடு பழைய அனுமானங்களின் ஆவணப்படுத்தப்படாத கலவையை விட்டுச் செல்வதைத் தடுக்கிறது.