ਦੋ ਨੈੱਟਵਰਕ ਵਾਲਾ ਕੰਟੇਨਰ ਗਲਤ ਗੇਟਵੇ ਚੁਣਦਾ ਹੈ

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

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

ਡਿਫਾਲਟ ਰੂਟ ਗਲਤ ਨੈੱਟਵਰਕ 'ਤੇ ਕਿਉਂ ਡਿੱਗਦਾ ਹੈ

ਸੇਵਾ ਜਿਸ ਵੀ ਨੈੱਟਵਰਕ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ, ਉਹ ਆਪਣਾ ਗੇਟਵੇ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਕੰਟੇਨਰ ਕੋਲ ਫਿਰ ਵੀ ਠੀਕ ਇੱਕ ਡਿਫਾਲਟ ਰੂਟ ਰਹਿੰਦਾ ਹੈ। Compose 2.33.1 ਤੋਂ ਪਹਿਲਾਂ ਬਰਾਬਰੀ ਨੈੱਟਵਰਕ ਨਾਵਾਂ ਨੂੰ ਤਰਤੀਬ ਦੇ ਕੇ ਤੈਅ ਹੁੰਦੀ ਸੀ, ਇਸ ਲਈ control ਵਰਗਾ ਲੇਬਲ ਜੋ office ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ, ਇਹ ਤੈਅ ਕਰਦਾ ਸੀ ਕਿ ਟ੍ਰੈਫ਼ਿਕ ਕਿੱਥੇ ਜਾਵੇਗਾ। ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਕੁਝ ਵੀ ਦਰਜ ਨਹੀਂ ਕਰਦਾ ਕਿ ਫ਼ੈਸਲਾ ਮਨਮਾਨਾ ਸੀ, ਇਸ ਲਈ ਇਹ ਕੋਡ ਸਮੀਖਿਆ ਵਿੱਚੋਂ ਲੰਘ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਅਜੀਬ ਰਾਹ ਵਜੋਂ ਸਾਹਮਣੇ ਆਉਂਦਾ ਹੈ। compose ਫ਼ਾਈਲ ਵਿੱਚ ਨੀਤੀ ਰੱਖਣਾ ਹੀ ਇਸ ਚੋਣ ਨੂੰ ਜਾਂਚਯੋਗ ਬਣਾਉਣ ਦਾ ਇੱਕੋ ਤਰੀਕਾ ਹੈ।

ਕਿਹੜਾ ਨੈੱਟਵਰਕ ਜਿੱਤੇਗਾ ਇਹ ਸੱਚਮੁੱਚ ਦੋ ਚੀਜ਼ਾਂ ਬਦਲਦੀਆਂ ਹਨ: ਤੁਹਾਡੇ ਵੱਲੋਂ ਦਿੱਤੇ gw_priority ਮੁੱਲ, ਅਤੇ ਕਿਹੜੇ ਨੈੱਟਵਰਕ ਜੁੜੇ ਹੋਏ ਹਨ। ਤੀਜਾ ਨੈੱਟਵਰਕ ਜੋੜੋ ਤਾਂ ਉਮੀਦਵਾਰਾਂ ਦਾ ਸਮੂਹ ਵਧਦਾ ਹੈ; macvlan ਹਟਾਓ ਤਾਂ ਬ੍ਰਿਜ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਬਚਦਾ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕਦਮ ਐਪਲੀਕੇਸ਼ਨ ਲੌਗਾਂ ਵਿੱਚ ਨਹੀਂ ਦਿਸਦਾ, ਕਿਉਂਕਿ ਗਲਤ ਡਿਫਾਲਟ ਰੂਟ ਕਦੇ-ਕਦਾਈਂ ਹੀ ਕਨੈਕਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੋੜਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਜਵਾਬਾਂ ਨੂੰ ਉਸ ਪਤੇ ਤੋਂ ਆਉਣ ਦਿੰਦਾ ਹੈ ਜਿਸ ਦੀ ਦੂਜਾ ਪਾਸਾ ਸ਼ਾਇਦ ਉਮੀਦ ਨਾ ਕਰੇ।

gw_priority ਨਾਲ ਗੇਟਵੇ ਪਿੰਨ ਕਰੋ

Compose 2.33.1 ਸੰਸਕਰਣ ਤੋਂ ਹਰ ਸੇਵਾ-ਤੋਂ-ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨ 'ਤੇ gw_priority ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਵੱਡੀ ਸੰਖਿਆ ਜਿੱਤਦੀ ਹੈ। ਹਰ ਸੇਵਾ ਲਈ ਵੱਖਰੀ ਗੇਟਵੇ ਕੁੰਜੀ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਮੁੱਲ ਸੇਵਾ ਦੇ networks ਬਲਾਕ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਨ ਡਿਫਾਲਟ control ਨੂੰ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਕਿ office ਆਪਣੇ ਸਿੱਧੇ ਜੁੜੇ LAN ਲਈ ਪਹੁੰਚਯੋਗ ਰਹਿੰਦਾ ਹੈ।

services:
  vpn:
    networks:
      control:
        gw_priority: 1
      office:
        gw_priority: 0

networks:
  control:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.50.0/24
  office:
    driver: macvlan
    driver_opts:
      parent: eno1.120
      macvlan_mode: bridge
    ipam:
      config:
        - subnet: 192.168.120.0/24
          ip_range: 192.168.120.192/27
          gateway: 192.168.120.1

ਬਲਾਕ ਨੂੰ ਦੋ ਵੱਖਰੇ ਨਿਯੰਤਰਣਾਂ ਵਜੋਂ ਪੜ੍ਹੋ: gw_priority ਡਿਫਾਲਟ ਰੂਟ ਤੈਅ ਕਰਦਾ ਹੈ, ਅਤੇ ipam ਭਾਗ ਪਤਾ ਤੈਅ ਕਰਦਾ ਹੈ। ਸਿਰਫ਼ subnet ਬਦਲਣ ਨਾਲ ਨਿਕਾਸ ਦੀ ਚੋਣ ਅਛੂਤੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਸੁਧਾਰ ਅੱਧਾ ਲਾਗੂ ਹੋਣ ਦਾ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ। ਤਰਜੀਹਾਂ ਨੂੰ ਉਸ ਨੈੱਟਵਰਕ ਦੇ ਕੋਲ ਰੱਖੋ ਜਿਸ 'ਤੇ ਉਹ ਰਾਜ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ ਅਗਲੇ ਪਾਠਕ ਨੂੰ ਫ਼ੈਸਲਾ ਲੱਭਣਾ ਨਾ ਪਵੇ।

gw_priority ਨੂੰ ਕੋਲ ਦੀ ਸਾਧਾਰਨ priority ਵਿਸ਼ੇਸ਼ਤਾ ਨਾਲ ਨਾ ਮਿਲਾਓ। ਉਹ ਕਨੈਕਸ਼ਨ ਬਣਾਉਣ ਦਾ ਕ੍ਰਮ ਤੈਅ ਕਰਦੀ ਹੈ ਅਤੇ ਰੂਟਿੰਗ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ, ਇਸ ਲਈ ਉਹ ਡਿਫਾਲਟ ਗੇਟਵੇ ਨਹੀਂ ਚੁਣ ਸਕਦੀ ਅਤੇ ਇੰਟਰਫੇਸ ਦੇ ਨਾਮ ਨਹੀਂ ਸੁਧਾਰਦੀ। ਜੇ ਕੋਈ ਟ੍ਰੈਫ਼ਿਕ ਮੋੜਨ ਲਈ priority ਵਧਾਉਣ ਦੀ ਸਲਾਹ ਦੇਵੇ, ਤਾਂ ਨਤੀਜੇ ਵਜੋਂ ਮਿਲਿਆ ਕ੍ਰਮ ਇਤਫ਼ਾਕਨ ਸਹੀ ਲੱਗੇ ਤਾਂ ਵੀ ਸਲਾਹ ਗਲਤ ਹੈ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਨੈੱਟਵਰਕ ਡਿਫਾਲਟ ਰੂਟ ਢੋਂਦਾ ਹੈ

ਚੱਲ ਰਹੇ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਹੋਸਟ ਦੀ ਰੂਟਿੰਗ ਟੇਬਲ ਹੋਸਟ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ, ਸੇਵਾ ਜੋ ਨੇਮਸਪੇਸ ਵਰਤਦੀ ਹੈ ਉਸ ਦਾ ਨਹੀਂ। ਪਹਿਲਾਂ ਕਾਨਫਿਗ ਜਾਂਚ ਚਲਾਓ ਤਾਂ ਜੋ ਟਾਈਪੋ ਰੀਸਟਾਰਟ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਫੜਿਆ ਜਾਵੇ, ਫਿਰ ਕੰਟੇਨਰ ਵੱਲੋਂ ਅਸਲ ਵਿੱਚ ਸਥਾਪਿਤ ਕੀਤਾ ਰੂਟ ਪੜ੍ਹੋ।

docker compose config --quiet
docker exec vpn ip -4 route show default
docker exec vpn cat /proc/net/route

ਸਹੀ ਨਤੀਜਾ ਬ੍ਰਿਜ ਡਿਵਾਈਸ ਅਤੇ 172.30.50.1 ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ; ਗਲਤ ਨਤੀਜਾ 192.168.120.1 ਅਤੇ macvlan ਡਿਵਾਈਸ ਦਾ। ਜੇ ਇਮੇਜ ਵਿੱਚ iproute2 ਪੈਕੇਜ ਨਹੀਂ ਹੈ, ਤਾਂ /proc ਫ਼ਾਈਲ ਫਿਰ ਵੀ ਡਿਫਾਲਟ ਰੂਟ ਦੱਸਦੀ ਹੈ, ਮੰਜ਼ਿਲ 00000000 ਅਤੇ ਗੇਟਵੇ ਦੇ ਬਾਈਟ ਉਲਟੇ ਹੋਏ। ਜਦੋਂ ਡਿਵਾਈਸ ਨਾਮ ਸਪਸ਼ਟ ਨਾ ਹੋਣ ਤਾਂ ਇੰਟਰਫੇਸ ਕਾਲਮ ਦੀ docker inspect ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

macvlan ਇੱਕ ਭੌਤਿਕ ਪੋਰਟ ਹੈ, ਬ੍ਰਿਜ ਦੀ ਨਕਲ ਨਹੀਂ

macvlan ਕੰਟੇਨਰ ਨੂੰ ਤਾਰ 'ਤੇ ਦੂਜੀ ਪਛਾਣ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਸਥਾਨਕ ਡਿਵਾਈਸਾਂ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਕੰਮ ਕਰਾਉਂਦਾ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਸਵਿੱਚ ਪੋਰਟ ਅਤੇ ਹਾਈਪਰਵਾਈਜ਼ਰ ਨੂੰ ਵਾਧੂ MAC ਪਤਾ ਸਵੀਕਾਰ ਕਰਨਾ ਪਵੇਗਾ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਕਲਾਉਡ ਨੈੱਟਵਰਕ ਇਸ ਨੂੰ ਚੁੱਪਚਾਪ ਮਨ੍ਹਾਂ ਕਰ ਦਿੰਦੇ ਹਨ। ਫਲੀਟ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਕੰਟੇਨਰ ਟੈਸਟ ਕਰੋ, ਕਿਉਂਕਿ ਅਸਵੀਕਾਰਿਆ MAC ਆਮ ਤੌਰ 'ਤੇ ਉੱਪਰ ਚੱਲ ਰਹੀ ਪਰ ਕੁਝ ਨਾ ਲੰਘਾਉਣ ਵਾਲੀ ਲਿੰਕ ਵਜੋਂ ਦਿਸਦਾ ਹੈ।

macvlan_mode: bridge ਸੈਟਿੰਗ macvlan ਡਰਾਈਵਰ ਦਾ ਇੱਕ ਮੋਡ ਹੈ, Docker ਦਾ ਸਾਫ਼ਟਵੇਅਰ ਬ੍ਰਿਜ ਨਹੀਂ, ਅਤੇ passthru ਡਿਫਾਲਟ ਨਹੀਂ ਸਗੋਂ ਵੱਖਰਾ ਵਿਸ਼ੇਸ਼ ਮੋਡ ਹੈ। Linux macvlan ਕੰਟੇਨਰ ਨੂੰ ਆਪਣੇ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਵੀ ਰੋਕਦਾ ਹੈ ਉਸੇ ਪੇਰੈਂਟ ਰਾਹੀਂ, ਅਤੇ ਇਸੇ ਲਈ ਕੰਟਰੋਲ ਬ੍ਰਿਜ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਕਨੈਕਸ਼ਨ ਦੋਵੇਂ ਕੰਮ ਕਰੇਗਾ ਇਸ ਉਮੀਦ ਦੀ ਥਾਂ।

Compose ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ VLAN ਪੇਰੈਂਟ ਦਾ ਨਾਮ ਦਿਓ

Docker eno1.120 ਵਰਗੇ ਬਿੰਦੂ ਵਾਲੇ ਪੇਰੈਂਟ ਨੂੰ 802.1Q ਸਬ-ਇੰਟਰਫੇਸ ਮੰਨਦਾ ਹੈ ਅਤੇ VLAN ਡਿਵਾਈਸ ਆਪ ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਸੁਵਿਧਾ ਦੀਆਂ ਹੱਦਾਂ ਹਨ: ਬਣਿਆ ਨਾਮ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਦੇ ਨਾਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਲੰਮੇ ਨਾਮ ਨਤੀਜੇ ਨੂੰ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਟੂਲਾਂ ਦੀ ਉਮੀਦ ਤੋਂ ਅੱਗੇ ਧੱਕ ਸਕਦੇ ਹਨ। ਹੋਸਟ ਦੇ ਨੈੱਟਵਰਕ ਕਾਨਫਿਗ ਵਿੱਚ ਨਾਮ ਵਾਲਾ VLAN ਇੰਟਰਫੇਸ ਬਣਾ ਕੇ parent ਨੂੰ ਉਸ ਵੱਲ ਦਿਖਾਉਣ ਨਾਲ ਦੋਵੇਂ ਸਿਰੇ ਅਨੁਮਾਨਯੋਗ ਰਹਿੰਦੇ ਹਨ।

ਯਾਦ ਰੱਖੋ ਕਿ networks ਹੇਠਾਂ ਕੁੰਜੀ Compose ਨਾਮ ਹੈ, Linux ਡਿਵਾਈਸ ਨਹੀਂ। ਹੋਸਟ 'ਤੇ office ਨਾਮ ਦਾ ਇੰਟਰਫੇਸ ਲੱਭਣਾ ਫੇਲ੍ਹ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਕਰਨਲ ਸਿਰਫ਼ ਪੇਰੈਂਟ ਇੰਟਰਫੇਸ ਅਤੇ ਕੰਟੇਨਰ ਪਿੱਛੇ ਦੀ veth ਜੋੜੀ ਦੇਖਦਾ ਹੈ।

ਉੱਤੇ VPN ਲਈ ਥਾਂ ਬਣਾਓ

VPN ਕਲਾਇੰਟ ਇਹ ਨੈੱਟਵਰਕ ਬਣਨ ਤੋਂ ਬਾਅਦ ਜੁੜਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ gw_priority ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਵਧੇਰੇ ਖ਼ਾਸ ਰੂਟ, ਨੀਤੀ ਨਿਯਮ ਅਤੇ ਫਿਲਟਰ ਜੋੜ ਸਕਦਾ ਹੈ। ਦੂਰ ਦੇ ਪ੍ਰੀਫਿਕਸ ਦੀ ਯੋਜਨਾ ਦੋਵਾਂ ਸਥਾਨਕ subnetਾਂ ਦੇ ਮੁਕਾਬਲੇ ਕਰੋ, ਕੰਟਰੋਲ ਰਾਹ ਨੂੰ ਲੋੜੀਂਦੇ ਜਵਾਬਾਂ ਸਮੇਤ। ਜਦੋਂ ਦੂਰ ਦਾ ਪ੍ਰੀਫਿਕਸ ਆਫ਼ਿਸ LAN ਨਾਲ ਓਵਰਲੈਪ ਹੋਵੇ, ਤਾਂ ਪੂਰੀ ਪ੍ਰਾਈਵੇਟ ਰੇਂਜ ਟਨਲ ਵਿੱਚੋਂ ਖਿੱਚਣ ਦੀ ਥਾਂ ਪਤਾ ਯੋਜਨਾ ਸੁਧਾਰੋ।

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