ਤੁਹਾਡਾ ਟਨਲ ਕੰਟੇਨਰ ਕੰਮ ਕਰਦਾ ਹੈ, 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 ਨਾ ਹੋਣ ਵਾਲੇ ਹੋਸਟ ਪਤੇ ਉੱਤੇ ਕੁਝ ਨਹੀਂ ਸੁਣਦਾ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਉਤਪਾਦਨ ਵਿੱਚ ਚੁੱਪਚਾਪ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਉੱਪਰ ਦਿੱਤੀ ਇੱਕ-ਲਾਈਨ ਜਾਂਚ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ