VPN ಕಂಟೇನರ್ನಲ್ಲಿ NET_ADMIN: ಅದು ಏನನ್ನು ಮತ್ತು ಎಲ್ಲಿ ಬದಲಾಯಿಸಬಹುದು

NET_ADMIN ಲಿನಕ್ಸ್ ಸಾಮರ್ಥ್ಯವಾಗಿದ್ದು, ಅದು ಪ್ರಕ್ರಿಯೆಗೆ ನೆಟ್ವರ್ಕ್ ಆಡಳಿತ ನಡೆಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು ಕಂಟೇನರ್ನಲ್ಲಿ ಅದು ಪ್ರಕ್ರಿಯೆ ಚಲಿಸುವ ನೆಟ್ವರ್ಕ್ ನಾಮಸ್ಥಾನದ ಒಳಗೆ ನಿಖರವಾಗಿ ಅದನ್ನೇ ಮಾಡುತ್ತದೆ. ಇದು ಸಾಕೆಟ್ ತೆರೆಯುವ ಪರವಾನಗಿ ಅಲ್ಲ, ಮತ್ತು ಸಾಧನ ಅಥವಾ ಮಾರ್ಗಕ್ಕೆ ಬದಲಿಯೂ ಅಲ್ಲ. ಆಸಕ್ತಿದಾಯಕ ಪ್ರಶ್ನೆ ಎಂದಿಗೂ ಸಾಮರ್ಥ್ಯ ನೀಡಲಾಗಿದೆಯೇ ಎಂಬುದಲ್ಲ, ಬದಲಾಗಿ ಯಾವ ನಾಮಸ್ಥಾನ ಬದಲಾವಣೆಯನ್ನು ಪಡೆಯುತ್ತದೆ ಎಂಬುದು.

ಸಾಮರ್ಥ್ಯ ಏನನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ

ತನ್ನ ನಾಮಸ್ಥಾನದ ಒಳಗೆ NET_ADMIN ಹೊಂದಿರುವ ಪ್ರಕ್ರಿಯೆ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಮೇಲೆ ಮತ್ತು ಕೆಳಗೆ ಮಾಡಬಹುದು, ವಿಳಾಸಗಳನ್ನು ನಿಗದಿಪಡಿಸಬಹುದು, ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ತೆಗೆಯಬಹುದು ಮತ್ತು ಫೈರ್ವಾಲ್ ನಿಯಮಗಳನ್ನು ಬರೆಯಬಹುದು, ಇದು capabilities(7) ಈ ಸಾಮರ್ಥ್ಯದ ಅಡಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುವ ಕ್ರಿಯೆಗಳ ಗುಂಪು. ಇದು ಕೆರ್ನೆಲ್ ಸಂಚಾರವನ್ನು ಹೇಗೆ ಸರತಿಗೆ ಸೇರಿಸಿ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುವ ಇಂಟರ್ಫೇಸ್ ಮಟ್ಟದ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನೂ ಸರಿಹೊಂದಿಸಬಹುದು. VPN ಕ್ಲೈಂಟ್ಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಆರಂಭದಲ್ಲಿ ಇವುಗಳಲ್ಲಿ ಕೆಲವು ಬೇಕಾಗುತ್ತವೆ ಮತ್ತು ನಂತರ ಬೇರೇನೂ ಬೇಕಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಹೆಚ್ಚಿನ ಇಮೇಜ್ಗಳು ಬಳಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ವ್ಯಾಪ್ತಿಯನ್ನು ಕೇಳುತ್ತವೆ.

ಆ ನಾಮಸ್ಥಾನದ ಹೊರಗಿನ ಕ್ರಿಯೆಗಳು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ಪಕ್ಕದ ಸವಲತ್ತುಗಳು ಪ್ರತ್ಯೇಕ. ಕಚ್ಚಾ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಓದುವುದು ಮತ್ತು ಬರೆಯುವುದು NET_RAW ಗೆ ಸೇರಿದ್ದು, ಮತ್ತು tun ಸಾಧನವನ್ನು ರಚಿಸಲು ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಸಾಧನ ನೋಡ್ಗೆ ಪ್ರವೇಶ ಎರಡೂ ಬೇಕು. ಸಾಧನವಿಲ್ಲದ ಪ್ರಕ್ರಿಯೆಗೆ ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವ ಆದರೆ ಅಲ್ಲದ ಅನುಮತಿ ದೋಷ ಸಿಗುತ್ತದೆ.

ನಾಮಸ್ಥಾನ ಹಾನಿಯ ತ್ರಿಜ್ಯವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ

ತನ್ನ ಸ್ವಂತ ಬ್ರಿಡ್ಜ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿರುವ ಕಂಟೇನರ್ ತನ್ನ ಸ್ವಂತ loopback, ತನ್ನ ಇಂಟರ್ಫೇಸ್ಗಳು ಮತ್ತು ತನ್ನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ತಲುಪುತ್ತದೆ. ಅಲ್ಲಿ NET_ADMIN ನೀಡಿದರೆ VPN ಕ್ಲೈಂಟ್ ಹೋಸ್ಟ್ನ ರೂಟಿಂಗ್ ನಿರ್ಧಾರಗಳನ್ನು ಮುಟ್ಟದೆ ಸುರಂಗ ನಿರ್ಮಿಸಬಹುದು, ಇದು ಹೆಚ್ಚಿನ ಕಂಟೇನರ್ ಇಮೇಜ್ಗಳು ಊಹಿಸುವ ವ್ಯವಸ್ಥೆ.

ಆ ಕಂಟೇನರ್ ಅನ್ನು ಹೋಸ್ಟ್ ನೆಟ್ವರ್ಕಿಂಗ್ಗೆ ಬದಲಿಸಿ ಮತ್ತು ಅದೇ ಅನುಮತಿ ಈಗ ಹೋಸ್ಟ್ನ ಮಾರ್ಗಗಳು ಮತ್ತು ಹೋಸ್ಟ್ನ ಫೈರ್ವಾಲ್ ಅನ್ನು ಸಂಪಾದಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರತ್ಯೇಕ ನಾಮಸ್ಥಾನ ಉಳಿದಿಲ್ಲ. ಒಂದು ಸುರಂಗ ನಿರ್ವಹಿಸಬೇಕಿದ್ದ ಕ್ಲೈಂಟ್ ಇಡೀ ಯಂತ್ರದ ಸಂಚಾರವನ್ನು ಮರುನಿರ್ದೇಶಿಸಬಹುದು, ಮತ್ತು ಅದರ ತೆಗೆಯುವ ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿನ ತಪ್ಪು ಹೋಸ್ಟ್ನಲ್ಲಿ ಯಾರೂ ಬರೆಯದ ನಿಯಮಗಳನ್ನು ಬಿಟ್ಟುಹೋಗುತ್ತದೆ. ಸಾಮರ್ಥ್ಯದಲ್ಲೇ ಏನೂ ಬದಲಾಗಲಿಲ್ಲ; ಸಂದರ್ಭ ಬದಲಾಯಿತು. ಅದೇ compose ಕಡತ ಎರಡು ಹೋಸ್ಟ್ಗಳಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುವುದಕ್ಕೆ ಇದೇ ಕಾರಣ.

ಒಂದಾಗಿ ಸೇರಿಸಲಾಗುವ ಮೂರು ಪೂರ್ವಾಪೇಕ್ಷೆಗಳು

VPN ಕಂಟೇನರ್ಗಳಲ್ಲಿನ ಆರಂಭಿಕ ವೈಫಲ್ಯಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಮೂರು ಪ್ರತ್ಯೇಕ ವಿಷಯಗಳಲ್ಲಿ ಒಂದನ್ನು ಒಳಗೊಳ್ಳುತ್ತವೆ: ಸಾಮರ್ಥ್ಯ, ಸುರಂಗ ಸಾಧನ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ಗೆ ಕೆರ್ನೆಲ್ ಬೆಂಬಲ. ಮೂರನ್ನೂ ಒಟ್ಟಿಗೆ ನೀಡುವುದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ವೈಫಲ್ಯವನ್ನು ಆರೋಪಿಸಲು ಅಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ಕನಿಷ್ಠ compose ತುಣುಕು ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಸಾಧನ ನೋಡ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ರವಾನಿಸುತ್ತದೆ:

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

ಯಾವ sysctl ಬೇಕು ಎಂದು ಇಮೇಜ್ನ ಸ್ವಂತ ದಾಖಲೆಗಳಲ್ಲಿ ಓದಿ, ಏಕೆಂದರೆ ಕಂಟೇನರ್ನಲ್ಲಿನ sysctl ಹೆಚ್ಚುವರಿ ಸವಲತ್ತು ಅಥವಾ ಹೋಸ್ಟ್ ಮಟ್ಟದ ಸೆಟ್ಟಿಂಗ್ ಬೇಕಾಗಬಹುದು. ಇಮೇಜ್ ಕೇವಲ ಬಳಕೆದಾರ ಸ್ಥಳ ಕ್ರಮವನ್ನು ಬೆಂಬಲಿಸುವಲ್ಲಿ ಸಾಧನವೇ ಬೇಕಿಲ್ಲ ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳ ಪಟ್ಟಿ ಅದಕ್ಕನುಗುಣವಾಗಿ ಕುಗ್ಗುತ್ತದೆ.

ಕ್ರಮವನ್ನಲ್ಲ, ಸಂಕುಚಿತ ಕ್ರಿಯೆಯನ್ನು ನೀಡಿ

ವಿಶೇಷ ಸವಲತ್ತಿನ ಕ್ರಮವು ಪ್ರತಿ ಸಾಮರ್ಥ್ಯವನ್ನು ಒಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಸಾಧನ ಪ್ರವೇಶವನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೂರು ಪೂರ್ವಾಪೇಕ್ಷೆಗಳಲ್ಲಿ ಯಾವುದು ಕೊರತೆಯಿತ್ತು ಎಂಬುದನ್ನು ಮರೆಮಾಡುತ್ತದೆ. ಅದು ಕಂಟೇನರ್ನ ವೈಫಲ್ಯ ವಿಧಾನಗಳನ್ನು ಹೋಸ್ಟ್ ಬದಲಾವಣೆಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾಗದಂತೆ ಮಾಡುತ್ತದೆ. ಬರೆಯಲು ಉದ್ದವಾದರೂ ಸ್ಪಷ್ಟ ಪಟ್ಟಿಗೆ ಆದ್ಯತೆ ನೀಡಿ.

ರೂಟ್ಲೆಸ್ ಮತ್ತು ಬಳಕೆದಾರ ನಾಮಸ್ಥಾನ ನಿಯೋಜನೆಗಳು ಸಾಮರ್ಥ್ಯದ ಪ್ರಾಯೋಗಿಕ ಅರ್ಥವನ್ನು ಬದಲಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಪ್ರಕ್ರಿಯೆ ಅದನ್ನು ಮ್ಯಾಪ್ ಮಾಡಿದ ನಾಮಸ್ಥಾನದ ಒಳಗೆ ಮಾತ್ರ ಹೊಂದಿರಬಹುದು. ರೂಟ್ಫುಲ್ ಉದಾಹರಣೆಯಿಂದ ಸಾಮರ್ಥ್ಯಗಳ ಪಟ್ಟಿಯನ್ನು ರೂಟ್ಲೆಸ್ ರನ್ಟೈಮ್ಗೆ ನಕಲಿಸಿ ಅದೇ ವ್ಯಾಪ್ತಿಯನ್ನು ನಿರೀಕ್ಷಿಸುವುದು ಮಧ್ಯಾಹ್ನವನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಸಾಮಾನ್ಯ ದಾರಿ.

ರಹಸ್ಯಗಳು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಕ್ಕೆ ಸೇರಿದ್ದವು. NET_ADMIN ಹೊಂದಿರುವುದು ಕ್ಲೈಂಟ್ ಯಾವ ಪೀರ್ ಗುರುತನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ, ಯಾವ ರುಜುವಾತುಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ ಅಥವಾ ಅವು ಹೇಗೆ ತಿರುಗಿಸಲ್ಪಡುತ್ತವೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ನೆಟ್ವರ್ಕ್ ಆಡಳಿತ ವಿಶ್ವಾಸವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ.

ಬದಲಾವಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಅನುಮತಿ ಏಕೆ ಇದೆ ಎಂದು ದಾಖಲಿಸಿ

ಸುರಂಗವನ್ನು ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಕಂಟೇನರ್ಗೆ ನಿಜವಾಗಿ ಏನು ಸಿಕ್ಕಿತು ಎಂದು ದೃಢೀಕರಿಸಿ. ಕೆಳಗಿನ ಪರಿಶೀಲನೆ ಸೇರಿಸಿದ ಸಾಮರ್ಥ್ಯಗಳು ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಕ್ರಮವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ನಂತರ ಒಳಗಿನಿಂದ ಇಂಟರ್ಫೇಸ್ ಪಟ್ಟಿ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ:

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

ಸಾಮರ್ಥ್ಯ ಇದ್ದು ಇಂಟರ್ಫೇಸ್ ಪಟ್ಟಿ ಇನ್ನೂ ಖಾಲಿಯಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಏನನ್ನೂ ರಚಿಸುವ ಮೊದಲೇ ವಿಫಲವಾಗಿದೆ, ಮತ್ತು ಮುಂದೆ ನೋಡಬೇಕಾದ ಸ್ಥಳ ಕಂಟೇನರ್ ಲಾಗ್ಗಳು. ಸುರಂಗ ಇದ್ದು ಸಂಚಾರ ಹರಿಯದಿದ್ದರೆ, ಕಂಟೇನರ್ ಒಳಗಿನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಮುಂದಿನ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ.

ತೆಗೆಯುವ ಮಾರ್ಗವನ್ನೂ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳನ್ನು ಬರೆಯುವ ಕ್ಲೈಂಟ್ ಅವನ್ನು ಹಿಂದೆ ಬಿಡಬಹುದು. ಕಂಟೇನರ್ ನಿಲ್ಲಿಸಿ ಮತ್ತು ಹೋಸ್ಟ್ ನೆಟ್ವರ್ಕಿಂಗ್ ಬಳಕೆಯಲ್ಲಿದ್ದರೆ ಹೋಸ್ಟ್ನ ನಿಯಮ ಸಮೂಹವನ್ನು ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ. ಆರಂಭದಲ್ಲಿ ಕೇವಲ ಎರಡು ಸೆಕೆಂಡು ಬೇಕಾಗುವ ಅನುಮತಿಯನ್ನು ಅದನ್ನು ವಿವರಿಸುವ ಟಿಪ್ಪಣಿ ಇಲ್ಲದೆ compose ಕಡತದಲ್ಲಿ ಶಾಶ್ವತ ಅಗತ್ಯವಾಗಿ ವಿವರಿಸಬಾರದು.

ಪ್ರತಿ ಸಾಮರ್ಥ್ಯದ ಪಕ್ಕದಲ್ಲಿ ಕಾರಣ ಬರೆಯಿರಿ: ಯಾವ ಕ್ರಿಯೆಗೆ ಅದು ಬೇಕಿತ್ತು ಮತ್ತು ಅದಿಲ್ಲದೆ ಏನು ವಿಫಲವಾಗುತ್ತದೆ. ಆ ಟಿಪ್ಪಣಿ ಇಮೇಜ್ ನವೀಕರಣಗಳ ನಂತರವೂ ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಅದೇ ಪರಿಶೀಲಿಸಿದ ಸವಲತ್ತು ಪಟ್ಟಿ ಮತ್ತು ನಕಲಿಸಿ ಅಂಟಿಸಿ ಬೆಳೆದ ಪಟ್ಟಿಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸ.