VPN கொள்கலனின் நெட்வொர்க்கைப் பகிர்வது: DNS-க்கு என்ன நடக்கிறது
பகிரப்பட்ட பெயர்வெளி உங்கள் பயன்பாட்டுக்கு சுரங்கப்பாதையின் இடைமுகங்களைத் தருகிறது, ஒருங்கிணைந்த தீர்வி அல்ல. பயன்பாட்டின் உள்ளிருந்து சோதித்து, runtime ஆதரிக்கும் DNS ஏற்பாட்டைப் பயன்படுத்துங்கள்.
VPN கொள்கலனின் நெட்வொர்க் பெயர்வெளியைப் பகிர்வது உங்கள் பயன்பாட்டுக்கு சுரங்கப்பாதையின் இடைமுகங்களையும் வழித்தடங்களையும் தருகிறது. அது அதற்கு சுரங்கப்பாதையின் தீர்வியைத் தரவில்லை, அல்லது ஹோஸ்ட்டில் உள்ள வேறு எதன் ஒருங்கிணைந்த நகலையும் தரவில்லை. இந்த இடைவெளி மிகவும் குறிப்பிட்ட தோல்வியை உருவாக்குகிறது: பொது பெயர்கள் தீர்க்கப்படுகின்றன, உள் பெயர்கள் தீர்க்கப்படுவதில்லை, தோல்வியடையும் பயன்பாடு தவறான DNS சேவையகத்தைப் பயன்படுத்துவது போல் தெரிகிறது, ஏனெனில் அது உண்மையிலேயே அப்படிச் செய்கிறது. சரிசெய்தல் பொதுவாக நோயறிதல் குறிப்பிடுவதை விடச் சிறியது.
படி 1: ஹோஸ்ட்டிலிருந்து அல்ல, பயன்பாட்டிலிருந்து சோதியுங்கள்
பிரச்சினை உள்ள கொள்கலனின் உள்ளே தேடலை இயக்குங்கள், ஹோஸ்ட்டிலோ உலாவியிலோ அல்ல. docker exec app-container getent hosts db.internal முக்கியமான ஒரே கேள்விக்குப் பதிலளிக்கிறது: இந்தச் செயல்முறையின் தீர்வி என்ன திருப்பித் தருகிறது.
ஹோஸ்ட் பெயரைத் தீர்த்து கொள்கலன் தீர்க்கவில்லை என்றால், நீங்கள் குறையைக் கண்டுபிடித்துவிட்டீர்கள். இதற்குப் பிறகு எல்லாம் அதைச் சரிசெய்யும் ஆதரிக்கப்பட்ட வழியைத் தேர்ந்தெடுப்பதுதான்.
படி 2: runtime-இன் ஆதரிக்கப்பட்ட மாதிரியைப் படியுங்கள்
Docker-இன் நெட்வொர்க் ஆவணம் மற்றொரு கொள்கலனின் நெட்வொர்க் பயன்முறையைப் பகிரும் கொள்கலன்களுக்கான DNS கொடிகளில் உள்ள கட்டுப்பாடுகளைப் பதிவு செய்கிறது. Compose-இல் network_mode: service:vpn பயன்பாட்டை VPN கொள்கலனின் பெயர்வெளியுடன் இணைக்கிறது, ஒவ்வொரு சேவைக்கும் dns அமைப்புகள் சாதாரண சேவையில் இருப்பதுபோல் செயல்படுவதில்லை. நீங்கள் பெறும் தீர்வு பகிரப்பட்ட பெயர்வெளி வைத்திருப்பதே.
பயனர் வரையறுத்த பாலம் நெட்வொர்க்குகளும் Docker-இன் உள்ளமைந்த DNS-ஐ இயல்புநிலைப் பாலத்திலிருந்து வேறுவிதமாகப் பயன்படுத்துகின்றன. அதனால்தான் dns வேலை செய்யும் பாலம் எடுத்துக்காட்டிலிருந்து நகலெடுத்த ஒரு விதி பகிரப்பட்ட ஸ்டாக்கில் எதுவும் செய்யாமல் இருக்கலாம். விதியை நகலெடுக்கும் முன் ஏற்பாட்டைச் சரிபாருங்கள்.
லூப்பபேக் முகவரி எப்போதும் தொடர்புடைய நெட்வொர்க் சூழலைக் குறிக்கிறது. பகிரப்பட்ட பெயர்வெளிக்குள், 127.0.0.1 ஹோஸ்ட்டின் தீர்வி அல்ல.
படி 3: வினவலை அதன் பெறுநர் வரை பின்தொடருங்கள்
பயன்பாட்டின் தீர்வி உள்ளமைவைப் படியுங்கள், பின்னர் பயன்பாடு கொண்டுவரும் பயன்பாட்டுக்கு உரிய மறையாக்கப்பட்ட DNS-ஐப் படியுங்கள், ஏனெனில் தன் சொந்தத் தீர்வியை இயக்கும் பயன்பாடு நீங்கள் திருத்திய கோப்பைப் புறக்கணிக்கிறது. பின்னர் தேர்ந்தெடுத்த தீர்வி VPN-இன் வழித்தடங்கள் மற்றும் ஃபயர்வால் கொள்கையின் கீழ் அணுகக்கூடியதா எனச் சரிபாருங்கள். சுரங்கப்பாதையின் மறுபக்கத்தில் உள்ள தீர்வி முகவரி, பெயர்வெளிக்கு அங்கு வழித்தடம் இல்லாவிட்டால் பயனற்றது. எந்தக் கோப்பையும் திருத்தும் முன் பெறுநரை உறுதிப்படுத்துங்கள்.
உலாவியின் IP-சரிபார்ப்புப் பக்கம் பெயர் வினவல்கள் எங்கே சென்றன எனச் சொல்ல முடியாது. ஒரு HTTP இணைப்பு எங்கே சென்றது எனச் சொல்கிறது.
படி 4: இரண்டு தோல்வி வகைகளையும் வெவ்வேறாகச் சரிசெய்யுங்கள்
பொது பெயர்கள் வேலை செய்யும்போது சேவைப் பெயர்கள் தோல்வியடைந்தால், சிக்கல் கொள்கலன் நெட்வொர்க்கின் உள்ளேயுள்ள சேவைக் கண்டறிதலில் உள்ளது, பொது தீர்விகள் பட்டியலில் இல்லை. ஒவ்வொரு பொது DNS முகவரியையும் மாற்றுவது, நெட்வொர்க்கின் கண்டறிதல் பொறிமுறையிடம் ஒருபோதும் கேட்கப்படாத பதிவுகளை உருவாக்காது.
இரண்டு வகைகளும் தோல்வியடைந்தால், தீர்வியை அணுகும் திறனில் தொடங்குங்கள். ஒன்று மட்டும் தோல்வியடைந்தால், கண்டறிதல் பொறிமுறையில் தொடங்குங்கள். இரண்டுக்கும் வெவ்வேறு உரிமையாளர்கள் உள்ளனர், அதனால்தான் ஒரு சரிசெய்தல் ஒருபோதும் இரண்டையும் மூடுவதில்லை.
படி 5: மீண்டும் உருவாக்கிய பின் மீண்டும் சோதியுங்கள்
runtime-இன் ஆதரிக்கப்பட்ட பொறிமுறையின் மூலம் உள்ளமைவை மாற்றுங்கள், பின்னர் இயங்கும் கொள்கலனுக்குள் கோப்புகளைத் திருத்துவதற்குப் பதிலாக கொள்கலன்களை மீண்டும் உருவாக்குங்கள். புதிய தனிப்பட்ட பெயர், புதிய பொது பெயர் மற்றும் தேடலைத் தொடர்ந்து வரும் பயன்பாட்டுக் கோரிக்கையைச் சோதியுங்கள். /etc/resolv.conf கொள்கலனுக்குள் திருத்தம் மீண்டும் உருவாக்கும்போது மறைந்துவிடும், சரிசெய்யாதபோதும் அது செயல்பட்டதாக நம்பவைக்கும்.
பகிரப்பட்ட நெட்வொர்க் வரையறைக்கு அடுத்து தீர்வியின் உரிமையாளரையும் எதிர்பார்க்கப்படும் பெயர்வெளியையும் பதிவு செய்யுங்கள். அடுத்த நபருக்கு இரண்டும் தேவைப்படும்.