ಒಂದು ಸಾರ್ವಜನಿಕ ಪ್ರಾಕ್ಸಿ VPN ಮೂಲಕ ಖಾಸಗಿ ಮೂಲವನ್ನು ತಲುಪುವುದು ಹೇಗೆ

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

ಚಿತ್ರದಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎರಡು ಮಾದರಿಗಳು

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

ಮಾದರಿಗಳು ಯಾರು ದೃಢೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ಎಲ್ಲಿ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನವಾಗಿವೆ. ಮೊದಲನೆಯದರಲ್ಲಿ, ಪ್ರಾಕ್ಸಿ ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶದ್ವಾರವಾಗಿದೆ ಮತ್ತು ಅದರ ಮೇಲೆ ಸಂರಚಿಸಲಾದ ನೀತಿಗೆ ಒಳಪಟ್ಟು, ಬರುವ ಯಾವುದೇ ವಿನಂತಿಯನ್ನು, ಶತ್ರುತ್ವದ್ದನ್ನೂ ಸಹ, ರವಾನಿಸುತ್ತದೆ. ಎರಡನೆಯದರಲ್ಲಿ, ತಲುಪಬಹುದಾದ ಸಾಮರ್ಥ್ಯವೇ ದ್ವಾರ, ಅದು ಒರಟಾದರೂ ನಿಜವಾದ ಪ್ರವೇಶ.

TLS ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ, ಮತ್ತು ಅದು ನಿಜವಾಗಿ ಏನನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ

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

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

ಮುಂದಕ್ಕೆ ರವಾನಿಸಿದ ಹೆಡರ್‌ಗಳನ್ನು ಪ್ರಾಕ್ಸಿಯಿಂದ ಮಾತ್ರ ನಂಬಿ

ಕ್ಲೈಂಟ್ ವಿಳಾಸದ ಆಧಾರದ ಮೇಲೆ ಲಾಗ್ ಮಾಡುವ ಅಥವಾ ಅಧಿಕಾರ ನೀಡುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಾಕ್ಸಿ ಸೇರಿಸುವ ಹೆಡರ್ ಅನ್ನು ಓದುತ್ತವೆ. ಆ ಹೆಡರ್ ಕೇವಲ ಪಠ್ಯ, ಆದ್ದರಿಂದ ಮೂಲವನ್ನು ನೇರವಾಗಿ ತಲುಪಬಲ್ಲ ಯಾವುದೇ ವಸ್ತು ತನಗೆ ಇಷ್ಟವಾದ ಯಾವುದೇ ವಿಳಾಸವನ್ನು ಪ್ರತಿಪಾದಿಸಬಹುದು. ಮೂಲವನ್ನು ಪ್ರಾಕ್ಸಿಯ ಟನೆಲ್ ವಿಳಾಸ ಮಾತ್ರ ಸಂಪರ್ಕಿಸಬಹುದಾದಂತೆ ನಿರ್ಬಂಧಿಸಿ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಆ ವಿಳಾಸದಿಂದ ಮಾತ್ರ ಹೆಡರ್ ಸ್ವೀಕರಿಸುವಂತೆ ಸಂರಚಿಸಿ.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

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

ಮೂಲವನ್ನು ನಿಖರವಾಗಿ ಒಂದೇ ಸ್ಥಳದಿಂದ ತಲುಪಬಹುದಾಗಿ ಇರಿಸಿ

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

ss -ltnp | grep -E ':(80|443)'

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