ಎರಡು ನೆಟ್‌ವರ್ಕ್‌ಗಳಿರುವ ಕಂಟೇನರ್ ತಪ್ಪು ಗೇಟ್‌ವೇ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ

ನಿಮ್ಮ ಕಂಟೇನರ್ ಇನ್ನೂ ತನ್ನ ನಿಯಂತ್ರಣ ಸೇತುವೆಯಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರತಿ ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ ಕಚೇರಿ 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 ಸಂರಚನೆ ತನ್ನದೇ ನೀತಿಯನ್ನು ಮಾತ್ರ ಹೊಂದಿರಲಿ.