ஹோஸ்ட் VPN-ஐ புறக்கணிக்கும் Docker மற்றும் WSL ட்ராஃபிக்கை சரிசெய்யவும்

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

ஒரு விதியை மாற்றும் முன் மூன்று வழி அட்டவணைகளையும் ஒப்பிடுங்கள்

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

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

தீர்வானைப் பொது ஒன்றுக்கு அல்ல, சுரங்கத்திற்கு காட்டுங்கள்

ஹோஸ்ட்டில், resolvectl status ஒவ்வொரு இணைப்பிற்கும் DNS சேவையகங்களைப் பட்டியலிடுகிறது, மேலும் readlink -f /etc/resolv.conf கோப்பு systemd ஸ்டப்பா, NetworkManager கோப்பா, அல்லது ஒரு விற்பனையாளர் வாடிக்கையாளர் மீண்டும் எழுதிய ஒன்றா என்று சொல்கிறது. பயனர் வரையறுத்த பிணையத்தில் உள்ள கண்டெய்னருக்குள், /etc/resolv.conf பெயரிடுகிறது 127.0.0.11, Docker-இன் உள்ளமைந்த தீர்வானை, அது டீமன் அமைக்கப்பட்ட upstream-க்கு அனுப்புகிறது. ஆனால் இயல்புநிலை பாலத்தின் கண்டெய்னர் உருவாக்கப்பட்டபோது ஹோஸ்ட் கோப்பின் நகலைப் பெற்று அதை வைத்திருக்கிறது.

அந்த நகலே, கண்டெய்னர் தொடங்கிய பிறகு எழும் சுரங்கம் கண்டெய்னரைப் பழைய upstream-ஐக் கேட்கவைக்கும் காரணம். ஒன்று VPN தீர்வானை வெளிப்படையாக இதனுடன் அனுப்புங்கள் docker run --dns 10.8.0.53, அல்லது "dns": ["10.8.0.53"] இல் /etc/docker/daemon.json அமைத்து டீமனை மீண்டும் தொடங்குங்கள், அல்லது சுரங்கம் மேலே வந்தபின் கண்டெய்னரை மீண்டும் உருவாக்குங்கள். மீண்டும் உருவாக்குவது வழக்கமாக ஒரு மணி நேரத்திற்கு முன் சரியாக இருந்த தீர்வானை பிழைத்திருத்துவதைவிட மலிவானது.

பொது தீர்வானை வைப்பது அறிகுறியைத் தக்கவைக்கும் பழுது. அது இணையத்தைத் தீர்க்கிறது, ஆனால் ஒவ்வொரு தனியார் மண்டலத்திலும் தோல்வியடைகிறது, மேலும் சுரங்கம் எதற்காக இருக்கிறதோ அந்த வடிகட்டலை அமைதியாகத் தவிர்க்கலாம். இயங்கும் கண்டெய்னரின் /etc/resolv.conf உள்ளே எழுத முயன்றால், எதிர்பாருங்கள் Device or resource busy: Docker அந்தக் கோப்பை bind-mount செய்கிறது, எனவே திருத்தத்திற்கு முதலில் unmount தேவை. --dns உருவாக்கத்தின் போது அமைப்பதே மறுதொடக்கத்தைத் தாண்டி நிற்கும் வரிசை.

கண்டெய்னர்கள் சுரங்கத்தைக் கடன் வாங்கும்போது அனுப்பி மொழிபெயர்க்கவும்

இயல்புநிலை பாலத்துடன், ஹோஸ்ட் docker0 மற்றும் tun0 இடையேயான திசைவி, இயல்பாக அது இரண்டு வேலைகளையும் செய்யாது. அனுப்புதலை இயக்கி மூல முகவரியை மொழிபெயர்க்கவும், அதனால் பங்குதாரர் திரும்பும் வழி இல்லாத முகவரிக்குப் பதிலாக ஹோஸ்ட்டின் சுரங்க முகவரியைப் பார்க்கும் (tun0-ஐ உங்கள் வாடிக்கையாளர் இடைமுகத்திற்கு இடும் பெயரால் மாற்றுங்கள்):

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i docker0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o docker0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

FORWARD விதிகள் அனுப்பு கொள்கை DROP ஆக உள்ள ஹோஸ்ட்களில் முக்கியம். Docker தனது சொந்தச் சங்கிலிகளைச் செருகுகிறது, எனவே படிப்பதற்குப் பதிலாக ஒரு பொட்டலத்தால் சோதியுங்கள் iptables -S: கண்டெய்னரிலிருந்து, ip route get 10.8.0.20 பால நுழைவாயிலைப் பெயரிட வேண்டும், மேலும் nc -vz 10.8.0.20 443 தீர்வானில் அல்ல, சுரங்கத்தில் இணைய வேண்டும் அல்லது நேரம் முடிவடைய வேண்டும்.

MASQUERADE இல்லாமல் பங்குதாரருக்கு 172.17.0.0/16-க்கு திரும்பும் வழி தேவை, அதைப் பெரும்பாலான தொலை அணுகல் VPN தள்ளாது. இங்கேயே கொள்கை அடிப்படையிலான வாடிக்கையாளர் திட்டத்தை உடைக்கிறது: அது குறிப்பிட்ட UID அல்லது cgroups-இன் ட்ராஃபிக்கை மட்டும் பிடித்தால், உங்கள் அனுப்பு விதிகள் சுரங்கத்திற்குள் பொட்டலத்தை ஒருபோதும் பார்க்காது, திருத்தம் iptables-இல் அல்ல, வாடிக்கையாளரின் வழியமைப்பு கொள்கையில் உள்ளது. கையால் சேர்க்கப்பட்ட விதிகள் மறுதொடக்கத்தில் மறைந்துவிடும், எனவே அவற்றை systemd அலகு அல்லது netfilter-persistent அட்டவணையில் வைத்து மறுதொடக்கத்திற்குப் பிறகு மீண்டும் சோதியுங்கள், ஏனெனில் தாமதமாக எழும் சுரங்கம் அவற்றை அடித்துச் செல்லலாம்.

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

ஒரு கண்டெய்னர் ஒரு குறிப்பிட்ட முனையம் வழியாக வெளியேற வேண்டும் என்றால், அந்தக் கண்டெய்னரில் வாடிக்கையாளரை இயக்குங்கள். அதற்கு --cap-add NET_ADMIN மற்றும் --device /dev/net/tun தேவை, பின்னர் அதற்கு சொந்த tun0, வழிகள் மற்றும் தீச்சுவர் உள்ளன. மற்ற கண்டெய்னர்கள் அதன் வழியாகச் சென்றால், கண்டெய்னருக்குள் அனுப்புதலும் MASQUERADE விதியும் தேவை, அந்தப் பங்குதாரர்களுக்கு அதை நோக்கிக் காட்டும் வெளிப்படையான வழி அல்லது ப்ராக்ஸி தேவை; Docker-இன் இயல்புநிலை பாலம் அந்த வழியை உங்களுக்காகச் சேர்க்காது.

ஹோஸ்ட் பிணையம், docker run --network host, மலிவான பதிப்பு: கண்டெய்னர் ஹோஸ்ட்டின் பெயரிடத்தில் சேர்ந்து சுரங்க வழிகளை நேரடியாகப் பார்க்கிறது. அது பிணையத் தனிமைப்படுத்தலையும் கைவிடுகிறது, துறைமுக மோதல்களை அழைக்கிறது, நடைமுறையில் இது Linux விருப்பம். வெளியிடப்பட்ட துறைமுகம் அதற்கு மாற்று அல்ல. -p 8080:80 ஒரு சேவையை ஹோஸ்ட்டிலிருந்து அணுகக்கூடியதாக்குகிறது; உள் 10.x முகவரிகளைக் கண்டெய்னருக்குள்ளிருந்து அணுகக்கூடியதாக்காது, இரண்டையும் கலப்பதே வழியமைப்புப் பிரச்சினை வெளிப்பட்ட தரவுத்தளத் துறைமுகமாக மாறும் வழி.

பெயர் தோல்வியை ஒன்றுடன் ஒன்று மேலிடும் துணைப்பிணையத்திலிருந்து வேறுபடுத்துங்கள்

Docker-இன் இயல்புநிலை பாலம் 172.17.0.0/16, மேலும் பல நிறுவன VPN குளங்கள் 172.16.0.0/12-க்குள் உள்ளன. சுரங்கம் அந்த வீச்சைக் கொண்டவுடன், கண்டெய்னருக்கு உரிய ட்ராஃபிக் அதற்குப் பதிலாக சுரங்கத்திற்குள் வழியமைக்கப்படலாம். பெயர்கள் தோல்வியடைகின்றன, பிழை DNS போலத் தெரிகிறது, பிரச்சினை முகவரிகளில் உள்ளது. சேரிடத்தைச் சரிபாருங்கள், தீர்வானை அல்ல: ip route get 172.17.0.5 ஹோஸ்ட்டில், பின்னர் பால முன்னொட்டை VPN குளம் மற்றும் docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}' உடன் ஒப்பிடுங்கள்.

பழுது என்பது வீச்சுகளில் ஒன்றை நகர்த்துவது: ஒன்று daemon.json இல் Docker-க்கான வேறு இயல்புநிலை முகவரிக் குளம், அல்லது செறிவூட்டியில் வேறு குளம். இங்கே மற்றொரு பெயர் சேவையகத்தைச் சேர்ப்பது எதையும் செய்யாது, ssh -b உம் செய்யாது: வாடிக்கையாளரை இடைமுகத்தில் பிணைப்பது மூல முகவரியை மாற்றுகிறது, சுரங்கத்திற்குள் செல்லும் சேரிட வழியை அல்ல. விரைவான வேலைப்பங்கீடு: ஹோஸ்ட்டில் தீர்க்கப்படும் ஆனால் கண்டெய்னரில் தீர்க்கப்படாத பெயர் தீர்வான் பிரச்சினை, கண்டெய்னரில் தொங்கும் ஆனால் ஹோஸ்ட்டில் வேலை செய்யும் நேரடி IP இணைப்பு வழி அல்லது அனுப்பு சங்கிலிப் பிரச்சினை.

WSL மற்றும் Docker Desktop Linux விதிகளைப் பின்பற்றுவதில்லை

அதன் இயல்புநிலை NAT பயன்முறையில், WSL தனது சொந்த மெய்நிகர் தகவமைப்புக்குப் பின்னால் அமர்ந்து Windows VPN-இன் உள் வழிகளையோ DNS பின்னொட்டுகளையோ பெறாது, அதனால்தான் உலாவி வேலை செய்கிறது, ping விநியோகத்திற்குள் செய்யவில்லை. சமீபத்திய Windows 11 கட்டமைப்புகளில் கிடைக்கும் கண்ணாடிப் பிணையம் அதற்குப் பதிலாக ஹோஸ்ட் இடைமுகங்களைப் பகிர்கிறது, ஆனால் அதை .wslconfig இல் இயக்கி விநியோகத்தை wsl --shutdown மூலம் மீண்டும் தொடங்க வேண்டும். செயலில் உள்ள பயன்முறையை wslinfo --networking-mode மூலம் உறுதிசெய்யுங்கள், பழுதைப் பயன்படுத்தும் முன், ஏனெனில் NAT-இன் பதில் கண்ணாடிப் பயன்முறைக்குத் தவறு, திருப்பியும் அப்படியே.

Docker Desktop மற்றொரு அடுக்கைச் சேர்க்கிறது. Windows-இல் Linux கண்டெய்னர்கள் வரலாற்றில் vpnkit என அழைக்கப்படும் NAT செயலாக்கத்திற்குப் பின்னால் அமர்கின்றன, அவற்றின் பாதை இயல்பான Linux ஹோஸ்ட்டிலிருந்து வேறுபடுகிறது. Windows கண்டெய்னர்கள் Hyper-V மெய்நிகர் சுவிட்ச் வழியாக இணைகின்றன, நிறுவன வாடிக்கையாளர் அந்தச் சுவிட்சிலிருந்து வரும் ட்ராஃபிக்கைத் தடுக்கலாம், எனவே ஒரே இயந்திரத்தில் உள்ள Linux கண்டெய்னர்கள் பிணையத்தை அடையலாம், ஆனால் Windows கண்டெய்னர்களுக்கு எதுவும் இல்லை. இயற்பியல் தகவமைப்புடன் பிணைக்கப்பட்ட வெளிப்புற சுவிட்ச் வழக்கமான தீர்வு, அது கண்டெய்னரின் பிணைய அடையாளத்தைக் கொள்கை அனுமதிக்காத வழிகளில் மாற்றுகிறது.

மற்றொரு விதியை எழுதும் முன், நான்கு அடுக்குகளையும் வரிசையாகச் சென்று அவற்றில் ஒன்று தவறாக இருக்கும் இடத்தில் நிறுத்துங்கள்:

• கண்டெய்னருக்குள்: ip route தனியார் முன்னொட்டை அடைகிறதா, மேலும் /etc/resolv.conf அதைத் தீர்க்கும் upstream-ஐப் பெயரிடுகிறதா?
• ஹோஸ்ட்டில்: அனுப்புதல் இயக்கத்தில் உள்ளதா, NAT சுரங்க இடைமுகத்தில் பிணைக்கப்பட்டுள்ளதா, அனுப்பு சங்கிலி பாலத்திலிருந்து சுரங்கத்தை ஏற்கிறதா?
• பங்குதாரரிடம்: திரும்பும் பாதை தெரியுமா, அல்லது கண்டெய்னர் துணைப்பிணையத்தை மறைக்க NAT-ஐ நம்புகிறீர்களா?
• தளத்தில்: WSL NAT அல்லது கண்ணாடிப் பயன்முறையில் உள்ளதா, கண்டெய்னர் Linux அல்லது Windows?

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