VPN மூலம் Docker கொள்கலனை அணுக முடியவில்லையா? துணை வலைகளை ஒப்பிடுங்கள்
Docker வழங்கும் துணை வலையை VPN-ம் கோருகிறது. இரண்டு முகவரித் திட்டங்களையும் ஒப்பிட்டு, மீண்டும் இணைந்த பிறகும் நிலைத்திருக்கும் திருத்தத்தைத் தேர்ந்தெடுங்கள்.
கொள்கலன்கள் அலுவலக LAN-இல் பதிலளிக்கின்றன, ஆனால் நிறுவன VPN இணையும் அந்தக் கணமே பதிலளிப்பதை நிறுத்துகின்றன. கொள்கலனில் எதுவும் மாறவில்லை: மறுதொடக்கம் இல்லை, படச் செயல்புதுப்பிப்பு இல்லை, உள்ளமைப்புத் திருத்தம் இல்லை. மாறியது ஹோஸ்ட்டின் வழிசெலுத்தல் அட்டவணை; அதில் சுரங்கப்பாதை சேர்த்த ஒரு வழி இப்போது Docker வழங்கிய முகவரியை மூடுகிறது. ஒரு துணை வலையைத் திருத்தும் முன்னோ VPN விலக்கைக் கேட்கும் முன்னோ இரண்டு முகவரித் திட்டங்களையும் அருகருகே வையுங்கள், ஏனெனில் ஒவ்வொரு திருத்தமும் மிக வேறுபட்ட நேரத்தை எடுக்கும்.
உள்ளமைப்பை மாற்றும் முன் வழியைப் படியுங்கள்
Docker உண்மையில் கட்டிய வலையிலிருந்து தொடங்குங்கள். IPAM தொகுதி முகவரித் திட்டம், துணை வலை என்பது முக்கியமான வரி:
docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]Compose இயல்பாகவே ஒவ்வொரு புதிய திட்டத்திற்கும் /16 ஒதுக்குகிறது, எனவே இரண்டு சேவைகள் 65,536 முகவரிகளின் வரம்பிற்குள் இருக்க முடியும். இந்த அகலமே ஒன்றுடன் ஒன்று மேற்படிதல் பொதுவாக இருப்பதற்குக் காரணம்: சீரற்ற முறையில் தேர்ந்தெடுக்கப்பட்ட /16, சுரங்கப்பாதை வழியாக நீங்கள் அடையும் தளத்தை விழுங்கும் அளவுக்குப் பெரியது, சுரங்கப்பாதை உயரும் வரை யாரும் கவனிப்பதில்லை.
பிறகு ஒரு கொள்கலன் முகவரிக்கான வழித் தேர்வை ஒப்பிடுங்கள் — ஒருமுறை சுரங்கப்பாதை மூடியிருக்கும்போது, ஒருமுறை அது திறந்திருக்கும்போது:
ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1இரு வகையான பதில்கள் வெவ்வேறு இடங்களுக்கு இட்டுச் செல்கின்றன. வெளியீடு tun0, wg0 அல்லது வேறு சுரங்கப்பாதை சாதனத்தைக் குறிப்பிட்டால், VPN முன்னொட்டு பாலம் வழியைப் போலவே குறைந்தது அளவுக்குக் குறிப்பிட்டதாக இருக்கும், மேலும் பாக்கெட் ஒருபோதும் கொள்கலனை அடையாது. அது இன்னும் பாலத்தைக் குறிப்பிட்டால், ஹோஸ்ட் கொள்கலனை அடைய முடியும், உங்கள் தவறு வடிகட்டுதல், DNS அல்லது ஒரு திசையில் மட்டும் தோல்வியடையும் திரும்பும் பாதை.
/16 மோதலை எளிதாக அடைவது ஏன்
Docker தனியார் குளங்களிலிருந்து பாலம் வலைகளை எடுக்கிறது, இயல்புநிலை குளம் 172.16.0.0/12 தொகுதியிலிருந்து /16 துண்டுகளாக வருகிறது. நிறுவன வலைகள் பெரும்பாலும் அதே தனியார் இடத்தைப் பயன்படுத்துகின்றன, தொலை அணுகல் VPN அந்த முன்னொட்டுகளை இணையும் ஒவ்வொரு வாடிக்கையாளருக்கும் தள்ளுகிறது. இரு பக்கமும் 172.18.0.0/16 தங்களுக்குச் சொந்தம் என்று நம்பும்போது, ஒரு வழிசெலுத்தல் அட்டவணையில் இரண்டு முரணான உரிமைகோரல்கள் இருக்கும்.
வெற்றியாளரை முன்னொட்டின் நீளம் தீர்மானிக்கிறது, வழிகளின் வரிசை அல்ல. 10.0.0.0/8 தள்ளும் சுரங்கப்பாதை 172.18.0.0/16 பாலம் வழியை வெல்லாது, ஏனெனில் /8 குறைவான குறிப்பிட்டது. 172.18.0.0/16 அல்லது அதற்குள் இருக்கும் 172.18.5.0/24 தள்ளும் சுரங்கப்பாதை வெல்லும். அதனால்தான் ஒரு மடிக்கணினி அலுவலக வலையில் வேலை செய்து அதே VPN-உடன் ஹோட்டல் Wi-Fi-இல் தோல்வியடைகிறது: வாடிக்கையாளர் வெவ்வேறு முன்னொட்டுகளைப் பெறுகிறார்.
அதே அட்டவணை எதிர் திசையையும் நிர்வகிக்கிறது. 10.8.4.20-இல் உள் ஹோஸ்ட் தேவைப்படும் கொள்கலன் பாக்கெட்டை அதன் பாலம் நுழைவாயிலுக்கு அனுப்புகிறது, பிறகு ஹோஸ்ட் அதை சுரங்கப்பாதைக்குள் வழிசெலுத்துகிறது. ஹோஸ்ட் NAT செய்வதால் அந்தப் பாதை பொதுவாக வேலை செய்கிறது, ஆனால் நிறுவனப் பக்கம் மடிக்கணினியின் VPN முகவரியை மட்டும் ஏற்றுக்கொள்ளும்போது, அல்லது திரும்பும் பாதை வடிகட்டுதல் சமச்சீரற்ற பதிலை வீழ்த்தும்போது அது தோல்வியடைகிறது.
மூன்று திருத்தங்களை ஒப்பிடுங்கள்
வெளியேற மூன்று வழிகள் மட்டுமே உள்ளன, அவை யார் அனுமதிக்க வேண்டும், ஒன்றைப் பயன்படுத்தும்போது என்ன உடையும் என்பதில் வேறுபடுகின்றன.
| Repair | Who owns it | What it costs |
|---|---|---|
| Renumber the container network | You | Recreates the network, restarts services, invalidates literal addresses in configs and scripts |
| Exclude your range from the tunnel | Network team | Changes what every laptop sees, needs a change request and a client profile update |
| Reach the service through a published port | You and the client | One port only, no direct container-to-container routing across the tunnel |
டிக்கெட் இல்லாமல் முடிக்கக்கூடிய ஒரே திருத்தம் மறுஎண்ணிடல், அதனால்தான் பெரும்பாலான கட்டுரைகள் அங்கேயே நிற்கின்றன. புதிய திட்டத்தில் இது மலிவு, ஆனால் இடம்பெயர்வுக் கருவி அல்லது சேமிக்கப்பட்ட இணைப்பு சரம் நேரடி முகவரியைச் சுட்டிக்காட்டத் தொடங்கியதும் விலை உயர்ந்ததாகிறது. YAML திருத்தும் முன் அந்தக் குறிப்புகளை எண்ணுங்கள், பிறகு அல்ல.
ஒன்றுடன் ஒன்று மேற்படிதல் உங்கள் நிறுவனம் உண்மையில் சொந்தமான வரம்பில் இருக்கும்போது சுரங்கப்பாதையிலிருந்து விலக்கு என்பது மிகத் தெளிவான பதில். அதுவே மிக மெதுவானதும், வாடிக்கையாளர் சுயவிவரத்தை மாற்ற முடியாத ஒப்பந்தக்காரருக்கு பயனற்றதும். வெளியிடப்பட்ட துறைமுகம் அல்லது சிறிய தலைகீழ் ப்ராக்சி இந்த வாதத்தைத் தவிர்க்கிறது: சுரங்கப்பாதை ஏற்கனவே சரியாக வழிசெலுத்தும் முகவரியுடன் வாடிக்கையாளர் பேசுகிறார், அந்தத் துறைமுகம் மட்டுமே அணுகக்கூடியதாக இருக்க வேண்டும்.
வேண்டுமென்றே ஒரு வரம்பை நிர்ணயியுங்கள்
ஒரு திட்டத்திற்கு, திட்டம் பகிரப்பட்ட குளத்திலிருந்து எடுப்பதை நிறுத்த compose கோப்பில் துணை வலையை அறிவிக்கவும்:
networks:
default:
ipam:
config:
- subnet: 10.201.7.0/24அந்த வரம்பை நீங்கள் தேடும்போது கண்ட உதாரணத்திலிருந்து அல்ல, உங்கள் குழு பராமரிக்கும் பதிவேட்டிலிருந்து எடுங்கள். VPN தள்ளும் முன்னொட்டுகள், மக்கள் வேலை செய்யும் வீட்டு LAN-கள், அதே ஹோஸ்ட்டில் உள்ள பிற கொள்கலன் வலைகள் ஆகியவற்றுடன் அதைச் சரிபார்க்கவும். பிறகு மறுகட்டமைப்பைத் திட்டமிடுங்கள், ஏனெனில் இருக்கும் வலை தன் பழைய துணை வலையைத் தக்கவைத்துக்கொள்ளும்: docker compose down, பிறகு up -d. இறுதிப்புள்ளிகள் இணைக்கப்பட்டிருக்கும்போது docker network rm மறுக்கும், கோப்பில் உள்ள எந்த ipv4_address பதிவும் புதிய வரம்பிற்குள் இருக்க வேண்டும்.
Docker தானே உருவாக்கும் வலைகளுக்கு, /etc/docker/daemon.json-இல் டீமன் குளத்தை அமைக்கவும்:
{
"default-address-pools": [
{ "base": "10.201.0.0/16", "size": 24 },
{ "base": "10.202.0.0/16", "size": 24 }
]
}இந்தக் குளம் டீமன் மறுதொடங்கிய பிறகு உருவாக்கப்படும் வலைகளுக்குப் பொருந்தும், ஏற்கனவே உள்ள பாலங்கள் தங்கள் முகவரிகளைத் தக்கவைக்கும். இது வசதியானது, மறப்பதும் எளிது, எனவே யாராவது அதன் வலையை மீண்டும் உருவாக்கும் வரை பழைய திட்டத்தை இன்னும் மேற்படிந்ததாகக் கருதுங்கள். Docker-இன் இன்ஜின் வலையமைப்பு ஆவணம் மதிப்பாய்வில் குளத்தை நியாயப்படுத்த வேண்டுமானால் ஒதுக்கீட்டு விதிகளை விவரிக்கிறது.
Linux பாலம் மற்றும் Docker Desktop வெவ்வேறு விதமாகத் தோல்வியடைகின்றன
Linux ஹோஸ்ட்டில், கொள்கலன்கள் ஹோஸ்ட் பெயர்வெளியில் உள்ள பாலங்களில் அமர்ந்திருக்கும். ஒரே அட்டவணை எல்லாவற்றையும் தீர்மானிக்கிறது, எனவே மேலே உள்ள ஒப்பீடே முழுக் கதை: பாலம் வழியைப் படியுங்கள், சுரங்கப்பாதை வழியைப் படியுங்கள், உண்மையான கொள்கலன் முகவரிக்கு எது வெல்லும் எனப் பாருங்கள்.
Docker Desktop கொள்கலன்களை அதன் சொந்த NAT உள்ள VM-க்குப் பின்னால் வைக்கிறது. ஹோஸ்ட்டுக்கு கொள்கலன் முகவரிக்கு எந்த வழியும் இல்லை; வெளியிடப்பட்ட துறைமுகம் வழியாகச் சேவையை அடைகிறது, பொதுவாக 127.0.0.1-உடன் பிணைக்கப்பட்டிருக்கும். எனவே VPN வாடிக்கையாளர் எந்தத் துணை வலை மேற்படிதலும் இல்லாமல் சேவையை உடைக்க முடியும்: VM-இன் உள் வரம்பிற்கு வழியை நிறுவுவதன் மூலம் அல்லது சுரங்கப்பாதை இணைந்திருக்கும்போது loopback போக்குவரத்தைத் தடுப்பதன் மூலம். ஹோஸ்ட்டில் ip route get கொள்கலன் முகவரிக்கு வழி இல்லை என்று தெரிவித்தால், அது எதிர்பார்க்கப்பட்டதே, பிழை அல்ல.
நடைமுறை விளைவு நீங்கள் முதலில் எங்கு பார்க்கிறீர்கள் என்பதில் உள்ளது. Linux-இல், வழிசெலுத்தல் அட்டவணையில் தொடங்குங்கள். Desktop-இல், வெளியிடப்பட்ட துறைமுகம் மற்றும் VPN வாடிக்கையாளரின் ஃபயர்வால் விதிகளில் தொடங்கி, VM-இன் உள் துணை வலை சுரங்கப்பாதை தள்ளும் எதனுடனும் மோதுகிறதா எனப் பாருங்கள்.
சுரங்கப்பாதை திறந்திருக்கும்போது சரிபார்க்கவும்
இது தீர்க்கப்பட்டது எனக் கூறும் முன் VPN-ஐ இருமுறை மீண்டும் இணைக்கவும், ஏனெனில் இணையும்போது வழிகளைத் தள்ளி, துண்டிக்கும்போது அவற்றை மீளப்பெறும் சுயவிவரம் முதல் முயற்சிக்குப் பிறகு சரியாகத் தோன்றலாம். பிறகு வாடிக்கையாளர் உண்மையில் செய்யும் சரிபார்ப்புகளை இயக்கவும்:
- கொள்கலனின் உண்மையான முகவரியைப் பயன்படுத்தி ஹோஸ்ட்டிலிருந்து
ip route get. - சேவை உடல்நலமாக உள்ளது என நிரூபிக்க மற்றொரு கொள்கலனிலிருந்து ஒரு கோரிக்கை.
- சுரங்கப்பாதை திறந்திருக்கும்போது வாடிக்கையாளரிடமிருந்து
curl -sv http://127.0.0.1:8080/, பிறகு LAN-இல் உள்ள இயந்திரத்திலிருந்து கொள்கலன் முகவரிக்குtraceroute -n. - கோரிக்கை ஹோஸ்ட்டை அடைந்தும் பதில் மறைந்தால்
sysctl net.ipv4.conf.all.rp_filter.
இறுதியாக, தேர்ந்தெடுத்த வரம்பை அதைத் தேர்ந்தெடுக்கப் பயன்படுத்திய அதே பதிவேட்டில் தேதி மற்றும் அதைச் சொந்தமாகக் கொண்ட திட்டத்துடன் எழுதுங்கள். அடுத்த மேற்படிதல் யாரும் ஆவணப்படுத்தாத திட்டத்திலிருந்து வரும், ஒரே பாதுகாப்பு என்னவென்றால் வரம்பு சீரற்றதாக அல்லாமல் வேண்டுமென்றே ஒதுக்கப்பட்டது என்பதே.