ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಹೋಸ್ಟ್‌ನಾಮ್ ಟೈಪ್ ಮಾಡಿ ಮತ್ತು ಸ್ಕೀಮ್ ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್ ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ: http ಗೆ 80, https ಗೆ 443. DNS ಉತ್ತರದಲ್ಲಿ ಯಾವುದೂ ಅದನ್ನು ರದ್ದುಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ನಿಮ್ಮ ಯಂತ್ರದಲ್ಲಿನ ಯಾವುದೇ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮ ಪೂರೈಕೆದಾರರ ಅಂಚಿನಲ್ಲಿ ಕೇಳುಗನನ್ನು ಸೃಷ್ಟಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. VPN ಪೂರೈಕೆದಾರರು ನಿಮಗೆ 45000 ನಂತಹ ಎತ್ತರದ ಸಾರ್ವಜನಿಕ ಪೋರ್ಟ್ ನೀಡಿದಾಗ, ಸ್ಪಷ್ಟ URL ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸ್ವಚ್ಛವಾದದ್ದು ಮಾಡುವುದಿಲ್ಲ. ಅಂತರವು ಪ್ರವೇಶ ಬಿಂದುವಿನಲ್ಲಿದೆ, ಅಪ್ಲಿಕೇಶನ್ ಒಳಗೆ ಅಲ್ಲ.

ಬ್ರೌಸರ್‌ನಿಂದ ಪ್ರಕ್ರಿಯೆಗೆ ಇರುವ ಮಾರ್ಗವನ್ನು ಒಮ್ಮೆ ನೋಡಿ, ಮತ್ತು ಮೂರು ಪ್ರಕಟಣೆ ಆಯ್ಕೆಗಳು ನಿಗೂಢವಾಗಿ ಕಾಣುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ.

ವಿನಂತಿ ನಿಜವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ನೋಡಿ

ಬ್ರೌಸರ್ ಹೆಸರನ್ನು ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುತ್ತದೆ, ನಂತರ URL ಬೇರೆ ಪೋರ್ಟ್ ಹೇಳದಿದ್ದರೆ ಸ್ಕೀಮ್‌ನ ಡೀಫಾಲ್ಟ್ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಆ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ. ಬರುವ ಸಂಪರ್ಕಕ್ಕೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಮ್ಮ ಪೂರೈಕೆದಾರರ ಅಂಚು ನಿರ್ಧರಿಸುತ್ತದೆ. ಅದರ ಫಾರ್ವರ್ಡಿಂಗ್ ಕೋಷ್ಟಕವು ಕೇವಲ 45000 ಅನ್ನು ನಿಮ್ಮ ಆಂತರಿಕ ವಿಳಾಸಕ್ಕೆ ಮ್ಯಾಪ್ ಮಾಡಿದರೆ, 80 ಗೆ ಸಂಪರ್ಕಕ್ಕೆ ಹೋಗಲು ಸ್ಥಳವಿಲ್ಲ ಮತ್ತು ನಿಮ್ಮ ಯಂತ್ರ ಒಳಗೊಳ್ಳುವ ಮೊದಲೇ ಅದನ್ನು ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ ಅಥವಾ ಬಿಡಲಾಗುತ್ತದೆ.

ಆ ನಿರಾಕರಣೆ ಅಂಚಿನಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗ್‌ಗಳು ಏನನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ. ಲಾಗ್‌ಗಳ ಅನುಪಸ್ಥಿತಿ ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿ ನಿಂತಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿ, ಅಪ್ಲಿಕೇಶನ್ ಕೆಟ್ಟಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿ ಅಲ್ಲ.

ಸ್ಥಳೀಯ ನಿಯಮ ಅಂಚನ್ನು ಏಕೆ ಸರಿಪಡಿಸಲಾರದು

ಅಪ್ಲಿಕೇಶನ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿನ ಮರುನಿರ್ದೇಶನ ಅಥವಾ DNAT ನಿಯಮ ಈಗಾಗಲೇ ಬಂದ ಪ್ಯಾಕೆಟ್‌ಗಳ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಪೂರೈಕೆದಾರರಲ್ಲಿ ಪೋರ್ಟ್ 80 ಗೆ ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳು ಎಂದಿಗೂ ಬರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಿಯಮವನ್ನು ಎಂದಿಗೂ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಇಡೀ ಸಮಸ್ಯೆಯಲ್ಲಿ ಇದು ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾಗಿ ವ್ಯರ್ಥವಾಗುವ ಗಂಟೆ.

DNS ಕೂಡ ಪೋರ್ಟ್ ಅನ್ನು ಹೊತ್ತೊಯ್ಯಲಾರದು. HTTP ವಿಶೇಷಣೆ ಸ್ಕೀಮ್‌ನ ಡೀಫಾಲ್ಟ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಮತ್ತು A ಅಥವಾ AAAA ದಾಖಲೆ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಆದರೆ CNAME ಬೇರೆ ಹೆಸರನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಬ್ರೌಸರ್ ಇನ್ನೂ ಸ್ಕೀಮ್‌ನ ಪೋರ್ಟ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ URL ನಲ್ಲಿ ಸ್ಪಷ್ಟ ಪೋರ್ಟ್ ಮಾತ್ರ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಬದಲಿಸುತ್ತದೆ.

ಆಯ್ಕೆ ಒಂದು: ಸ್ಪಷ್ಟ ಪೋರ್ಟ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ

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

ಅಲ್ಲಿರುವಾಗ ಮರುನಿರ್ದೇಶನಗಳು ಮತ್ತು ಕುಕಿ ವ್ಯಾಪ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ತನ್ನದೇ ಹೋಸ್ಟ್‌ನಾಮ್ ಅನ್ನು Location ಹೆಡರ್‌ನಲ್ಲಿ ಬರೆಯುವ ಬ್ಯಾಕೆಂಡ್ ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ರದ್ದುಗೊಳಿಸುತ್ತದೆ.

ಆಯ್ಕೆ ಎರಡು: ಡೀಫಾಲ್ಟ್ ಪೋರ್ಟ್‌ನಲ್ಲಿ ನಿಜವಾದ ಪ್ರವೇಶ ಪಡೆಯಿರಿ

ಕೆಲವು ಪೂರೈಕೆದಾರರು ಮತ್ತು ಹೋಸ್ಟಿಂಗ್ ವ್ಯವಸ್ಥೆಗಳು ದಾಖಲಿತ ಸೇವೆಯಾಗಿ ಹಂಚಿದ ಅಥವಾ ಮೀಸಲಾದ ವಿಳಾಸದಲ್ಲಿ 80 ಮತ್ತು 443 ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತವೆ. ಸಾರ್ವಜನಿಕ ನಿರ್ಗಮನ ವಿಳಾಸವು ಅನಿಯಂತ್ರಿತ ಒಳಬರುವ ಪೋರ್ಟ್‌ಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ನಿಜವಾಗಿ ಏನು ಸೇರಿದೆ ಎಂದು ಕೇಳಿ. ಮೀಸಲಾದ ನಿರ್ಗಮನ ವಿಳಾಸ ಒಳಬರುವ ಫಾರ್ವರ್ಡಿಂಗ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಮಾಲೀಕತ್ವ ಮತ್ತು ಲಭ್ಯತೆಯನ್ನು ಲಿಖಿತವಾಗಿ ದೃಢೀಕರಿಸಿ, ಸುರಂಗವು ಬೇರೆ ವಿಳಾಸದೊಂದಿಗೆ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡಾಗ ಪ್ರವೇಶಕ್ಕೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದೂ ಸೇರಿದಂತೆ. ಸುರಂಗದೊಂದಿಗೆ ಚಲಿಸುವ ಪ್ರವೇಶವು DNS ವೈಫಲ್ಯಗಳಂತೆ ಕಾಣುವ ಅಡಚಣೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಆಯ್ಕೆ ಮೂರು: ಮುಂದೆ ಫ್ರಂಟೆಂಡ್ ಇಡಿ

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

ಇದು ನೀವು ನಿರ್ವಹಿಸುವುದನ್ನೂ ಬದಲಿಸುತ್ತದೆ. ಫ್ರಂಟೆಂಡ್ ಸಾರ್ವಜನಿಕ TLS, ಪ್ರವೇಶ ನೀತಿ, ಲಾಗ್‌ಗಳು ಮತ್ತು ಲಭ್ಯತೆಯನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಅದು ಬ್ಯಾಕೆಂಡ್ ಆಯ್ಕೆಯನ್ನು ಉದ್ದೇಶಿತ ಸೇವೆಗೆ ಸೀಮಿತಗೊಳಿಸಬೇಕು. ಫ್ರಂಟೆಂಡ್‌ನಿಂದ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಜಿಗಿತವು HTTPS ಬಳಸಿದರೆ, ಆ ಜಿಗಿತದಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಉಳಿಸಿ.

ಒಂದೇ ಮೂಲವನ್ನು ಉಳಿಸಿ

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

ನಂತರ ಪ್ರೇಕ್ಷಕರನ್ನು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಂಡು ನಿರ್ಧರಿಸಿ. ಚಿಕ್ಕ URL ನಿರ್ವಹಿತ ಫ್ರಂಟೆಂಡ್ ಅನ್ನು ಸಮರ್ಥಿಸಬಹುದು, ಮತ್ತು VPN ಗೆ ಮಾತ್ರ ಇರುವ ಖಾಸಗಿ ಸೇವೆಯನ್ನು ಆಕಸ್ಮಿಕವಾಗಿ ಸಾರ್ವಜನಿಕವನ್ನಾಗಿ ಮಾಡುವುದು ಯೋಗ್ಯವಲ್ಲ.

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