ਕੰਟੇਨਰ VPN-only API ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਰਿਹਾ? ਇਸਨੂੰ ਹੋਸਟ ’ਤੇ ਪ੍ਰਾਕਸੀ ਕਰੋ

ਤੁਹਾਡੀ Compose ਸੇਵਾ ਉਸ API ਲਈ ਸਮਾਂ-ਸੀਮਾ ਪਾਰ ਕਰ ਜਾਂਦੀ ਹੈ ਜਿਸਨੂੰ ਉਸੇ ਮਸ਼ੀਨ ਦਾ ਬ੍ਰਾਊਜ਼ਰ ਬਿਨਾਂ ਕਿਸੇ ਸ਼ਿਕਾਇਤ ਦੇ ਖੋਲ੍ਹਦਾ ਹੈ। ਇਹੀ ਫ਼ਰਕ ਸੁਰਾਗ ਹੈ: ਜੋ ਬੇਨਤੀ ਕੰਮ ਕਰਦੀ ਹੈ ਉਹ VPN ਟਨਲ ਵਾਲੇ ਹੋਸਟ ਤੋਂ ਨਿਕਲਦੀ ਹੈ, ਅਤੇ ਜੋ ਅਟਕ ਜਾਂਦੀ ਹੈ ਉਹ ਆਪਣਾ ਨੈੱਟਵਰਕ ਸਟੈਕ ਰੱਖਣ ਵਾਲੇ ਕੰਟੇਨਰ ਤੋਂ। ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਕੁਝ ਵੀ ਟਨਲ ਦੇ ਰੂਟ ਨਹੀਂ ਜਾਣਦਾ, ਇਸ ਲਈ ਨਾਮ ਕਿਵੇਂ ਵੀ ਲਿਖਿਆ ਜਾਵੇ ਨਿੱਜੀ ਮੰਜ਼ਿਲ ਅਪਹੁੰਚ ਰਹਿੰਦੀ ਹੈ। ਹੱਲ ਹੋਸਟ ਰਾਹੀਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤੀ ਛਾਲ ਹੈ, ਵਧੇਰੇ ਚਤੁਰ ਰੂਟ ਟੇਬਲ ਨਹੀਂ।

ਦੋ ਰਾਹ ਕਿਉਂ ਵੱਖਰੇ ਹਨ ਇਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਟਨਲ ਕਿੱਥੇ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ।

ਹੋਸਟ ਕਿਉਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਕਿਉਂ ਨਹੀਂ

ਟਨਲ ਚੁੱਕਣ ਨਾਲ ਹੋਸਟ ਨੂੰ ਇੱਕ ਇੰਟਰਫ਼ੇਸ, ਰੂਟਾਂ ਦਾ ਸਮੂਹ ਅਤੇ ਆਮ ਤੌਰ ’ਤੇ VPN ਵੱਲੋਂ ਦਿੱਤੀ ਰਿਜ਼ੋਲਵਰ ਐਂਟਰੀ ਮਿਲਦੀ ਹੈ। ਕੰਟੇਨਰ ਨੂੰ ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਮਿਲਦਾ: ਇਹ ਇੰਜਣ ਦੇ ਬ੍ਰਿਜ ’ਤੇ ਇੱਕ ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਉਸੇ ਬ੍ਰਿਜ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੇ ਡਿਫ਼ਾਲਟ ਰੂਟ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਹੋਸਟ ’ਤੇ ਲੱਗੇ ਰੂਟ ਉਸ ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰ ਚੱਲ ਰਹੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਨਹੀਂ ਦਿਸਦੇ।

ਇਸੇ ਲਈ ਲੱਛਣ ਸਿਰਫ਼ ਟੁੱਟੇ ਨਹੀਂ ਸਗੋਂ ਅਸੰਗਤ ਦਿਸਦੇ ਹਨ। ਹੋਸਟ ਨਿੱਜੀ ਨਾਮ ਹੱਲ ਕਰਕੇ ਜੁੜਦਾ ਹੈ, ਕਿਉਂਕਿ ਉੱਥੇ ਨਾਮ ਅਤੇ ਰੂਟ ਦੋਵੇਂ ਹਨ। ਕੰਟੇਨਰ ਆਪਣਾ ਪੈਕਟ ਅਜਿਹੇ ਨਿੱਜੀ ਪਤੇ ’ਤੇ ਭੇਜਦਾ ਹੈ ਜਿੱਥੇ ਬ੍ਰਿਜ ਰਾਹ ’ਤੇ ਕੋਈ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ, ਅਤੇ ਬੇਨਤੀ ਸਮਾਂ-ਸੀਮਾ ਪਾਰ ਕਰ ਜਾਂਦੀ ਹੈ। ਕੰਟੇਨਰ ਦੀ hosts ਫ਼ਾਈਲ ਵਿੱਚ ਨਾਮ ਜੋੜਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਕਿਉਂਕਿ ਪਤਾ ਆਪ ਹੀ ਕੰਟੇਨਰ ਜਿੱਥੇ ਬੈਠਾ ਹੈ ਉੱਥੋਂ ਅਪਹੁੰਚ ਹੈ।

ਕੰਟੇਨਰ ਦੇ ਅੰਦਰੋਂ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚੋ

ਕੰਟੇਨਰ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਜੋ localhost ਡਾਇਲ ਕਰਦੀ ਹੈ, ਕੰਟੇਨਰ ਨੂੰ ਡਾਇਲ ਕਰਦੀ ਹੈ। Docker Desktop host.docker.internal ਨੂੰ ਇੰਜਣ ਚਲਾਉਣ ਵਾਲੀ ਮਸ਼ੀਨ ਵੱਲ ਵਾਪਸ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੇ ਨਾਮ ਵਜੋਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ; Linux ਇੰਜਣ ਸੇਵਾ ਮੰਗਣ ਤੱਕ ਇਸਨੂੰ ਅਣ-ਪਰਿਭਾਸ਼ਿਤ ਛੱਡਦੇ ਹਨ, ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੀ ਮੈਪਿੰਗ ਇਹੀ ਕਰਦੀ ਹੈ। ਇਸ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਨਿੱਜੀ ਪਤੇ ਦੀ ਥਾਂ ਨਾਮ ਅਤੇ ਪੋਰਟ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀ ਹੈ।

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      INTERNAL_API_HOST: "host.docker.internal:8666"

ਟਨਲ ਛਾਲ ਦੇ ਹੋਸਟ ਪਾਸੇ ਹੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਉਸ ਵੇਰੀਏਬਲ ਵਿੱਚ ਪੋਰਟ ਉਹੀ ਹੈ ਜਿਸ ’ਤੇ ਪ੍ਰਾਕਸੀ ਸੁਣੇਗੀ। ਟਨਲ ਗੁਆਉਣ ਵਾਲਾ ਕੰਟੇਨਰ ਹੁਣ ਇੱਕ ਜਾਣੀ-ਪਛਾਣੀ ਛਾਲ ’ਤੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਉਸ ਰੂਟ ਨੂੰ ਅਜ਼ਮਾਉਣ ਦੀ ਥਾਂ ਜੋ ਉਸ ਕੋਲ ਕਦੇ ਨਹੀਂ ਸੀ।

ਚੁਣੋ ਕਿ ਟਨਲ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ

ਨਿੱਜੀ API ਲੋੜੀਂਦੀ Compose ਸੇਵਾ ਲਈ ਤਿੰਨ ਰੂਪ ਸੰਭਵ ਹਨ, ਅਤੇ ਉਹ ਇਸ ਵਿੱਚ ਵੱਖਰੇ ਹਨ ਕਿ ਟਨਲ ਕਿਸ ਪ੍ਰਕਿਰਿਆ ਕੋਲ ਹੈ। VPN ਕਲਾਇੰਟ ਕੰਟੇਨਰ ਇਮੇਜ ਦੇ ਅੰਦਰ ਚੱਲ ਸਕਦਾ ਹੈ, ਜਿਸ ਲਈ ਟਨਲ ਯੰਤਰ ਖੋਲ੍ਹਣਾ ਅਤੇ ਇਸ ਨਾਲ ਆਉਣ ਵਾਲੀ ਨੈੱਟਵਰਕ ਪ੍ਰਸ਼ਾਸਨ ਸਮਰੱਥਾ ਦੇਣੀ ਲਾਜ਼ਮੀ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਵੱਖਰੇ ਟਨਲ ਕੰਟੇਨਰ ਦਾ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਸਾਂਝਾ ਕਰ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਦੋਵੇਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਇੱਕ ਸਟੈਕ ਅਤੇ ਇੱਕ ਰੂਟ ਟੇਬਲ ਦੇਖਦੀਆਂ ਹਨ। ਜਾਂ ਟਨਲ ਹੋਸਟ ’ਤੇ ਹੀ ਰਹਿ ਸਕਦੀ ਹੈ, ਹੋਸਟ ਤੋਂ ਕੰਟੇਨਰ ਵਿੱਚ ਇੱਕ ਸੰਕਰੇ ਫਾਰਵਰਡਰ ਨਾਲ।

ਪਹਿਲੇ ਦੋ ਪ੍ਰੋਫ਼ਾਈਲ ਫ਼ਾਈਲਾਂ, ਮੁੜ-ਜੁੜਨ ਵਿਵਹਾਰ ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਨੀਤੀ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਖਿੱਚਦੇ ਹਨ, ਅਤੇ ਫ਼ਾਈਲ ਦੀ ਹਰ ਸੇਵਾ ਨੂੰ ਟਨਲ ਦੀ ਸਿਹਤ ’ਤੇ ਨਿਰਭਰ ਬਣਾ ਦਿੰਦੇ ਹਨ। ਇੱਕ API ਕਾਲ ਲਈ ਇਹ ਬਹੁਤ ਜੋੜ ਹੈ। ਇੱਕ ਹੀ ਅੰਦਰੂਨੀ ਐਂਡਪੌਇੰਟ ਪੜ੍ਹਨ ਵਾਲੇ ਡਿਵੈਲਪਮੈਂਟ ਸਟੈਕ ਲਈ ਹੋਸਟ-ਪਾਸੇ ਵਾਲਾ ਫਾਰਵਰਡਰ ਸਭ ਤੋਂ ਛੋਟਾ ਬਦਲਾਅ ਹੈ ਜੋ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਉੱਥੇ ਹੀ ਰੱਖਦਾ ਹੈ ਜਿੱਥੇ ਪਲੇਟਫ਼ਾਰਮ ਟੀਮ ਉਨ੍ਹਾਂ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦੀ ਹੈ।

ਹੋਸਟ ’ਤੇ ਇੱਕ ਸੰਕਰਾ ਰਾਹ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ

ਫਾਰਵਰਡਰ ਜੋ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਉਂਦਾ ਹੈ ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਇਸਨੂੰ ਉਸ ਖਾਤੇ ਹੇਠ ਚਲਾਓ ਜੋ ਟਨਲ ਦਾ ਮਾਲਕ ਹੈ, ਫਿਰ ਇਸ ਦੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਸਾਕਟ ਹੋਸਟ ਦੇ ਰੂਟ ਅਤੇ ਹੋਸਟ ਦਾ ਰਿਜ਼ੋਲਵਰ ਲੈ ਲੈਣਗੇ। nginx ਦਾ ਇੱਕ location ਬਲਾਕ ਇੱਕ ਰਾਹ ਕਵਰ ਕਰਦਾ ਹੈ।

server {
    listen 8666;
    location /search/ {
        proxy_pass http://10.20.30.40:8090/;
        proxy_set_header Host internal-api.example;
        proxy_read_timeout 60s;
    }
}

ਪਤੇ ਅਤੇ ਪੋਰਟ ਨੂੰ ਅਸਥਾਈ ਮੰਨੋ ਅਤੇ ਉਹ ਜੋੜੀ ਪਾਓ ਜਿਸ ’ਤੇ API ਸੱਚਮੁੱਚ ਸੁਣਦੀ ਹੈ। ਹਰ ਵਾਧੂ upstream ਆਪਣਾ location ਬਲਾਕ ਪਾਉਂਦਾ ਹੈ, ਅਤੇ ਹਰ ਬਲਾਕ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਰਾਹ ਮਨਜ਼ੂਰ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਹ ਸੇਵਾ ਕਾਲ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਪ੍ਰਾਕਸੀ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਵਿੱਚ ਆਮ ਦਰਵਾਜ਼ਾ ਨਾ ਬਣ ਜਾਵੇ। host-gateway ਰਾਹੀਂ ਆਉਣ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਲਈ ਸਰੋਤੇ ਨੂੰ ਬ੍ਰਿਜ ਪਤੇ ਨਾਲ, ਕਲਾਇੰਟ ਹੋਸਟ ਦਾ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਸਾਂਝਾ ਕਰਦਾ ਹੋਵੇ ਤਾਂ ਹੀ loopback ਨਾਲ, ਅਤੇ ਕਦੇ ਵੀ 0.0.0.0 ਨਾਲ ਨਾ ਬੰਨ੍ਹੋ। ਅਜੇ ਖਾਲੀ ਪੋਰਟ ਵੀ ਚੁਣੋ: ਪਹਿਲਾਂ ਲਿਆ ਹੋਇਆ ਨੰਬਰ ਪ੍ਰਾਕਸੀ ਨੂੰ ਸੁਣਦਾ ਨਹੀਂ ਰਹਿਣ ਦਿੰਦਾ ਜਦੋਂ ਕਿ ਕੰਟੇਨਰ ਸਮਾਂ-ਸੀਮਾ ਪਾਰ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਜਿਸਨੂੰ ਉਸ ਨੈੱਟਵਰਕ ਖ਼ਰਾਬੀ ਤੋਂ ਵੱਖਰਾ ਨਹੀਂ ਪਛਾਣਿਆ ਜਾ ਸਕਦਾ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ।

ਪੋਰਟ, ਨਾਮ ਅਤੇ TLS ਫ਼ੈਸਲਾ

ਨਾਮ ਹੱਲ ਕਰਨਾ ਰੂਟਿੰਗ ਵਾਂਗ ਹੀ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਕੰਟੇਨਰ ਦੀਆਂ ਜਨਤਕ ਖੋਜਾਂ ਇੰਜਣ ਦੇ ਰਿਜ਼ੋਲਵਰ ਰਾਹੀਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਹੋਸਟ ’ਤੇ ਹੱਲ ਹੋਣ ਵਾਲਾ ਨਿੱਜੀ ਨਾਮ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਹੱਲ ਨਹੀਂ ਹੋਵੇਗਾ। ਨਿੱਜੀ ਨਾਮ ਹੱਲ ਕਰਨ ਵਾਲਾ ਹਿੱਸਾ ਪ੍ਰਾਕਸੀ ਹੈ, ਕਿਉਂਕਿ ਇਸਨੂੰ ਹੋਸਟ ਦਾ ਰਿਜ਼ੋਲਵਰ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ।

TLS ਉਹ ਫ਼ੈਸਲਾ ਹੈ ਜੋ ਟਾਲਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਅਗਲੀ ਅਸਫਲਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। ਜੇ ਪ੍ਰਾਕਸੀ ਬਾਈਟ ਅਛੂਤ ਭੇਜਦੀ ਹੈ, ਕੰਟੇਨਰ API ਦਾ ਆਪਣਾ ਸਰਟੀਫ਼ਿਕੇਟ ਦੇਖਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਭਰੋਸੇ ਸਟੋਰ ਵਿੱਚ ਅੰਦਰੂਨੀ CA ਚਾਹੀਦਾ ਹੈ। ਜੇ ਪ੍ਰਾਕਸੀ TLS ਖ਼ਤਮ ਕਰਦੀ ਹੈ, ਉਹ ਭਰੋਸਾ ਹੋਸਟ ’ਤੇ ਚਲਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਮਿਲਦੇ host ਹੈਡਰ ਤੋਂ ਲਿੰਕ ਬਣਾਉਣ ਲੱਗਦੀ ਹੈ। ਇੱਕ ਪ੍ਰਬੰਧ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਹਰ ਸਰੋਤ ’ਤੇ ਲਾਗੂ ਕਰੋ, ਕਿਉਂਕਿ ਦੂਜੇ ਵੱਲੋਂ ਜਾਰੀ ਰੀਡਾਇਰੈਕਟ ਅਜਿਹੇ ਹੋਸਟਨਾਮ ਵੱਲ ਜਾਂਦਾ ਹੈ ਜਿਸਨੂੰ ਕੰਟੇਨਰ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਸੇਵਾ ਦੇ ਅੰਦਰੋਂ ਤਸਦੀਕ ਕਰੋ

ਬੇਨਤੀ ਹੋਸਟ ਤੋਂ ਨਹੀਂ, ਕੰਟੇਨਰ ਤੋਂ ਭੇਜੋ: ਪ੍ਰਾਕਸੀ ਰਾਹ ’ਤੇ ਸਾਧਾਰਨ curl, ਫਿਰ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਪਣੀ ਸਿਹਤ ਜਾਂਚ। ਜਦੋਂ ਪ੍ਰਾਕਸੀ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ: ਇਹ ਜੋ ਅਧਾਰ URL ਬਣਾਉਂਦੀ ਹੈ, ਇਸ ਦੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕੋਈ ਵੀ ਪ੍ਰਾਕਸੀ ਵੇਰੀਏਬਲ, ਅਤੇ ਇਹ ਜਿਸ CA ’ਤੇ ਭਰੋਸਾ ਕਰਦੀ ਹੈ। ਸਾਰੇ ਕੰਟੇਨਰ ਦੇ ਵਾਤਾਵਰਣ ਅਤੇ ਲੌਗ ਵਿੱਚ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ ਵੀ ਠੀਕ ਕਰਨ ਨਾਲ VPN ਨੂੰ ਹੱਥ ਨਹੀਂ ਲੱਗਦਾ।

ਚੁਣਿਆ ਪ੍ਰਬੰਧ ਤਾਜ਼ਾ ਹੁੰਦੇ ਹੀ ਪ੍ਰੋਜੈਕਟ ਦੀ README ਵਿੱਚ ਲਿਖੋ। ਨਹੀਂ ਤਾਂ ਇਸ ਸਮਾਂ-ਸੀਮਾ ਨਾਲ ਟਕਰਾਉਣ ਵਾਲਾ ਅਗਲਾ ਵਿਅਕਤੀ ਉਹੀ ਦੁਪਹਿਰ ਟਨਲ ਹੋਸਟ ’ਤੇ ਰਹਿੰਦੀ ਹੈ ਇਹ ਦੁਬਾਰਾ ਲੱਭਣ ਵਿੱਚ ਲੰਘਾਏਗਾ।