VPN-ನಲ್ಲಿ Docker ಕಂಟೇನರ್ ತಲುಪಲಾಗುತ್ತಿಲ್ಲವೇ? ಸಬ್ನೆಟ್‌ಗಳನ್ನು ಹೋಲಿಸಿ

Docker VPN ಕೂಡ ಕ್ಲೇಮ್ ಮಾಡುವ ಸಬ್ನೆಟ್ ನೀಡುತ್ತದೆ. ಎರಡು ವಿಳಾಸ ಯೋಜನೆಗಳನ್ನು ಹೋಲಿಸಿ, ಮರುಸಂಪರ್ಕಕ್ಕೆ ಉಳಿಯುವ ದುರಸ್ತಿಯನ್ನು ಆರಿಸಿ.

ಕಂಟೇನರ್‌ಗಳು ಕಚೇರಿ LAN ನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತವೆ, ನಂತರ ಕಂಪನಿ VPN ಸಂಪರ್ಕಗೊಂಡ ಕ್ಷಣದಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ. ಕಂಟೇನರ್‌ನಲ್ಲಿ ಏನೂ ಬದಲಾಗಿಲ್ಲ: ಮರುಪ್ರಾರಂಭವಿಲ್ಲ, ಇಮೇಜ್ ನವೀಕರಣವಿಲ್ಲ, ಕಾನ್ಫಿಗ್ ತಿದ್ದುಪಡಿಯಿಲ್ಲ. ಬದಲಾಗಿದ್ದು ಹೋಸ್ಟ್ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ, ಅಲ್ಲಿ ಟನೆಲ್ ಸೇರಿಸಿದ ರೂಟ್ ಈಗ Docker ನೀಡಿದ ವಿಳಾಸವನ್ನು ಆವರಿಸುತ್ತದೆ. ಸಬ್ನೆಟ್ ತಿದ್ದುವ ಅಥವಾ VPN ಹೊರಗಿಡುವಿಕೆ ಕೇಳುವ ಮೊದಲು ಎರಡು ವಿಳಾಸ ಯೋಜನೆಗಳನ್ನು ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ದುರಸ್ತಿಗಳು ಬಹಳ ವಿಭಿನ್ನ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ.

ಕಾನ್ಫಿಗ್ ಬದಲಿಸುವ ಮೊದಲು ರೂಟ್ ಓದಿ

Docker ನಿಜವಾಗಿ ನಿರ್ಮಿಸಿದ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ. IPAM ಬ್ಲಾಕ್ ವಿಳಾಸ ಯೋಜನೆ, ಮತ್ತು ಸಬ್ನೆಟ್ ಮುಖ್ಯವಾದ ಸಾಲು:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Compose ಡೀಫಾಲ್ಟ್ ಆಗಿ ಪ್ರತಿ ಹೊಸ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ /16 ಹಂಚುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡು ಸೇವೆಗಳು 65,536 ವಿಳಾಸಗಳ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಇರಬಹುದು. ಆ ಅಗಲವೇ ಓವರ್‌ಲ್ಯಾಪ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿಸುತ್ತದೆ: ಯಾದೃಚ್ಛಿಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ /16 ಟನೆಲ್ ಮೂಲಕ ತಲುಪುವ ಸೈಟ್ ಅನ್ನು ನುಂಗಲು ಸಾಕಷ್ಟು ದೊಡ್ಡದು, ಮತ್ತು ಟನೆಲ್ ಬರುವವರೆಗೆ ಯಾರೂ ಗಮನಿಸುವುದಿಲ್ಲ.

ನಂತರ ಒಂದು ಕಂಟೇನರ್ ವಿಳಾಸಕ್ಕೆ ರೂಟ್ ಆಯ್ಕೆಯನ್ನು ಹೋಲಿಸಿ — ಒಮ್ಮೆ ಟನೆಲ್ ಆಫ್ ಇದ್ದಾಗ, ಒಮ್ಮೆ ಆನ್ ಇದ್ದಾಗ:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

ಉತ್ತರದ ಎರಡು ರೂಪಗಳು ಬೇರೆ ಬೇರೆ ಕಡೆ ಕರೆದೊಯ್ಯುತ್ತವೆ. ಔಟ್‌ಪುಟ್ tun0, wg0 ಅಥವಾ ಇನ್ನೊಂದು ಟನೆಲ್ ಸಾಧನವನ್ನು ಹೆಸರಿಸಿದರೆ, VPN ಪ್ರಿಫಿಕ್ಸ್ ಕನಿಷ್ಠ ಬ್ರಿಡ್ಜ್ ರೂಟ್‌ನಷ್ಟೇ ನಿರ್ದಿಷ್ಟವಾಗಿದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಕಂಟೇನರ್ ತಲುಪುವುದೇ ಇಲ್ಲ. ಅದು ಇನ್ನೂ ಬ್ರಿಡ್ಜ್ ಹೆಸರಿಸಿದರೆ, ಹೋಸ್ಟ್ ಕಂಟೇನರ್ ತಲುಪಬಲ್ಲದು, ಮತ್ತು ನಿಮ್ಮ ದೋಷ ಫಿಲ್ಟರಿಂಗ್, DNS, ಅಥವಾ ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ವಿಫಲವಾಗುವ ಹಿಂತಿರುಗು ಮಾರ್ಗ.

/16 ಘರ್ಷಣೆ ಸುಲಭವಾಗಿ ಏಕೆ ಸಂಭವಿಸುತ್ತದೆ

Docker ಬ್ರಿಡ್ಜ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಖಾಸಗಿ ಪೂಲ್‌ಗಳಿಂದ ಎಳೆಯುತ್ತದೆ, ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಪೂಲ್ 172.16.0.0/12 ಬ್ಲಾಕ್‌ನಿಂದ /16 ತುಣುಕುಗಳಲ್ಲಿ ಬರುತ್ತದೆ. ಕಾರ್ಪೊರೇಟ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಆಗಾಗ್ಗೆ ಅದೇ ಖಾಸಗಿ ಜಾಗವನ್ನು ಬಳಸುತ್ತವೆ, ಮತ್ತು ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ VPN ಆ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುವ ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ತಳ್ಳುತ್ತದೆ. ಎರಡೂ ಕಡೆ 172.18.0.0/16 ತಮ್ಮದು ಎಂದು ನಂಬಿದಾಗ, ಒಂದು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಎರಡು ವಿರುದ್ಧ ಹಕ್ಕುಗಳು ಇರುತ್ತವೆ.

ಗೆದ್ದವರನ್ನು ನಿರ್ಧರಿಸುವುದು ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದ, ರೂಟ್‌ಗಳ ಕ್ರಮವಲ್ಲ. 10.0.0.0/8 ಅನ್ನು ತಳ್ಳುವ ಟನೆಲ್ 172.18.0.0/16 ನ ಬ್ರಿಡ್ಜ್ ರೂಟ್ ಅನ್ನು ಸೋಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ /8 ಕಡಿಮೆ ನಿರ್ದಿಷ್ಟ. 172.18.0.0/16, ಅಥವಾ 172.18.5.0/24 ಅದರ ಒಳಗೆ ಬರುವ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ತಳ್ಳುವ ಟನೆಲ್ ಸೋಲಿಸುತ್ತದೆ. ಅದಕ್ಕಾಗಿಯೇ ಒಂದು ಲ್ಯಾಪ್‌ಟಾಪ್ ಕಚೇರಿ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಅದೇ VPN ಜೊತೆ ಹೋಟೆಲ್ Wi-Fi ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ: ಕ್ಲೈಂಟ್ ಬೇರೆ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತದೆ.

ಅದೇ ಕೋಷ್ಟಕವು ಇನ್ನೊಂದು ದಿಕ್ಕನ್ನೂ ನಿಯಂತ್ರಿಸುತ್ತದೆ. 10.8.4.20 ನಲ್ಲಿ ಆಂತರಿಕ ಹೋಸ್ಟ್ ಬೇಕಾದ ಕಂಟೇನರ್ ತನ್ನ ಬ್ರಿಡ್ಜ್ ಗೇಟ್‌ವೇಗೆ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸುತ್ತದೆ, ನಂತರ ಹೋಸ್ಟ್ ಅದನ್ನು ಟನೆಲ್‌ಗೆ ರೂಟ್ ಮಾಡುತ್ತದೆ. ಆ ಮಾರ್ಗ ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ NAT ಅನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತದೆ, ಆದರೆ ಕಾರ್ಪೊರೇಟ್ ಕಡೆ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನ VPN ವಿಳಾಸವನ್ನು ಮಾತ್ರ ಒಪ್ಪಿಕೊಂಡಾಗ, ಅಥವಾ ರಿವರ್ಸ್-ಪಾತ್ ಫಿಲ್ಟರಿಂಗ್ ಅಸಮಮಿತ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಬಿಟ್ಟಾಗ ಅದು ವಿಫಲವಾಗುತ್ತದೆ.

ಮೂರು ದುರಸ್ತಿಗಳನ್ನು ಹೋಲಿಸಿ

ಹೊರಬರಲು ಮೂರು ದಾರಿಗಳಷ್ಟೇ ಇವೆ, ಮತ್ತು ಅವು ಯಾರು ಅನುಮೋದಿಸಬೇಕು ಹಾಗೂ ಅನ್ವಯಿಸುವಾಗ ಏನು ಮುರಿಯುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನವಾಗಿವೆ.

RepairWho owns itWhat it costs
Renumber the container networkYouRecreates the network, restarts services, invalidates literal addresses in configs and scripts
Exclude your range from the tunnelNetwork teamChanges what every laptop sees, needs a change request and a client profile update
Reach the service through a published portYou and the clientOne port only, no direct container-to-container routing across the tunnel

ಮರುಸಂಖ್ಯೆ ಮಾಡುವುದು ಟಿಕೆಟ್ ಇಲ್ಲದೆ ಮುಗಿಸಬಹುದಾದ ಏಕೈಕ ದುರಸ್ತಿ, ಆದ್ದರಿಂದ ಬಹುಪಾಲು ಬರಹಗಳು ಅಲ್ಲೇ ನಿಲ್ಲುತ್ತವೆ. ಹೊಸ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಅದು ಅಗ್ಗ, ಆದರೆ ಮೈಗ್ರೇಶನ್ ಸಾಧನ ಅಥವಾ ಸಂಗ್ರಹಿಸಿದ ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಅಕ್ಷರಶಃ ವಿಳಾಸವನ್ನು ಸೂಚಿಸಿದಾಗ ದುಬಾರಿ. YAML ತಿದ್ದುವ ಮೊದಲು ಆ ಉಲ್ಲೇಖಗಳನ್ನು ಎಣಿಸಿ, ನಂತರವಲ್ಲ.

ಟನೆಲ್‌ನಿಂದ ಹೊರಗಿಡುವುದು ನಿಮ್ಮ ಕಂಪನಿ ನಿಜವಾಗಿ ಹೊಂದಿರುವ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಓವರ್‌ಲ್ಯಾಪ್ ಇದ್ದಾಗ ಅತ್ಯಂತ ಸ್ವಚ್ಛ ಉತ್ತರ. ಅದು ಅತ್ಯಂತ ನಿಧಾನವೂ ಹೌದು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ ಬದಲಿಸಲಾಗದ ಗುತ್ತಿಗೆದಾರರಿಗೆ ನಿರುಪಯುಕ್ತ. ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಅಥವಾ ಸಣ್ಣ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ವಾದವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ: ಕ್ಲೈಂಟ್ ಟನೆಲ್ ಈಗಾಗಲೇ ಸರಿಯಾಗಿ ರೂಟ್ ಮಾಡುವ ವಿಳಾಸದೊಂದಿಗೆ ಮಾತನಾಡುತ್ತದೆ, ಮತ್ತು ಆ ಪೋರ್ಟ್ ಮಾತ್ರ ತಲುಪಬಲ್ಲದಾಗಿರಬೇಕು.

ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ವ್ಯಾಪ್ತಿಯನ್ನು ಪಿನ್ ಮಾಡಿ

ಒಂದೇ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ, compose ಫೈಲ್‌ನಲ್ಲಿ ಸಬ್ನೆಟ್ ಘೋಷಿಸಿ, ಇದರಿಂದ ಪ್ರಾಜೆಕ್ಟ್ ಹಂಚಿದ ಪೂಲ್‌ನಿಂದ ಎಳೆಯುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

ಆ ವ್ಯಾಪ್ತಿಯನ್ನು ನಿಮ್ಮ ತಂಡ ಇಟ್ಟುಕೊಳ್ಳುವ ರಿಜಿಸ್ಟ್ರಿಯಿಂದ ತೆಗೆದುಕೊಳ್ಳಿ, ಹುಡುಕುವಾಗ ಕಂಡ ಉದಾಹರಣೆಯಿಂದ ಅಲ್ಲ. ಅದನ್ನು VPN ತಳ್ಳುವ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು, ಜನರು ಕೆಲಸ ಮಾಡುವ ಮನೆ LAN ಗಳು, ಮತ್ತು ಅದೇ ಹೋಸ್ಟ್‌ನ ಇತರ ಕಂಟೇನರ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಿ. ನಂತರ ಮರುಸೃಷ್ಟಿಯನ್ನು ಯೋಜಿಸಿ, ಏಕೆಂದರೆ ಇರುವ ನೆಟ್‌ವರ್ಕ್ ತನ್ನ ಹಳೆಯ ಸಬ್ನೆಟ್ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ: docker compose down, ನಂತರ up -d. docker network rm ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು ಜೋಡಣೆಯಾಗಿರುವಾಗ ನಿರಾಕರಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ipv4_address ನಮೂದು ಫೈಲ್‌ನಲ್ಲಿ ಹೊಸ ವ್ಯಾಪ್ತಿಯೊಳಗೆ ಬರಬೇಕು.

Docker ತಾನೇ ರಚಿಸುವ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ, ಡೀಮನ್ ಪೂಲ್ ಅನ್ನು /etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "10.201.0.0/16", "size": 24 },
    { "base": "10.202.0.0/16", "size": 24 }
  ]
}

ಪೂಲ್ ಡೀಮನ್ ಮರುಪ್ರಾರಂಭದ ನಂತರ ರಚಿಸಿದ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ, ಮತ್ತು ಈಗಾಗಲೇ ಇರುವ ಬ್ರಿಡ್ಜ್‌ಗಳು ತಮ್ಮ ವಿಳಾಸಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಅದು ಅನುಕೂಲಕರ ಮತ್ತು ಮರೆಯುವುದು ಸುಲಭ, ಆದ್ದರಿಂದ ಯಾರಾದರೂ ಅದರ ನೆಟ್‌ವರ್ಕ್ ಮರುಸೃಷ್ಟಿಸುವವರೆಗೆ ಹಳೆಯ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಇನ್ನೂ ಓವರ್‌ಲ್ಯಾಪ್ ಆಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಿ. Docker ನ ಎಂಜಿನ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ದಾಖಲೆ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಪೂಲ್ ಅನ್ನು ಸಮರ್ಥಿಸಬೇಕಾದರೆ ಹಂಚಿಕೆ ನಿಯಮಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

Linux ಬ್ರಿಡ್ಜ್ ಮತ್ತು Docker Desktop ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ

Linux ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಕಂಟೇನರ್‌ಗಳು ಹೋಸ್ಟ್ namespace ನಲ್ಲಿನ ಬ್ರಿಡ್ಜ್‌ಗಳ ಮೇಲೆ ಕುಳಿತುಕೊಳ್ಳುತ್ತವೆ. ಎಲ್ಲವನ್ನೂ ಒಂದು ಕೋಷ್ಟಕ ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೇಲಿನ ಹೋಲಿಕೆಯೇ ಪೂರ್ಣ ಕಥೆ: ಬ್ರಿಡ್ಜ್ ರೂಟ್ ಓದಿ, ಟನೆಲ್ ರೂಟ್ ಓದಿ, ಮತ್ತು ನಿಜವಾದ ಕಂಟೇನರ್ ವಿಳಾಸಕ್ಕೆ ಯಾವುದು ಗೆಲ್ಲುತ್ತದೆ ಎಂದು ನೋಡಿ.

Docker Desktop ಕಂಟೇನರ್‌ಗಳನ್ನು ತನ್ನದೇ NAT ಇರುವ VM ಹಿಂದೆ ಇಡುತ್ತದೆ. ಹೋಸ್ಟ್‌ಗೆ ಕಂಟೇನರ್ ವಿಳಾಸಕ್ಕೆ ರೂಟ್ ಇಲ್ಲವೇ ಇಲ್ಲ; ಅದು ಸೇವೆಯನ್ನು ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಮೂಲಕ ತಲುಪುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ 127.0.0.1 ಗೆ ಬಂಧಿಸಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ VPN ಕ್ಲೈಂಟ್ ಯಾವುದೇ ಸಬ್ನೆಟ್ ಓವರ್‌ಲ್ಯಾಪ್ ಇಲ್ಲದೆಯೂ ಸೇವೆಯನ್ನು ಮುರಿಯಬಹುದು: VM ನ ಆಂತರಿಕ ವ್ಯಾಪ್ತಿಗೆ ರೂಟ್ ಸ್ಥಾಪಿಸುವ ಮೂಲಕ, ಅಥವಾ ಟನೆಲ್ ಸಂಪರ್ಕದಲ್ಲಿರುವಾಗ loopback ಸಂಚಾರವನ್ನು ನಿರ್ಬಂಧಿಸುವ ಮೂಲಕ. ip route get ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಕಂಟೇನರ್ ವಿಳಾಸಕ್ಕೆ ರೂಟ್ ವರದಿ ಮಾಡದಿದ್ದರೆ, ಅದು ನಿರೀಕ್ಷಿತವೇ ಹೊರತು ದೋಷವಲ್ಲ.

ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮ ಎಂದರೆ ನೀವು ಮೊದಲು ಎಲ್ಲಿ ನೋಡುತ್ತೀರಿ. Linux ನಲ್ಲಿ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಿಂದ ಪ್ರಾರಂಭಿಸಿ. Desktop ನಲ್ಲಿ ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಮತ್ತು VPN ಕ್ಲೈಂಟ್‌ನ firewall ನಿಯಮಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ VM ನ ಆಂತರಿಕ ಸಬ್ನೆಟ್ ಟನೆಲ್ ತಳ್ಳುವ ಯಾವುದನ್ನಾದರೂ ಘರ್ಷಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಟನೆಲ್ ಆನ್ ಇದ್ದಾಗ ಪರಿಶೀಲಿಸಿ

ಸರಿಪಡಿಸಲಾಗಿದೆ ಎಂದು ಹೇಳುವ ಮೊದಲು VPN ಅನ್ನು ಎರಡು ಬಾರಿ ಮರುಸಂಪರ್ಕಿಸಿ, ಏಕೆಂದರೆ ಸಂಪರ್ಕದಲ್ಲಿ ರೂಟ್‌ಗಳನ್ನು ತಳ್ಳಿ ಸಂಪರ್ಕ ಕಡಿತದಲ್ಲಿ ಹಿಂಪಡೆಯುವ ಪ್ರೊಫೈಲ್ ಮೊದಲ ಪ್ರಯತ್ನದ ನಂತರ ಸರಿಯಾಗಿ ಕಾಣಬಹುದು. ನಂತರ ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ನಡೆಸುವ ಪರಿಶೀಲನೆಗಳನ್ನು ಚಲಾಯಿಸಿ:

  1. ip route get ಹೋಸ್ಟ್‌ನಿಂದ, ಕಂಟೇನರ್‌ನ ನಿಜವಾದ ವಿಳಾಸ ಬಳಸಿ.
  2. ಸೇವೆಯೇ ಆರೋಗ್ಯವಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಲು ಇನ್ನೊಂದು ಕಂಟೇನರ್‌ನಿಂದ ವಿನಂತಿ.
  3. curl -sv http://127.0.0.1:8080/ ಟನೆಲ್ ಆನ್ ಇದ್ದಾಗ ಕ್ಲೈಂಟ್‌ನಿಂದ, ನಂತರ traceroute -n LAN ನಲ್ಲಿನ ಯಂತ್ರದಿಂದ ಕಂಟೇನರ್ ವಿಳಾಸಕ್ಕೆ.
  4. sysctl net.ipv4.conf.all.rp_filter ವಿನಂತಿ ಹೋಸ್ಟ್ ತಲುಪಿ ಪ್ರತಿಕ್ರಿಯೆ ಮಾಯವಾದರೆ.

ಕೊನೆಯದಾಗಿ, ಆಯ್ಕೆ ಮಾಡಿದ ವ್ಯಾಪ್ತಿಯನ್ನು ಅದನ್ನು ಆರಿಸಲು ಬಳಸಿದ ಅದೇ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ದಿನಾಂಕ ಮತ್ತು ಅದನ್ನು ಹೊಂದಿರುವ ಪ್ರಾಜೆಕ್ಟ್ ಜೊತೆ ಬರೆಯಿರಿ. ಮುಂದಿನ ಓವರ್‌ಲ್ಯಾಪ್ ಯಾರೂ ದಾಖಲಿಸದ ಪ್ರಾಜೆಕ್ಟ್‌ನಿಂದ ಬರುತ್ತದೆ, ಮತ್ತು ಏಕೈಕ ರಕ್ಷಣೆ ಎಂದರೆ ವ್ಯಾಪ್ತಿಯನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಅಲ್ಲ, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕಾಯ್ದಿರಿಸಿದ್ದು.

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