ಗೇಟ್‌ವೇ ತನ್ನದೇ ನಿರ್ವಾಹಕ ಪುಟವನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತದೆ: ಒಳ ಅಥವಾ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ

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

ಪುಟವು ಸುರಂಗದ ಮೂಲಕವಲ್ಲ, ಹೊರಗಿನಿಂದ ಲೋಡ್ ಆಗುತ್ತದೆ

ಎರಡು ವಿಭಿನ್ನ ವಿನಂತಿಗಳನ್ನು ಹೋಲಿಸಲಾಗುತ್ತಿದೆ. ಮೊಬೈಲ್ ಡೇಟಾದಿಂದ ಬ್ರೌಸರ್ ನೇರವಾಗಿ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ತಲುಪುತ್ತದೆ. ಸುರಂಗದ ಒಳಗಿನಿಂದ ಅದೇ ಹೆಸರು ಅದೇ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಈಗ ಸುರಂಗದ ತನ್ನದೇ ದೂರದ ಬದಿಯಲ್ಲಿರುವ ವಿಳಾಸವನ್ನು ತಲುಪಲು ಸುರಂಗದಿಂದ ಹೊರಬರಬೇಕು. ಅದೇ ಹೆಸರು, ಅದೇ ವಿಳಾಸ, ಎರಡು ಸಂಪೂರ್ಣ ಭಿನ್ನ ಸ್ಥಾನಗಳು.

ಗಮ್ಯ ಮಾರ್ಗವು ವಿಳಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಪೋರ್ಟ್ ಅಲ್ಲ. ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಪೋರ್ಟ್ 443 ನಿರ್ವಹಣೆಗೆ ಮತ್ತು ಪೋರ್ಟ್ 1194 ಸಾಗಣೆಗೆ ಎಂದು ಯಾವುದಕ್ಕೂ ತಿಳಿದಿಲ್ಲ, ಆದ್ದರಿಂದ ಎರಡನ್ನೂ ಒಂದೇ ಗಮ್ಯವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಆದ್ದರಿಂದ ಪುಟವು ಕೆಲವೊಮ್ಮೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಇಲ್ಲ, ಕ್ಲೈಂಟ್ ಯಾವ ಹೆಸರು ಮತ್ತು ಯಾವ ನೆಟ್‌ವರ್ಕ್ ಬಳಸಿತು ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿ. ಇದು ಮಾರ್ಗದ ಸಮಸ್ಯೆ, ದೃಢೀಕರಣದ ಸಮಸ್ಯೆ ಅಲ್ಲ. ಎರಡೂ ಕ್ಲೈಂಟ್‌ಗಳು ಚೆನ್ನಾಗಿ ದೃಢೀಕರಿಸುತ್ತವೆ.

ಹೊರ ತುದಿಯನ್ನು ತಲುಪಬಹುದಾದಂತೆ ಇರಿಸಿ

ಪೂರ್ಣ ಸುರಂಗ ಪ್ರೊಫೈಲ್‌ಗಳಿಗೆ VPN ತುದಿಗೆ ವಿನಾಯಿತಿ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು OpenVPN ನ redirect-gateway ಆಯ್ಕೆ ನಿಖರವಾಗಿ ಅದನ್ನೇ ದಾಖಲಿಸುತ್ತದೆ: ದೂರದ ತುದಿ ಹಿಂದೆ ಇದ್ದ ಗೇಟ್‌ವೇ ಮೂಲಕ ಮಾರ್ಗವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಇದರಿಂದ ಸುರಂಗ ತನ್ನೊಳಗೇ ಮಾರ್ಗ ಮಾಡುವುದಿಲ್ಲ. ಆ ವಿನಾಯಿತಿಯನ್ನು ತೆಗೆದರೆ ಗೂಢಲಿಪೀಕೃತ ಸಾಗಣೆ ಸುರಂಗವನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಇದು ಅಧಿವೇಶನವನ್ನು ಲೂಪ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳಿಸುತ್ತದೆ. ತುದಿಯ ವಿಳಾಸ ಸುರಂಗದ ಒಳಗಿನಿಂದ ತಲುಪಬಹುದಾಗಿ ಉಳಿಯುವುದಕ್ಕೆ ಆ ವಿನಾಯಿತಿಯೇ ಕಾರಣ.

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

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಇಂಟರ್‌ಫೇಸ್ ಪಟ್ಟಿಯಲ್ಲ, ಮಾರ್ಗದ ನಿರ್ಣಯವನ್ನು ಓದಿ. ಕೆಳಗಿನ ಆಜ್ಞೆಗಳು ದಾಸ್ತಾನಲ್ಲ, ನಿರ್ಣಯವನ್ನು ಮುದ್ರಿಸುತ್ತವೆ. ವಿಫಲವಾದ ಕ್ಲೈಂಟ್‌ನಿಂದ ಅವನ್ನು ಚಲಾಯಿಸಿ.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

ಹುಡುಕಾಟವು ತುದಿಯ ಮಾರ್ಗವನ್ನು ಭೌತಿಕ ಗೇಟ್‌ವೇ ಮೂಲಕ ತೋರಿಸಿದರೆ, ನಡವಳಿಕೆ ಸರಿಯಾಗಿದೆ ಮತ್ತು ನಿರ್ವಾಹಕ ಪುಟವು ಬರೀ ತಪ್ಪು ದಾರಿಗೆ ಕಳುಹಿಸಲ್ಪಡುತ್ತಿದೆ. ಹೆಸರು ಪರಿಹಾರವೇ ಸರಿಪಡಿಸುವಿಕೆಯಾಗುವುದು ಅಲ್ಲೇ.

ಸೇವೆಗೆ ಖಾಸಗಿ ಹೆಸರು ನೀಡಿ

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

ಸಾಗಣೆಯ ಹೆಸರನ್ನು ಒಳ ವಿಳಾಸಕ್ಕೆ ಮರುನಿರ್ದೇಶಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಸುರಂಗ ಸ್ಥಾಪನೆ ಸುರಂಗದ ಒಳಗಷ್ಟೇ ಇರುವ ವಿಳಾಸವನ್ನು ತಲುಪಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಆ ತಪ್ಪು ನಿಖರವಾಗಿ ಒಮ್ಮೆ ಕೆಲಸ ಮಾಡುವ VPN ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಉಳಿದುಕೊಂಡ AAAA ದಾಖಲೆ ಬ್ರೌಸರ್ ಅನ್ನು ಖಾಸಗಿ ಯೋಜನೆ ಎಂದೂ ಆವರಿಸದ ಸ್ಥಳಕ್ಕೆ ಕಳುಹಿಸಬಹುದು.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

ಪ್ರಕ್ರಿಯೆ ನಡೆಯುವ ಸ್ಥಳಕ್ಕೆ ನೀತಿಯನ್ನು ಹೊಂದಿಸಿ

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

ಹೋಸ್ಟ್ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಪ್ರಕಟಿಸಿದ ಕಂಟೇನರ್ ಬೇರೆ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ಯಾಕೆಟ್ ಗಮ್ಯ-ಅನುವಾದಗೊಂಡು ಫಾರ್ವರ್ಡ್ ಆಗುತ್ತದೆ. ಆ ವಿನಂತಿ ಹೋಸ್ಟ್‌ನ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ ಮತ್ತು Docker ನ ತನ್ನದೇ ನಿಯಮಗಳನ್ನು ಎದುರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಸ್ಥಳೀಯ ಶ್ರೋತೃವು ಅದೇ ಪೋರ್ಟ್ ನಿರಾಕರಿಸುವ ಕಂಟೇನರ್ ಜೊತೆ ಸಹಬಾಳ್ವೆ ನಡೆಸಬಹುದು.

ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಆರಂಭ ಕ್ರಮ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಸುರಂಗ ಏರಿದ ನಂತರವೇ ಕಾಣಿಸುವ ವಿಳಾಸಕ್ಕೆ ಬೈಂಡಿಂಗ್ ಬೂಟ್‌ನಲ್ಲಿ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ.

ಖಾಸಗಿ ಪ್ರವೇಶ ಮತ್ತು ನಿರಾಕರಿಸಿದ ಸಾರ್ವಜನಿಕ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

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

ಬಳಕೆದಾರರಿಗೆ ನೀಡಿದ ಹೋಸ್ಟ್‌ಹೆಸರಲ್ಲ, ಬೈಂಡಿಂಗ್‌ಗಳು ಮತ್ತು ಫಿಲ್ಟರ್ ಸ್ಥಿತಿಯನ್ನು ಓದಿ. ಬಯಲಾಗುವಿಕೆ ಸಾಕೆಟ್‌ನ ಗುಣ, ಹೆಸರಿನದಲ್ಲ. ಆ ವ್ಯತ್ಯಾಸ ಪ್ರತಿ DNS ಬದಲಾವಣೆಯನ್ನೂ ಮೀರಿ ಉಳಿಯುತ್ತದೆ.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

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