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 ਬਾਅਦ ਵਿੱਚ ਕਿਤੇ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਪ੍ਰਕਾਸ਼ਿਤ ਮੈਪਿੰਗ ਅਤੇ ਬਾਈਂਡ ਪਤਾ ਲਿਖ ਲਓ ਤਾਂ ਜੋ ਅਗਲੀ ਮੁੜ-ਉਸਾਰੀ ਦੁਬਾਰਾ ਜਾਂਚ ਨਹੀਂ, ਬਲਕਿ ਦੋ ਮਿੰਟ ਦੀ ਪੜਤਾਲ ਹੋਵੇ।