VPN ಬಳಕೆದಾರರಿಗೆ ಒಂದು ಸೇವೆಗೆ ಪ್ರವೇಶ ನೀಡಿ, ಸಬ್ನೆಟ್ಗೆ ಅಲ್ಲ

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

ಅಗತ್ಯವನ್ನು ಸಬ್ನೆಟ್ ಆಗಿ ಅಲ್ಲ, ಸೇವೆಯಾಗಿ ಬರೆಯಿರಿ

ಗಮ್ಯಸ್ಥಾನದ ಹೋಸ್ಟ್, ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಪೋರ್ಟ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಅಲ್ಲಿಗೆ ತಲುಪಬೇಕಾದ ಬಳಕೆದಾರ ಅಥವಾ ಸಾಧನ ಗುಂಪನ್ನು ಸೇರಿಸಿ. ಖಾಸಗಿ DNS ವಲಯವನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿದರೆ ಮಾತ್ರ ಸೇರಿಸಿ, ಮತ್ತು ಸೈನ್-ಇನ್ ಹರಿವಿಗೆ ಅಗತ್ಯವಿದ್ದರೆ ಮಾತ್ರ ಗುರುತು ಪೂರೈಕೆದಾರರನ್ನು ಸೇರಿಸಿ. ಉಳಿದೆಲ್ಲವೂ ನೀವು ಇನ್ನೂ ಸಮರ್ಥಿಸದ ಅವಲಂಬನೆ.

ಸಬ್ನೆಟ್ ನೆಟ್ವರ್ಕ್ ತಂಡದ ಅನುಷ್ಠಾನ ವಿವರ, ಆದರೆ ಸೇವೆ ಎಂದರೆ ವ್ಯಾಪಾರ ಕೇಳಿದ್ದು ಮತ್ತು ಪರಿಶೀಲಿಸಿ ನಿಲ್ಲಿಸಬಹುದಾದ ಘಟಕ.

ಅವಲಂಬನೆಗಳ ಪಟ್ಟಿ ಮೂರು ಅಂಶಗಳನ್ನು ಮೀರಿದರೆ, ಅಪ್ಲಿಕೇಶನ್ಗೆ ತನ್ನದೇ ವಿನ್ಯಾಸ ಸಂಭಾಷಣೆ ಬೇಕಾಗಬಹುದು.

ಸಂಕುಚಿತವಾಗಿ ಮಾರ್ಗನಿರ್ದೇಶಿಸಿ, ಆದರೆ ಜಾರಿಯನ್ನು ಬೇರೆಡೆ ಮಾಡಿ

ಸಂಕುಚಿತ ಮಾರ್ಗ ಅಥವಾ ಆಯ್ಕೆದಾರನು ಸುರಂಗಕ್ಕೆ ಯಾವ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸಾಗಿಸಬೇಕೆಂದು ಹೇಳುತ್ತದೆ; ಅದು ಅನುಮತಿ ನೀತಿ ಅಲ್ಲ. ಗೇಟ್ವೇ ಫಿಲ್ಟರ್, ಗಮ್ಯಸ್ಥಾನದ ಹೋಸ್ಟ್ನ ಫೈರ್ವಾಲ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಅನುಮತಿ ಮಾದರಿ — ಪ್ರವೇಶ ನಿರ್ಧರಿಸುವ ಸ್ಥಳಗಳು. ಒಂದು ವಿಳಾಸವನ್ನು ಆವರಿಸುವ ಮಾರ್ಗ ಒಳ್ಳೆಯ ಆರಂಭ, ಮತ್ತು ಅದು ನಿಶ್ಚಯಿಸಿದ ಬಳಕೆದಾರನನ್ನು ನಿಲ್ಲಿಸುವ ನಿಯಂತ್ರಣ ಅಲ್ಲ. ಆ ಪ್ರತ್ಯೇಕತೆಯೇ ಸುರಂಗವನ್ನು ಮರು ವಿನ್ಯಾಸ ಮಾಡದೆ ಫಿಲ್ಟರ್ ಬದಲಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ವಿರುದ್ಧವಾಗಿ, ಕಟ್ಟುನಿಟ್ಟಾದ ಫಿಲ್ಟರ್ನೊಂದಿಗೆ ಅಗಲ ಮಾರ್ಗ ಕಾನೂನುಬದ್ಧವಾಗಿರಬಹುದು, ಆದರೆ ಒಳಗೊಂಡ ಎಲ್ಲರೂ ಯಾವುದು ಜಾರಿ ಮಾಡುತ್ತದೆ ಎಂದು ತಿಳಿದಿದ್ದರೆ ಮಾತ್ರ.

ಜಾರಿ ಬಿಂದುವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ದಾಖಲಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ಬದಲಾವಣೆ ಅದನ್ನು ಆಕಸ್ಮಿಕವಾಗಿ ಸರಿಸುತ್ತದೆ.

ಸೇವೆ ನಿಜವಾಗಿ ನೋಡುವ ಮೂಲವನ್ನು ಪರಿಶೀಲಿಸಿ

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

ಅನುವಾದವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆರಿಸಿ: ಅದು ಮಾರ್ಗನಿರ್ದೇಶನವನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಮೂಲದ ಗುರುತನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ, ಇದು ಲೆಕ್ಕಪರಿಶೋಧನೆ ಮತ್ತು ಪ್ರತಿ-ಬಳಕೆದಾರ ನಿಯಮಗಳಿಗೆ ಮುಖ್ಯ.

ಎರಡರಲ್ಲಿ ಯಾವುದನ್ನು ಆರಿಸಿದಿರಿ ಎಂದು ಅದನ್ನು ಅವಲಂಬಿಸಿದ ನಿಯಮದ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ.

ಅಪ್ಲಿಕೇಶನ್ ಅನುಮತಿ ಐಚ್ಛಿಕ ಅಲ್ಲ

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

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

ನೆಟ್ವರ್ಕ್ ನಿಯಮ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪಾತ್ರವನ್ನು ಪ್ರತ್ಯೇಕ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಇರಿಸಿ, ಮತ್ತು ಅವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನಿಲ್ಲಿಸಿ.

ಅನುಮತಿಸಿದ ಮತ್ತು ನಿರಾಕರಿಸಿದ ಎರಡೂ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸಿ

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

ಸ್ವೀಕೃತಿ ಪರೀಕ್ಷೆ ಉತ್ತೀರ್ಣವಾಗಲು ಫಾರ್ವರ್ಡಿಂಗ್ ಫಿಲ್ಟರ್ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಅದು ಪರೀಕ್ಷಿಸಲ್ಪಡುತ್ತಿರುವ ವಸ್ತುವನ್ನೇ ಬದಲಿಸುತ್ತದೆ.

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