ಮೀಸಲಾದ VPN IP ನಿಮ್ಮ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಪ್ರಕಟಿಸುವುದಿಲ್ಲ
ಮೀಸಲಾದ ನಿರ್ಗಮನ ವಿಳಾಸವು ಒಳಬರುವ ವಿತರಣೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಫಾರ್ವರ್ಡಿಂಗ್ ಒಪ್ಪಂದವನ್ನು ಪರಿಶೀಲಿಸಿ, ಮೂಲ ಭಾಗವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ, ನಂತರ ಎತ್ತರದ ಪೋರ್ಟ್ ಪ್ರಕಟಿಸಿ.
VPN ಪೂರೈಕೆದಾರರಿಂದ ಮೀಸಲಾದ IP ಖರೀದಿಸುವುದು ಮುಂಭಾಗದ ಬಾಗಿಲನ್ನು ಖರೀದಿಸಿದಂತೆ ಭಾಸವಾಗುತ್ತದೆ. ವಿಳಾಸ ಸ್ಥಿರವಾಗಿದೆ, ಸುರಂಗ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಆದರೂ ಹೊರಗಿನ ಯಾರಿಗೂ ಸೈಟ್ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ. ನೀವು ಖರೀದಿಸಿದ್ದು ಒಂದು ನಿಗದಿ, ಒಳಬರುವ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮವಲ್ಲ. ಎರಡೂ ಒಂದೇ ಅಂಗಡಿಯಲ್ಲಿ ಮಾರಾಟವಾಗುತ್ತವೆ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ಸಂರಚಿಸಲಾಗುತ್ತವೆ.
ವಿಳಾಸವು ನಿಗದಿಯಾಗಿದೆ, ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮವಲ್ಲ
ಒಳಬರುವ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಅಥವಾ ಹೋಸ್ಟ್‌ಹೆಸರು, ಅನುಮತಿಸಲಾದ ಸಾಗಣೆ, ನಿಗದಿಪಡಿಸಿದ ಬಾಹ್ಯ ಪೋರ್ಟ್ ಮತ್ತು ಪೂರೈಕೆದಾರರು ತಲುಪಿಸುವ ಕ್ಲೈಂಟ್-ಬದಿಯ ಗಮ್ಯಸ್ಥಾನವನ್ನು ದಾಖಲಿಸಿ. ನಂತರ ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ಸರ್ವರ್, ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಖಾತೆ ವೈಶಿಷ್ಟ್ಯವು ನಿಜವಾಗಿಯೂ ಫಾರ್ವರ್ಡಿಂಗ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಮತ್ತು ಪೂರೈಕೆದಾರರು ಅದರ ಮೇಲೆ ಹೋಸ್ಟಿಂಗ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತಾರೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ಮೀಸಲಾದ ಎಂಬ ಪದವು ವಿಳಾಸದ ನಿಗದಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅದು ಕೇಳದ ಒಳಬರುವ ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ಎಂದು ಅರ್ಥವಲ್ಲ, ಮತ್ತು ಒಂದೇ ನಿರ್ವಾಹಕರ ವಿವಿಧ ಆಡ್-ಆನ್‌ಗಳು ವಿಭಿನ್ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಮೀಸಲಾದ ವಿಳಾಸ ಮತ್ತು ಮೀಸಲಾದ ಸರ್ವರ್ ಉತ್ಪನ್ನವು ಜನರು ಹೆಚ್ಚಾಗಿ ಗೊಂದಲಪಡಿಸುವ ಎರಡು ಲೇಬಲ್‌ಗಳು, ಮತ್ತು ಬೆಂಬಲ ಪುಟಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ ಎಂದು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತವೆ.
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
ಒಂದು ಉದಾಹರಣೆಯ ಒಪ್ಪಂದ ಹೀಗಿದೆ: ಪೂರೈಕೆದಾರರು TCP 203.0.113.60:45000 ಅನ್ನು ನಿಮ್ಮ ಸಂಪರ್ಕಿತ ಸಾಧನದ HTTPS ಸೇವೆಗೆ 8443 ಪೋರ್ಟ್‌ನಲ್ಲಿ ತಲುಪಿಸುತ್ತಾರೆ. ಇದು ಬೇರೆಯವರು ಸಂರಚಿಸಿದ ಮ್ಯಾಪಿಂಗ್‌ನ ವಿವರಣೆ, ನಿಮ್ಮ ಸ್ವಂತ ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ ಟೈಪ್ ಮಾಡಿ ಅವರ ಎಡ್ಜ್‌ನಲ್ಲಿ ನೀವು ರಚಿಸಬಹುದಾದ ನಿಯಮವಲ್ಲ.
ಮೂಲ ಭಾಗವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ
ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ VPN ಕ್ಲೈಂಟ್‌ನಲ್ಲೇ ಚಾಲನೆಯಲ್ಲಿದ್ದರೆ, ಅದಕ್ಕೆ ತಲುಪಿಸಿದ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಶ್ರೋತೃ ಮತ್ತು ಆ ಪೋರ್ಟ್‌ಗೆ ಸೀಮಿತ ಸ್ಥಳೀಯ-ಇನ್‌ಪುಟ್ ಅನುಮತಿ ಬೇಕು. ಕ್ಲೈಂಟ್ ಮ್ಯಾಪ್ ಮಾಡಿದ ಸಂಪರ್ಕವನ್ನು ಇನ್ನೊಂದು ಹೋಸ್ಟ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದರೆ, ಅದಕ್ಕೆ ಗಮ್ಯಸ್ಥಾನ ಅನುವಾದ, ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ ಮತ್ತು ಹೋಗಿ-ಬರುವ ಪ್ರಯಾಣವನ್ನು ತಾಳುವ ಪ್ರತ್ಯುತ್ತರ ಮಾರ್ಗ ಬೇಕು.
ಪ್ರವೇಶ ನಿಯಮಗಳನ್ನು ಪೂರೈಕೆದಾರರ ಮಾರ್ಗವು ನಿಜವಾಗಿ ಪ್ರಸ್ತುತಪಡಿಸುವ ಮೂಲ ವಿಳಾಸದ ಸುತ್ತ ವಿನ್ಯಾಸ ಮಾಡಿ. ಅದು ಯಾವಾಗಲೂ ಮೂಲ ಸಂದರ್ಶಕನಲ್ಲ, ಮತ್ತು ಯಾವಾಗಲೂ VPN ಸರ್ವರ್ ಕೂಡ ಅಲ್ಲ, ಇದು ಆ ವಿಳಾಸಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಮಾತ್ರ ಹೊಂದಿಕೆಯಾಗುವ ನಿಯಮವನ್ನು ಬರೆಯುವಾಗ ಮುಖ್ಯ.
ಪೋರ್ಟ್ ಅನುವಾದವು HTTP ಅನ್ನು HTTPS ಆಗಿ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ. ಸಾರ್ವಜನಿಕ ಪೋರ್ಟ್ ಮತ್ತು ಸ್ಥಳೀಯ ಅಪ್ಲಿಕೇಶನ್ ಪೋರ್ಟ್ ಮುಕ್ತವಾಗಿ ಭಿನ್ನವಾಗಿರಬಹುದು, ಆದರೆ ಸ್ಕೀಮ್, ಪ್ರಮಾಣಪತ್ರದ ಗುರುತು ಮತ್ತು ಮರುನಿರ್ದೇಶನಗಳು ಜನರು ನಿಜವಾಗಿ ತಲುಪುವ ಸೇವೆಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಪ್ರಮಾಣಪತ್ರವು ಸಾರ್ವಜನಿಕ ಹೋಸ್ಟ್ ಅನ್ನು ಹೆಸರಿಸಿದರೆ, ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಆ ಹೆಸರನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ಇಲ್ಲಿನ ಅಸಂಗತಿ ರೌಟಿಂಗ್ ವೈಫಲ್ಯವಾಗಿ ಅಲ್ಲ, ಬ್ರೌಸರ್ ಎಚ್ಚರಿಕೆಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ, ಇದು ಜನರನ್ನು ಒಂದು ಗಂಟೆಗೆ ತಪ್ಪು ಲಾಗ್‌ಗಳಿಗೆ ಕಳುಹಿಸುತ್ತದೆ.
ಎತ್ತರದ ಪೋರ್ಟ್ ಅನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಪ್ರಕಟಿಸಿ
ಸಂದರ್ಶಕರು ನೇರವಾಗಿ ಸಂಪರ್ಕಿಸಿದರೆ ಮತ್ತು ಪೂರೈಕೆದಾರರು ಎತ್ತರದ ಪೋರ್ಟ್ ನಿಗದಿಪಡಿಸಿದರೆ, ಅವರಿಗೆ ಪೂರ್ಣ URL ನೀಡಿ. ಸಾಮಾನ್ಯ DNS ವಿಳಾಸ ದಾಖಲೆಯು ಡೀಫಾಲ್ಟ್ ಆಗಿ 443 ಬಳಸುವ HTTPS ವಿನಂತಿಗೆ ಪೋರ್ಟ್ ಸೇರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು TTL ಬದಲಾವಣೆಯಿಂದ ಅದು ಬದಲಾಗುವುದಿಲ್ಲ.
ವೆಬ್ ಫ್ರಂಟೆಂಡ್ ಇದನ್ನು ಸಂದರ್ಶಕರನ್ನು ಸಾಮಾನ್ಯ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಸ್ವೀಕರಿಸಿ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಮೂಲ ಪೋರ್ಟ್‌ಗೆ ತನ್ನದೇ ಸಂಪರ್ಕವನ್ನು ಮಾಡುವ ಮೂಲಕ ಪರಿಹರಿಸಬಹುದು. ಆದರೆ Cloudflare ನ ಡೀಫಾಲ್ಟ್ ಪ್ರಾಕ್ಸಿ ಪೋರ್ಟ್‌ಗಳು ಒಂದು ನಿರ್ದಿಷ್ಟ ಪಟ್ಟಿ, ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಮಾಡಿದ DNS ದಾಖಲೆಯನ್ನು ಸೇರಿಸಿದ್ದರಿಂದ ಅನಿಯತವಾಗಿ ನಿಗದಿಪಡಿಸಿದ ಪೋರ್ಟ್ ಬೆಂಬಲಿತ ಎಡ್ಜ್ ಪೋರ್ಟ್ ಆಗುವುದಿಲ್ಲ.
ಮೂಲದ ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್ ಬದಲಾಯಿಸುವುದು ಸಂದರ್ಶಕ ಪೋರ್ಟ್ ಬದಲಾಯಿಸುವುದಕ್ಕಿಂತ ಬೇರೆ ಕಾರ್ಯಾಚರಣೆ. Cloudflare ನ Origin Rules ಬ್ಯಾಕೆಂಡ್ ಸಂಪರ್ಕಕ್ಕಾಗಿ ಗಮ್ಯಸ್ಥಾನ-ಪೋರ್ಟ್ ಓವರ್‌ರೈಡ್ ಅನ್ನು ದಾಖಲಿಸುತ್ತವೆ, ಇದು ಬೆಂಬಲಿತ ನಿಯಮ, ಸ್ಕೀಮ್ ಮತ್ತು ಹೋಸ್ಟ್‌ಹೆಸರಿಗೆ ಸೀಮಿತವಾಗಿದೆ. ಪೋರ್ಟ್ ಓವರ್‌ರೈಡ್ ಅನಿಯತ UDP ಅಥವಾ ಇತರ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ ಸಾಮಾನ್ಯ ರಿಲೇ ಅಲ್ಲ.
ಫ್ರಂಟೆಂಡ್ TLS ಮುಗಿಸಿದಾಗ, ಎರಡೂ ಹಂತಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸಿ: ಬ್ರೌಸರ್‌ನಿಂದ ಫ್ರಂಟೆಂಡ್‌ಗೆ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಫ್ರಂಟೆಂಡ್‌ನಿಂದ ಮೂಲಕ್ಕೆ ಸಂಪರ್ಕ. VPN ಹಂತವು ಎರಡೂ ಪರಿಶೀಲನೆಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಆಂತರಿಕ ವಿಳಾಸವು ಮರುನಿರ್ದೇಶನಗಳು ಅಥವಾ ಕುಕೀಗಳಿಗೆ ಸೋರುವುದು ಎರಡರಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಂಡು ಸಂರಚಿಸಲಾಗಿದೆ ಎಂಬ ಸಾಮಾನ್ಯ ಸೂಚನೆ.
ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಜೀವಂತವಾಗಿರಿಸಿ
ಕೆಲವು ಪೂರೈಕೆದಾರರು ಮರುಸಂಪರ್ಕದ ನಂತರ ಬೇರೆ ಪೋರ್ಟ್ ಹಂಚುತ್ತಾರೆ, ಮತ್ತು ಗುತ್ತಿಗೆ ಪಡೆದ ಮ್ಯಾಪಿಂಗ್‌ಗೆ ಪೂರೈಕೆದಾರರ ಬದಿಯ ಕ್ರಿಯೆಯ ಮೂಲಕ ನವೀಕರಣ ಬೇಕಾಗಬಹುದು. ನಿಮ್ಮ ಪೂರೈಕೆದಾರರು ದಾಖಲಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಅನುಸರಿಸಿ, ಮತ್ತು ಶ್ರೋತೃ, ಸ್ಥಳೀಯ ನಿಯಮಗಳು, DNS ಅಥವಾ ಫ್ರಂಟೆಂಡ್ ನಿಯಮವನ್ನು ಪ್ರಸ್ತುತ ಒಪ್ಪಂದ ಅಗತ್ಯವಿರುವಲ್ಲಿ ಮಾತ್ರ ನವೀಕರಿಸಿ.
ಸ್ಥಿರ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವು ಪೋರ್ಟ್ ಗುತ್ತಿಗೆಯನ್ನು ಸ್ಥಿರಗೊಳಿಸುವುದಿಲ್ಲ. ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಇನ್ನೂ ತೋರಿಸುವ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಸಕ್ರಿಯ ಸೆಷನ್ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಹೊಂದಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ, ಆದ್ದರಿಂದ ಪರೀಕ್ಷೆ ಹೊರಗಿನಿಂದ ಬಂದ ಹೊಸ ವಿನಂತಿ, ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಅಲ್ಲ.
ನಂತರ ನೀವು ನಿರೀಕ್ಷಿಸುವ ಸಂದರ್ಭಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ: ಸಾಮಾನ್ಯ ಮರುಸಂಪರ್ಕ, ಮತ್ತು VPN ನಷ್ಟ. ನಷ್ಟವು ಮೂಲವನ್ನು ತಲುಪಲಾಗದಂತೆ ಮಾಡಬೇಕಿದ್ದರೆ, ನವೀಕರಣ ಸಾಧನವು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ನೇರ ISP ಮಾರ್ಗವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮರುಪ್ರಕಟಿಸಲು ಬಿಡಬೇಡಿ. ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಒಪ್ಪಂದವು ಸೈಟ್‌ನ ಸ್ಥಿರತೆಯ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಇನ್ನೊಂದು ವಿಳಾಸ ಲೇಬಲ್ ಖರೀದಿಸಿ ಸರ್ವರ್‌ನಂತೆ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ಆಶಿಸುವ ಬದಲು ಬೇರೆ ಪ್ರಕಟಣೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿ.