VPN கன்டெய்னருக்குள் உள்ள வலை இடைமுகத்தை அடைவது: போர்ட்டின் உரிமையாளரைத் தேர்ந்தெடுக்கவும்

பயன்பாட்டில் எந்தத் தவறும் இல்லை, சுரங்கப்பாதையிலும் எந்தத் தவறும் இல்லை, இருந்தும் டாஷ்போர்டு ஏற்றப்படவில்லை. ஒரு சேவை network_mode: service:vpn உடன் இயங்கும்போது, அது VPN கன்டெய்னரின் பிணையப் பெயர்வெளியைப் பகிர்கிறது, அதாவது அதன் கேட்பானும் வெளியிடப்பட்ட போர்ட்டுகளும் சேவைக்கு அல்ல, அந்தப் பெயர்வெளிக்குச் சொந்தம். இதிலிருந்து மூன்று முடிவுகள் வருகின்றன: பயன்பாடு எங்கே இணைகிறது, எந்தக் கன்டெய்னர் போர்ட்டை வெளியிடுகிறது, நிர்வாகப் பாதை எவ்வளவு குறுகலானது. இவற்றைத் தவறான வரிசையில் செய்தால் ஒவ்வொரு தனி அமைப்பும் சரியாகத் தெரியும், ஆனால் கலவை இயங்க முடியாது.

போர்ட் பெயர்வெளி யாருக்குச் சொந்தம்

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

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

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

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

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

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

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

நிர்வாகப் பாதை எப்படி உள்ளே வருவது என்பதைத் தேர்ந்தெடுக்கவும்

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

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

எல்லாவற்றையும் திறக்காமல் நிர்வாகப் போர்ட்டைத் திறக்கவும்

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

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

நிர்வாகச் சாதனத்திலிருந்து சரிபார்க்கவும், பிறகு மீண்டும் சரிபார்க்கவும்

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

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