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 ಅಲ್ಲದ ಹೋಸ್ಟ್ ವಿಳಾಸದಲ್ಲಿ ಯಾವುದೂ ಕೇಳುವುದಿಲ್ಲ। ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಮೇಲಿನ ಒಂದು ಸಾಲಿನ ಪರಿಶೀಲನೆ।

ಸಂಬಂಧಿತ ಲೇಖನಗಳು