Docker போர்ட் வெளியீடு vs VPN: பதில் எங்கே செல்கிறது

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

இலக்கு NAT வழியாக டூப்பிளைப் பின்தொடரவும்

ஒரு ஹோஸ்ட்டை எடுத்துக்கொள்ளுங்கள் 192.0.2.10 இல், அது TCP 2222 ஐ 172.30.240.5:22 இல் உள்ள கன்டெய்னருக்கு வெளியிடுகிறது. 198.51.100.25 இலிருந்து வரும் கோரிக்கை கன்டெய்னரை அடைவதற்கு முன் மொழிபெயர்க்கப்படுகிறது, கன்டெய்னர் தன்னாகவே பதிலளிக்கிறது.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

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

ஹோஸ்ட்டுக்கு மட்டும் உள்ள விதி அதைத் தவறவிடுவது ஏன்

WAN அட்டவணையை 192.0.2.10 இலிருந்து வரும் பாக்கெட்டுகளுக்கு மட்டும் தேர்ந்தெடுக்கும் விதி ஹோஸ்ட்டின் சொந்த டீமான்களை உள்ளடக்கி, இந்த முன்னனுப்பப்பட்ட பதிலை முழுவதுமாகத் தவறவிடுகிறது. பதிலில் உள்ள மூல முகவரி 172.30.240.5, ஹோஸ்ட் அல்ல.

அதிகமான திருத்தம் என்பது கன்டெய்னரிலிருந்து எல்லாவற்றையும் WAN வழியாக வழிமாற்றுவதாகும், இது கன்டெய்னரின் தொடர்பில்லாத வெளிச்செல்லும் இணைப்புகளையும் VPN இலிருந்து விலக்குகிறது. அது கேட்கப்பட்ட கொள்கையிலிருந்து வேறுபட்டது, பொதுவாக பின்னர் யாரையாவது ஆச்சரியப்படுத்துகிறது.

DNAT க்குப் பிந்தைய பொருத்தம் வேறு ஒரு ஹூக்

Docker இன் ஃபயர்வால் ஆவணம் குறிப்பிடுகிறது: சாதாரண பயனர் வடிகட்டுதல் DNAT க்குப் பிந்தைய இலக்கைப் பார்க்கிறது, எனவே சாதாரண விதியில் வெளியிடப்பட்ட போர்ட் 2222 ஐப் பொருத்துவது கன்டெய்னர் போர்ட் 22 ஐப் பொருத்துவதற்குச் சமமல்ல. அசல் டூப்பிள் முக்கியமெனில், எந்தப் போர்ட் தெரிகிறது என ஊகிப்பதற்குப் பதிலாக ஆதரிக்கப்படும் அசல்-இலக்கு முறையைப் பயன்படுத்துங்கள்.

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

வடிவமைப்பு A: முடிவை இணைப்பு நிலையாக எடுத்துச் செல்லுங்கள்

இணைப்புக் குறி நுழைவு முடிவை மொழிபெயர்ப்பின் வழியாக எடுத்துச் செல்ல முடியும், ஆனால் முக்கியமான பாதைத் தேடலுக்கு முன் அது பாக்கெட்டுக்குத் திரும்பக் கொண்டுவரப்பட வேண்டும். நிலைகள்:

1. Docker, VPN அல்லது வேறு கொள்கை உரிமையாளருடன் மோதாத குறிப் புலத்தையும் விதி முன்னுரிமையையும் ஒதுக்குங்கள்.
2. இணைப்புக் கண்காணிப்பு கிடைக்கும் DNAT க்கு முந்தைய புள்ளியில் நோக்கமிடப்பட்ட புதிய WAN இணைப்பை மட்டும் அடையாளம் காணுங்கள்.
3. அசல் கோரிக்கையையே WAN அட்டவணைக்குள் தள்ளாமல் முடிவை இணைப்புக் குறியில் பதிவு செய்யுங்கள்.
4. பதில் திசையில், வழிமாற்றத்திற்கு முன் உங்கள் சொந்தக் குறி பிட்களை மட்டும் பாக்கெட்டுக்குத் திரும்பக் கொண்டுவாருங்கள்.
5. VPN விதி முதலில் வெல்ல முடியாதபடி முழுமையான WAN அட்டவணையைப் போதுமான முன்பே தேர்ந்தெடுங்கள்.

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

வடிவமைப்பு B: ஹோஸ்ட்டில் முடிக்கவும்

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

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

மாற்றத்தைச் சரிபார்க்கவும், நோக்கத்தை அல்ல

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

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