VPN ಕ್ಲೈಂಟ್ ಸಂಚಾರ ಮತ್ತು ಫೈರ್ವಾಲ್ ಸ್ಥಿತಿ: ಹೊರ ಮತ್ತು ಒಳ ಹರಿವು

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

ಈ ಎರಡನ್ನು ಬೇರ್ಪಡಿಸುವವರೆಗೆ, ಪ್ರತಿ ನಿಯಮ ಬದಲಾವಣೆಯೂ ಒಂದು ಊಹೆ.

ಫೈರ್ವಾಲ್ ಎರಡು ಬೇರೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನೋಡುತ್ತದೆ

ಡೀಕ್ಯಾಪ್ಸುಲೇಷನ್‌ಗೆ ಮೊದಲು, ಫೈರ್ವಾಲ್ VPN ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ವಿಳಾಸ ಮಾಡಿದ ಸಂಚಾರವನ್ನು ನೋಡುತ್ತದೆ: ಆಲಿಸುವವರ ಕಡೆಗೆ ಹೊರ UDP ಹರಿವು. ಡೀಕ್ಯಾಪ್ಸುಲೇಷನ್ ನಂತರ, ಮುಂದಕ್ಕೆ ರವಾನಿಸಿದ ಪ್ಯಾಕೆಟ್ ಕ್ಲೈಂಟ್‌ನ ಒಳ ವಿಳಾಸ ಮತ್ತು ಸೇವೆಯ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತದೆ.

ಹೊರ ಹರಿವಿಗೆ ನೀಡಿದ ಅನುಮತಿ ರವಾನಿಸಿದ TCP ಸಂಪರ್ಕಕ್ಕೆ ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ. ಅವನ್ನು ಬೇರೆ ಸರಪಳಿಗಳಲ್ಲಿ, ಬೇರೆ ಇಂಟರ್‌ಫೇಸ್‌ಗಳ ಎದುರು ಮತ್ತು ಅನುವಾದದ ನಂತರ ಬೇರೆ ವಿಳಾಸಗಳೊಂದಿಗೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು.

ಎರಡೂ ಬದಿಗಳ ಸಮಾನ ಸ್ಥಾನಗಳಿಂದ ತೆಗೆದ ಕ್ಯಾಪ್ಚರ್‌ಗಳನ್ನು ಹೋಲಿಸಿ. ಟನೆಲ್ ಅಂಚಿನಲ್ಲಿನ ಕ್ಯಾಪ್ಚರ್ ಮತ್ತು ಸರ್ವರ್‌ನಲ್ಲಿನ ಕ್ಯಾಪ್ಚರ್ ಒಂದೇ ಅಧಿವೇಶನಕ್ಕೆ ಬೇರೆ ಟ್ಯುಪಲ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತವೆ.

ಮೊದಲ ನಿರ್ಧಾರ: ಟನೆಲ್ ಅಥವಾ ಸೇವೆಗೆ ಅನುಮತಿ

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

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

ಎರಡೂ ನಿಯಮಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬರೆಯಿರಿ. ಟನೆಲ್ ನಿಯಮ ಮತ್ತು ಸೇವಾ ನಿಯಮ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ ಮತ್ತು ಬೇರೆ ಸಾಕ್ಷ್ಯಗಳಿಂದ ಡೀಬಗ್ ಆಗುತ್ತವೆ. ಒಂದು ವಿಫಲವಾದಾಗ, ಮೊದಲು ಯಾವ ಪದರವನ್ನು ಪರಿಶೀಲಿಸಬೇಕೆಂದು ನಿಮಗೆ ತಿಳಿಯುತ್ತದೆ.

ಎರಡನೇ ನಿರ್ಧಾರ: ಪ್ರತಿ ಗಡಿಯಲ್ಲಿ ಸ್ಥಿತಿಯೊಂದಿಗೆ ಅಥವಾ ಇಲ್ಲದೆ

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

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

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

ಅದೇ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

ಕ್ಲೈಂಟ್‌ನಿಂದ ಸೇವೆಗೆ ಹೊಸ ವಿನಂತಿ ಕಳುಹಿಸಿ, ನಂತರ ಪ್ರತಿ ಗಡಿಯಲ್ಲಿ ಮುಂದೆ ಮತ್ತು ಹಿಂತಿರುಗುವ ಕೌಂಟರ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಪ್ರತ್ಯುತ್ತರ ನೀವು ನಿರೀಕ್ಷಿಸಿದ ಮಾರ್ಗ ಬಳಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ವಿಶೇಷವಾಗಿ ಅನುವಾದ ಒಳಗೊಂಡಿದ್ದರೆ.

ಉದ್ದೇಶಿತ ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿ ಮತ್ತು ಸೇವೆಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಸಂಕುಚಿತವಾಗಿಡಿ, ಮತ್ತು ವಿನಂತಿಗೆ ಅನುಮತಿ ನೀಡಿದ ಅದೇ ನಿಯಮ ಗುಂಪಿನ ಅಡಿಯಲ್ಲಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ. ಹಳೆಯ ಹರಿವು ಇನ್ನೂ ತೆರೆದಿರುವುದರಿಂದ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ನಿಯಮ ಕೆಲಸ ಮಾಡುವ ನಿಯಮ ಅಲ್ಲ.