Docker VPN கொள்கலன் வழியாக ஹோஸ்ட் டிராஃபிக்கை எவ்வாறு ரூட் செய்வது

VPN கொள்கலன் ஒரு நெட்வொர்க் பெயர்வெளி, ப்ராக்ஸி அல்ல। பகிரப்பட்ட netns, உண்மையான SOCKS செவிமடுப்பான் அல்லது ரூட் செய்யப்பட்ட நுழைவாயில் தேர்ந்தெடுத்து, பின்னர் வெளியேறும் பாதையைச் சரிபார்க்கவும்।

உங்கள் சுரங்கக் கொள்கலன் வேலை செய்கிறது, docker compose exec vpn curl -s https://ifconfig.me வழங்குநரின் முகவரியுடன் பதிலளிக்கிறது, ஆயினும் உங்கள் டெஸ்க்டாப்பின் உலாவி இன்னும் உங்கள் ISP வழியாகவே வெளியேறுகிறது। அந்த இடைவெளி எதிர்பார்க்கப்படுகிறது। VPN கிளையண்டை இயக்கும் கொள்கலன் ஒரு நெட்வொர்க் பெயர்வெளி, வழிகள் மற்றும் சுரங்க இடைமுகத்தை வைத்திருக்கிறது, HTTP அல்லது SOCKS பேசும் எதையும் வைத்திருக்கவில்லை; அதில் போர்ட்டை வெளியிடுவது ஒருபோதும் இல்லாத செவிமடுப்பானை உருவாக்க முடியாது।

கிளையண்ட் எங்கு இயங்குகிறது என்பது வடிவமைப்பைத் தீர்மானிக்கிறது। அண்டை கொள்கலன் சுரங்கத்தின் பெயர்வெளிக்குச் செல்ல முடியும், டெஸ்க்டாப் பயன்பாடு செல்ல முடியாது, ரவுட்டருக்கு ப்ராக்ஸி புலம் அல்ல, வழிகள் தேவை। மேப்பிங்கைத் தவறாக்கினால் அறிகுறி ஒன்றே: இணைப்பு மறுக்கப்பட்டது, அல்லது அமைதியாகப் பழைய பாதையை எடுக்கும் டிராஃபிக்।

கிளையண்ட் இயங்கும் இடத்திற்கு ஏற்ப அமைப்பைப் பொருத்துங்கள்

Compose திருத்தும் முன் ஒரு கேள்வி கேளுங்கள்: VPN கொள்கலனின் நெட்வொர்க் பெயர்வெளிக்குள் கிளையண்டைத் தொடங்க முடியுமா? ஏற்கனவே Linux கொள்கலனாக இயங்கும் எதுவும் முடியும்। உங்கள் மேசையில் உள்ள உலாவி, IDE அல்லது CLI முடியாது, ஏனெனில் அதன் ப்ராக்ஸி அமைப்பு நெறிமுறை சேவையை எதிர்பார்க்கிறது, பெயர்வெளியை அல்ல।

ClientArrangementWhat must already exist
Another Compose serviceShares the vpn namespace via network_mode: service:vpnA working tunnel and correct start order
Host browser, IDE or CLIProxy listener inside the namespace, published to host loopbackA configured SOCKS or HTTP proxy and its access rules
Router, VM or phoneThe container as a layer-3 gatewayForwarding, NAT and a return route

இந்த மூன்றும் கலக்காது। கொள்கலனின் பால முகவரியை நோக்கிய HTTP ப்ராக்ஸி புலம் அங்கு ப்ராக்ஸி கேட்காவிட்டால் எதையும் அடையாது, ப்ராக்ஸி செவிமடுப்பான் ரவுட்டரின் டிராஃபிக்கை ரூட் செய்யாது। முதலில் முடிவு செய்து, பின்னர் பொருந்தும் பகுதியைப் பின்பற்றுங்கள்।

சுரங்க பெயர்வெளியை அண்டை கொள்கலனுடன் பகிருங்கள்

ப்ராக்ஸி நெறிமுறை ஈடுபடாததால் இதுவே மலிவான விருப்பம்। பயன்பாடு vpn சேவையின் பெயர்வெளியில் சேர்ந்து அதன் இடைமுகங்கள், வழிகள் மற்றும் போர்ட் இடத்தை மரபுரிமையாகப் பெறுகிறது:

services:
  vpn:
    image: your-vpn-client
    cap_add:
      - NET_ADMIN
    healthcheck:
      test: ["CMD-SHELL", "ip link show tun0 >/dev/null"]
      interval: 10s
      retries: 5
  app:
    image: your-app
    network_mode: service:vpn
    depends_on:
      vpn:
        condition: service_healthy

பெயர்வெளி வேறொரு சேவைக்குச் சொந்தமானதால் மூன்று கட்டுப்பாடுகள் வருகின்றன। பயன்பாட்டிற்கு அதன் சொந்த networks விசை கிடைக்காது, ஏனெனில் இணைக்க பெயர்வெளி இல்லை। போர்ட் வெளியீடு vpn-க்கு உரியது, ஏனெனில் பெயர்வெளி அங்கேயே வாழ்கிறது। மேலும் vpn-ஐ மீண்டும் உருவாக்கினால் பயன்பாடு சேர்ந்த பெயர்வெளி அழிகிறது, எனவே docker compose up -d --force-recreate vpn app-ஐயும் மீண்டும் உருவாக்க உங்களை அனுமதிக்கிறது; சாதாரண மறுதொடக்கம் எப்போதும் போதாது। Compose சேவை குறிப்பு இந்த அமைப்பையும் அதன் போர்ட் வெளியீட்டுக் கட்டுப்பாட்டையும் உள்ளடக்குகிறது।

தீர்வான் உடன் வரும் என்று கருதாதீர்கள்। /etc/resolv.conf ஒவ்வொரு கொள்கலனுக்கும் ஒரு கோப்பு, நெட்வொர்க் பெயர்வெளியின் பகுதி அல்ல, எனவே பயன்பாட்டின் பொதிகள் சுரங்கம் வழியாக வெளியேறும்போதும் அது ஹோஸ்டின் தீர்வானைக் கேட்க முடியும்। அதைக் கொள்கலனின் உள்ளிருந்து படித்து, தனிப்பட்ட பெயர்கள் சுரங்கம் வழியாகத் தீர்க்கப்பட வேண்டியபோது பயன்பாட்டில் dns: அமைக்கவும்।

docker compose exec app ip route
docker compose exec app cat /etc/resolv.conf
docker compose exec app curl -s https://ifconfig.me

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

ஹோஸ்ட் கிளையண்டுகளுக்காக பெயர்வெளியில் உண்மையான ப்ராக்ஸி செவிமடுப்பானை வைக்கவும்

டெஸ்க்டாப் உலாவி பெயர்வெளியில் சேர முடியாது, எனவே சுரங்கம் சேவையாக வெளிப்படுத்தப்பட வேண்டும்। vpn பெயர்வெளிக்குள் உண்மையான SOCKS அல்லது HTTP ப்ராக்ஸியை இயக்கி அதன் போர்ட்டை மட்டும் வெளியிடுங்கள்:

services:
  vpn:
    ports:
      - "127.0.0.1:1080:1080"
  proxy:
    image: your-proxy
    network_mode: service:vpn
    command: ["--socks", "0.0.0.0:1080"]

ஹோஸ்ட் பக்க முகவரியே அந்த மேப்பிங்கின் முக்கியப் பாதி। இடதுபுறம் 127.0.0.1:1080 செவிமடுப்பானை உங்கள் LAN-க்கு வெளியே வைக்கிறது; வெறும் "1080:1080" உங்கள் இயந்திரத்தை அடையக்கூடிய ஒவ்வொரு சாதனத்திற்கும் திறந்த ப்ராக்ஸியை வெளியிடுகிறது।

கொள்கலன் பக்கத்திற்கு அதன் சொந்தப் பொறி உள்ளது। வெளியிடப்பட்ட போர்ட்கள் கொள்கலனின் பால முகவரிக்கு வழங்கப்படுகின்றன, அதன் loopback-க்கு அல்ல, எனவே பெயர்வெளிக்குள் --socks 127.0.0.1:1080 உடன் தொடங்கப்பட்ட ப்ராக்ஸி அண்டை கொள்கலன்களின் இணைப்புகளை ஏற்றுக்கொண்டு வெளியிடப்பட்ட போர்ட் வழியாக வருவதை மறுக்கிறது। அதை 0.0.0.0 உடன் பிணைத்து, தனிமைப்படுத்தலுக்கு ஹோஸ்ட் பக்க loopback பிணைப்பை நம்புங்கள்। அதே விதி ப்ராக்ஸி உள்ளமைவு கோப்பில் உள்ள கேட்கும் முகவரிக்கும் பொருந்தும்।

பின்னர் பெயர்கள் எங்கு தீர்க்கப்படுகின்றன என்பதைத் தீர்மானிக்கவும்। curl-ல் --socks5 ஹோஸ்ட் பெயரை உள்ளூரில் தீர்க்கிறது, --socks5-hostname பெயரை ப்ராக்ஸிக்கு அனுப்புகிறது; உலாவிகள் அதே சுவிட்சை வேறு லேபிளில் காட்டுகின்றன। உள்ளூர் தீர்வு பக்கம் சுரங்கம் வழியாக ஏற்றப்பட்டாலும் வினவலைக் கசியவிடுகிறது।

திரும்பும் வழி இருந்தால் மட்டுமே கொள்கலனை நுழைவாயிலாகக் கருதுங்கள்

ரவுட்டர்கள், VM-கள் மற்றும் தொலைபேசிகள் HTTP ப்ராக்ஸி புலத்தைப் பயன்படுத்தாது, சில பயன்பாடுகள் ப்ராக்ஸி மாறிகளை முற்றிலும் புறக்கணிக்கின்றன। அவற்றின் டிராஃபிக்கை ரூட் செய்வது என்பது அடுக்கு 3: கொள்கலன் பொதிகளை முன்னனுப்பி சுரங்க இடைமுகத்தில் முகவரிகளை மொழிபெயர்க்கிறது।

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

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

அதன் தாக்க வீச்சும் மிகப் பெரியது। முழு LAN-க்கும் நுழைவாயிலாக இருக்கும் ஹோஸ்ட் தவறாக உள்ளமைக்கப்பட்ட ஒவ்வொரு கிளையண்டையும் உங்கள் VPN கணக்கு வழியாக அனுப்புகிறது, சுரங்கம் விழுந்தால் kill switch-ஐப் பொருத்து LAN இருளாகும் அல்லது ISP-க்குத் திரும்பும்।

வெளியேறும் பாதையைச் சரிபார்த்து, பின்னர் வரிசையாகப் பின்னோக்கி மாற்றுங்கள்

இந்த வரிசையில் சரிபார்த்து முதல் தோல்வியில் நில்லுங்கள்: பெயர்வெளிக்குள் வெளியேறும் முகவரி, ஹோஸ்டிலிருந்து ப்ராக்ஸி வழியாக வெளியேறும் முகவரி, பின்னர் தனிப்பட்ட ஹோஸ்டுக்கான பெயர் தீர்வு।

docker compose exec vpn curl -s https://ifconfig.me
curl -s -x socks5h://127.0.0.1:1080 https://ifconfig.me
curl -s -x socks5h://127.0.0.1:1080 http://internal.example/health

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

பின்னோக்கி மாற்றுவது அமைப்பின் எதிர்। ஷெல் சுயவிவரம் மற்றும் எந்த systemd அலகிலிருந்தும் ப்ராக்ஸி சூழல் மாறிகளை நீக்கி, பின்னர் ஸ்டாக்கை இறக்குங்கள், பகிரப்பட்ட பெயர்வெளி அதன் உரிமையாளருடன் மறையும்। ப்ராக்ஸி சேவையை நீக்கும் முன் வெளியிடப்பட்ட போர்ட்டை நீக்குங்கள், இல்லையேல் ஹோஸ்டில் யாரும் படிக்காத loopback செவிமடுப்பான் எஞ்சும்।

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

தொடர்புடைய கட்டுரைகள்