Docker ಪೋರ್ಟ್ ಪ್ರಕಟಣೆ ಮತ್ತು VPN: ಉತ್ತರ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ

ಪ್ರಕಟಿಸಿದ ಕಂಟೇನರ್ ಹಿಮ್ಮುಖ NAT ಗಿಂತ ಮೊದಲು ತನ್ನದೇ ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸುತ್ತದೆ. ಎರಡು ವಿನ್ಯಾಸಗಳು ಆ ಉತ್ತರವನ್ನು ಸಾರ್ವಜನಿಕ ಮಾರ್ಗದಲ್ಲಿ ಇರಿಸಬಹುದು, ಬೇರೆ ಬೇರೆ ವೆಚ್ಚಗಳಲ್ಲಿ.

ಪೂರ್ಣ ಸುರಂಗದ VPN ಮೇಲೆ ಬಂದ ನಂತರವೂ ಹೋಸ್ಟ್ SSH ಗೆ ಉತ್ತರಿಸುತ್ತಲೇ ಇರುತ್ತದೆ, ಆದರೆ ಅದೇ ಯಂತ್ರದಲ್ಲಿ Docker ಮೂಲಕ ಪ್ರಕಟಿಸಿದ ಸೇವೆ ಮೌನವಾಗುತ್ತದೆ. ಆಲಿಸುವವರಲ್ಲಿ ಏನೂ ತಪ್ಪಿಲ್ಲ: ಕಂಟೇನರ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ಪೋರ್ಟ್ ಮ್ಯಾಪಿಂಗ್ ಇದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಬರುತ್ತದೆ. ಕಂಟೇನರ್ ಆರೋಗ್ಯವಾಗಿದೆ ಮತ್ತು ವಿನಂತಿ ನಿಜವಾಗಿಯೂ ಅದನ್ನು ತಲುಪುತ್ತದೆ. ವ್ಯತ್ಯಾಸವೆಂದರೆ Linux ತನ್ನ ಮಾರ್ಗವನ್ನು ಆರಿಸುವಾಗ ಉತ್ತರ ಎಲ್ಲಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದು, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸವೇ ಕೆಳಗಿನ ಎರಡು ವಿನ್ಯಾಸಗಳಲ್ಲಿ ನಿಮಗೆ ಯಾವುದು ಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಗಮ್ಯಸ್ಥಾನ NAT ಮೂಲಕ ಟ್ಯೂಪಲ್ ಅನ್ನು ಅನುಸರಿಸಿ

ಒಂದು ಹೋಸ್ಟ್ ತೆಗೆದುಕೊಳ್ಳಿ 192.0.2.10 ನಲ್ಲಿ, ಅದು TCP 2222 ಅನ್ನು 172.30.240.5:22 ನಲ್ಲಿರುವ ಕಂಟೇನರ್ಗೆ ಪ್ರಕಟಿಸುತ್ತದೆ. 198.51.100.25 ನಿಂದ ಬರುವ ವಿನಂತಿ ಕಂಟೇನರ್ ತಲುಪುವ ಮೊದಲು ಅನುವಾದಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಕಂಟೇನರ್ ತನ್ನಂತೆಯೇ ಉತ್ತರಿಸುತ್ತದೆ.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

ಹೋಸ್ಟ್ನ ಮಾರ್ಗ ನಿರ್ಧಾರದಲ್ಲಿ ಉತ್ತರವು ಇನ್ನೂ ಕಂಟೇನರ್ನ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೊರುತ್ತದೆ. ಹಿಮ್ಮುಖ ಅನುವಾದವು ಪ್ರಕಟಿಸಿದ ಟ್ಯೂಪಲ್ ಅನ್ನು ನಂತರ ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಮಾರ್ಗವನ್ನು ಆರಿಸುವ ಕ್ಷಣದಲ್ಲೇ ಪ್ಯಾಕೆಟ್ ತಪ್ಪಾಗಿ ಕಾಣುವುದಕ್ಕೆ ಅದೇ ಕಾರಣ.

ಹೋಸ್ಟ್ಗೆ ಮಾತ್ರ ಇರುವ ನಿಯಮ ಅದನ್ನು ಏಕೆ ತಪ್ಪಿಸುತ್ತದೆ

WAN ಕೋಷ್ಟಕವನ್ನು ಕೇವಲ 192.0.2.10 ನಿಂದ ಬರುವ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಆರಿಸುವ ನಿಯಮವು ಹೋಸ್ಟ್ನ ಸ್ವಂತ ಡೀಮನ್ಗಳನ್ನು ಆವರಿಸುತ್ತದೆ ಮತ್ತು ಈ ಮುಂದಕ್ಕೆ ರವಾನಿಸಿದ ಉತ್ತರವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸುತ್ತದೆ. ಉತ್ತರದಲ್ಲಿನ ಮೂಲ ವಿಳಾಸ 172.30.240.5, ಹೋಸ್ಟ್ ಅಲ್ಲ.

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

DNAT ನಂತರದ ಹೊಂದಾಣಿಕೆ ಬೇರೆ ಹುಕ್

Docker ನ ಫೈರ್ವಾಲ್ ದಾಖಲಾತಿ ಯು ಗಮನಿಸುವುದೇನೆಂದರೆ ಸಾಮಾನ್ಯ ಬಳಕೆದಾರ ಫಿಲ್ಟರಿಂಗ್ DNAT ನಂತರದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ ನಿಯಮದಲ್ಲಿ ಪ್ರಕಟಿಸಿದ ಪೋರ್ಟ್ 2222 ಅನ್ನು ಹೊಂದಿಸುವುದು ಕಂಟೇನರ್ ಪೋರ್ಟ್ 22 ಅನ್ನು ಹೊಂದಿಸುವುದಕ್ಕೆ ಸಮವಲ್ಲ. ಮೂಲ ಟ್ಯೂಪಲ್ ಮುಖ್ಯವಾದರೆ, ಯಾವ ಪೋರ್ಟ್ ಕಾಣುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಬೆಂಬಲಿತ ಮೂಲ-ಗಮ್ಯಸ್ಥಾನ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿ.

ಈ ಹುಕ್ ಗೊಂದಲವು ಸರಿಯಾಗಿ ಕಾಣುವ ಮತ್ತು ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗದ ನಿಯಮಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ನೀತಿಯನ್ನು ಮತ್ತೆ ಬರೆಯುವ ಮೊದಲು ನಿಯಮದ ಮೇಲೆಯೇ ಕೌಂಟರ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಶೂನ್ಯ ಹಿಟ್ ಇರುವ ನಿಯಮವು ಪ್ಯಾಕೆಟ್ ಎಂದಿಗೂ ತಲುಪದ ಸ್ಥಳದಲ್ಲಿ ಅದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತಿದೆ ಎಂದು ನಿಮಗೆ ಹೇಳುತ್ತದೆ.

ವಿನ್ಯಾಸ A: ನಿರ್ಧಾರವನ್ನು ಸಂಪರ್ಕ ಸ್ಥಿತಿಯಾಗಿ ಒಯ್ಯಿರಿ

ಸಂಪರ್ಕ ಮಾರ್ಕ್ ಒಳಬರುವ ನಿರ್ಧಾರವನ್ನು ಅನುವಾದದ ಮೂಲಕ ಒಯ್ಯಬಹುದು, ಆದರೆ ಮುಖ್ಯವಾದ ಮಾರ್ಗ ಹುಡುಕಾಟಕ್ಕೆ ಮೊದಲು ಅದನ್ನು ಪ್ಯಾಕೆಟ್ಗೆ ಮರುಸ್ಥಾಪಿಸಬೇಕು. ಹಂತಗಳು ಇವು:

  1. Docker, VPN ಅಥವಾ ಇನ್ನೊಂದು ನೀತಿ ಮಾಲೀಕರೊಂದಿಗೆ ಘರ್ಷಣೆಯಾಗದ ಮಾರ್ಕ್ ಕ್ಷೇತ್ರ ಮತ್ತು ನಿಯಮ ಆದ್ಯತೆಯನ್ನು ಕಾಯ್ದಿರಿಸಿ.
  2. ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್ ಲಭ್ಯವಿರುವ DNAT ಪೂರ್ವ ಹಂತದಲ್ಲಿ ಉದ್ದೇಶಿತ ಹೊಸ WAN ಸಂಪರ್ಕವನ್ನು ಮಾತ್ರ ಗುರುತಿಸಿ.
  3. ಮೂಲ ವಿನಂತಿಯನ್ನೇ WAN ಕೋಷ್ಟಕಕ್ಕೆ ಒತ್ತಾಯಿಸದೆ ನಿರ್ಧಾರವನ್ನು ಸಂಪರ್ಕ ಮಾರ್ಕ್ನಲ್ಲಿ ದಾಖಲಿಸಿ.
  4. ಉತ್ತರದ ದಿಕ್ಕಿನಲ್ಲಿ, ಮಾರ್ಗೀಕರಣಕ್ಕೆ ಮೊದಲು ನಿಮ್ಮದೇ ಮಾರ್ಕ್ ಬಿಟ್ಗಳನ್ನು ಮಾತ್ರ ಪ್ಯಾಕೆಟ್ಗೆ ಮರುಸ್ಥಾಪಿಸಿ.
  5. VPN ನಿಯಮವು ಮೊದಲು ಗೆಲ್ಲದಂತೆ ಸಂಪೂರ್ಣ WAN ಕೋಷ್ಟಕವನ್ನು ಸಾಕಷ್ಟು ಮುಂಚಿತವಾಗಿ ಆರಿಸಿ.

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

ವಿನ್ಯಾಸ B: ಹೋಸ್ಟ್ನಲ್ಲಿ ಕೊನೆಗೊಳಿಸಿ

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

ವೆಚ್ಚವೆಂದರೆ ತನ್ನದೇ ಸಂರಚನೆ, ಮೂಲ-ವಿಳಾಸ ನಿರ್ವಹಣೆ ಮತ್ತು ಪ್ರವೇಶ ನಿಯಂತ್ರಣಗಳನ್ನು ಹೊಂದಿರುವ ಇನ್ನೊಂದು ಚಲಿಸುವ ಭಾಗ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಸರಳವಾದ ಬೆಂಬಲಿತ ಗಡಿ, ಮತ್ತು ಮಾರ್ಗೀಕರಣ ನೀತಿಯನ್ನು ಬಿಟ್ಟುಹೋಗಬಹುದಾದ ಒಬ್ಬ ವ್ಯಕ್ತಿ ನಿರ್ವಹಿಸುವಾಗ ಇದು ಹೆಚ್ಚಾಗಿ ಸರಿಯಾದ ಉತ್ತರವಾಗಿರುತ್ತದೆ.

ಬದಲಾವಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಉದ್ದೇಶವನ್ನಲ್ಲ

ಸಾರ್ವಜನಿಕ ಬದಿಯಿಂದ ಹೊಸ ಅಧಿಕೃತ ಸಂಪರ್ಕವನ್ನು ತೆರೆದು ಉತ್ತರವು ಉದ್ದೇಶಿತ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಹೊರಹೋಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಂತರ ಕಂಟೇನರ್ ಪ್ರಾರಂಭಿಸಿದ ಸಂಬಂಧವಿಲ್ಲದ ವಿನಂತಿ ಇನ್ನೂ VPN ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.

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

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