VPN ಕಂಟೇನರ್ ಒಳಗಿನ ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ತಲುಪುವುದು: ಪೋರ್ಟ್ನ ಮಾಲೀಕರನ್ನು ಆಯ್ಕೆಮಾಡಿ

ಆ್ಯಪ್ನಲ್ಲಿ ಏನೂ ತಪ್ಪಿಲ್ಲ ಮತ್ತು ಸುರಂಗದಲ್ಲಿ ಏನೂ ತಪ್ಪಿಲ್ಲ, ಆದರೂ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ. ಸೇವೆಯು network_mode: service:vpn ಜೊತೆಗೆ ಚಲಿಸಿದಾಗ, ಅದು VPN ಕಂಟೇನರ್ನ ನೆಟ್ವರ್ಕ್ ನಾಮಸ್ಥಳವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ, ಅಂದರೆ ಅದರ ಶ್ರೋತೃ ಮತ್ತು ಪ್ರಕಟಿತ ಪೋರ್ಟ್ಗಳು ಸೇವೆಗೆ ಅಲ್ಲ, ಆ ನಾಮಸ್ಥಳಕ್ಕೆ ಸೇರಿವೆ. ಇದರಿಂದ ಮೂರು ನಿರ್ಧಾರಗಳು ಬರುತ್ತವೆ: ಆ್ಯಪ್ ಎಲ್ಲಿ ಬಂಧಿಸುತ್ತದೆ, ಯಾವ ಕಂಟೇನರ್ ಪೋರ್ಟ್ ಪ್ರಕಟಿಸುತ್ತದೆ ಮತ್ತು ನಿರ್ವಹಣಾ ಮಾರ್ಗ ಎಷ್ಟು ಸಂಕುಚಿತವಾಗಿದೆ. ಅವನ್ನು ತಪ್ಪು ಕ್ರಮದಲ್ಲಿ ಮಾಡಿದರೆ ಪ್ರತಿ ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಸಂಯೋಜನೆ ಕೆಲಸ ಮಾಡಲಾರದು.

ಪೋರ್ಟ್ ನಾಮಸ್ಥಳ ಯಾರಿಗೆ ಸೇರಿದೆ

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

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

ಮ್ಯಾಪಿಂಗ್ನ ಎಡಭಾಗದಲ್ಲಿರುವ ವಿಳಾಸವನ್ನು ಗಮನಿಸಿ. 127.0.0.1 ಗೆ ಬಂಧಿಸುವುದರಿಂದ ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಹೋಸ್ಟ್ನ ಲೂಪ್ಬ್ಯಾಕ್ನಲ್ಲಿ ಉಳಿಯುತ್ತದೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್ ಬಯಸುವುದು. 0.0.0.0 ಗೆ ಬಂಧಿಸುವುದರಿಂದ ಅದು ಹೋಸ್ಟ್ನ ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ತೆರೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಇದು ಅನುಕೂಲವಲ್ಲ, ಬೇರೆ ಭದ್ರತಾ ನಿರ್ಧಾರ.

ನಾಮಸ್ಥಳ ನಿರೀಕ್ಷಿಸುವ ಸ್ಥಳದಲ್ಲಿ ಆ್ಯಪ್ ಕೇಳಲಿ

ನಾಮಸ್ಥಳದ ಒಳಗೆ 127.0.0.1 ಗೆ ಬಂಧಿತ ಶ್ರೋತೃವು ಆ ನಾಮಸ್ಥಳದ ಒಳಗಿನಿಂದ ಮಾತ್ರ ತಲುಪಬಹುದು. ಪ್ರಕಟಿತ ಹೋಸ್ಟ್ ಪೋರ್ಟ್ಗಳು ಹೊರಗಿನಿಂದ ಬರುತ್ತವೆ, ಆದ್ದರಿಂದ ಮ್ಯಾಪಿಂಗ್ ಕೆಲಸ ಮಾಡಲು ಆ್ಯಪ್ ವಿಶಾಲ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸಬೇಕು. ಇದು ಬಹುಪಾಲು ಸರ್ವರ್ಗಳಲ್ಲಿ ಒಂದು ಸಾಲಿನ ಬದಲಾವಣೆ, ಮತ್ತು ಕಂಟೇನರ್ ಇಲ್ಲದ ನಿಯೋಜನೆಗಾಗಿ ಬರೆದ ಗಟ್ಟಿಗೊಳಿಸುವ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ನಕಲಿಸಿದ ನಂತರ ಜನರು ಬಿಟ್ಟುಬಿಡುವ ಹಂತ ಇದೇ.

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

ಆ್ಯಪ್ನ ಒಳಗಿನ ಶ್ರೋತೃ ಪಟ್ಟಿ ಬಂಧಿತ ವಿಳಾಸದ ಬಗ್ಗೆ ಸತ್ಯ ಹೇಳುತ್ತದೆ, ಮತ್ತು docker port ಮಾಲೀಕರು ನಿಜವಾಗಿ ಏನನ್ನು ಪ್ರಕಟಿಸಿದರು ಎಂದು ಹೇಳುತ್ತದೆ. ಮೊದಲನೆಯದು 127.0.0.1 ತೋರಿಸಿ ಎರಡನೆಯದು ಹೋಸ್ಟ್ ಮ್ಯಾಪಿಂಗ್ ತೋರಿಸಿದರೆ, VPN ಸಂರಚನೆಯನ್ನು ಮುಟ್ಟದೆಯೇ ನೀವು ಅಸಂಗತಿಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ.

ನಿರ್ವಹಣಾ ಮಾರ್ಗ ಹೇಗೆ ಒಳಬರಬೇಕೆಂದು ಆಯ್ಕೆಮಾಡಿ

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

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

ಎಲ್ಲವನ್ನೂ ತೆರೆಯದೆ ನಿರ್ವಹಣಾ ಪೋರ್ಟ್ ತೆರೆಯಿರಿ

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

ಆ್ಯಪ್ನ ಸ್ವಂತ ದೃಢೀಕರಣವನ್ನು ಆನ್ ಇರಿಸಿ. VPN ಗೆ ಸಂಪರ್ಕಿತ ಸ್ಟಾಕ್ನ ಒಳಗಿರುವುದು ಪ್ರತಿ ಸ್ಥಳೀಯ ಬಳಕೆದಾರರಿಗೆ ಅಥವಾ ಹೋಸ್ಟ್ ತಲುಪಬಲ್ಲ ಪ್ರತಿ ಸಾಧನಕ್ಕೆ ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಸುರಂಗದ ಹಿಂದಿನ ದೃಢೀಕರಣವಿಲ್ಲದ ನಿರ್ವಾಹಕ ಪ್ಯಾನೆಲ್ ಇನ್ನೂ ದೃಢೀಕರಣವಿಲ್ಲದ ನಿರ್ವಾಹಕ ಪ್ಯಾನೆಲ್ ಆಗಿದೆ.

ನಿರ್ವಹಣಾ ಸಾಧನದಿಂದ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ

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

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