VPN ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು LAN: ಯಾವಾಗ ಪ್ರತ್ಯೇಕ ವಲಯ ಬಳಸಬೇಕು

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

ವಲಯದ ಹೆಸರು ಏನನ್ನೂ ಗೂಢಲಿಪೀಕರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಬಳಕೆದಾರರನ್ನು ದೃಢೀಕರಿಸುವುದಿಲ್ಲ. ಅದು ಫೈರ್‌ವಾಲ್‌ನ ನೀತಿ ಮಾದರಿಗಾಗಿ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಗುಂಪು ಮಾಡುತ್ತದೆ ಅಷ್ಟೆ.

ವಲಯ ಸದಸ್ಯತೆ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ

ವಲಯವು ಫೈರ್‌ವಾಲ್ ಮಾದರಿಯಲ್ಲಿ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಅಥವಾ ಸಂಚಾರವನ್ನು ಗುಂಪು ಮಾಡುತ್ತದೆ. ಅದರ ಇನ್‌ಪುಟ್, ಔಟ್‌ಪುಟ್ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಬಳಿಕ ಬೇರೆ ಬೇರೆ ಪಾತ್ರಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ. ಇನ್‌ಪುಟ್ ಎಂಬುದು ರೌಟರ್‌ಗೇ ಹೋಗುವ ಸಂಚಾರ; ಫಾರ್ವರ್ಡಿಂಗ್ ಎಂಬುದು ಅದರ ಮೂಲಕ ಇನ್ನೊಂದು ಹೋಸ್ಟ್‌ಗೆ ಹೋಗುವ ಸಂಚಾರ. OpenWrt ನ ವಲಯ ದಸ್ತಾವೇಜು ಇದೇ ಕಾರಣಕ್ಕೆ ಇನ್‌ಪುಟ್, ಔಟ್‌ಪುಟ್ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್‌ಗಳೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ.

VPN ವಲಯದಿಂದ LAN ವಲಯಕ್ಕೆ ನೀಡಿದ ಅನುಮತಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವಿರುದ್ಧ ಅನುಮತಿ ಅಲ್ಲ. ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮಗಳು ದಿಕ್ಕಿನಾಧಾರಿತ, ಮತ್ತು ಕ್ಲೈಂಟ್‌ನಿಂದ ಸರ್ವರ್‌ಗೆ ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡುವ ನಿಯಮ ಸರ್ವರ್‌ನಿಂದ ಕ್ಲೈಂಟ್‌ಗೆ ಅಧಿವೇಶನಗಳಿಗೆ ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ. ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕ ತೆರೆಯಬಲ್ಲ ಕ್ಲೈಂಟ್, ಸರ್ವರ್ ಹಿಂತಿರುಗಿ ಸಂಪರ್ಕ ತೆರೆಯಬಲ್ಲ ಕ್ಲೈಂಟ್ ಅಲ್ಲ.

ಈ ವ್ಯತ್ಯಾಸವೇ ಪ್ರತ್ಯೇಕ ವಲಯ ಉಪಯುಕ್ತವಾಗಲು ಕಾರಣ: ಪ್ರತಿ ದಿಕ್ಕು ಮತ್ತು ಪ್ರತಿ ಪಾತ್ರವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಬಹುದು. ಪ್ರತಿ ನಿಯಮದ ಪಕ್ಕದಲ್ಲಿ ದಿಕ್ಕನ್ನು ಬರೆಯಿರಿ.

ಮೊದಲ ನಿರ್ಧಾರ: ಇನ್‌ಪುಟ್, ಫಾರ್ವರ್ಡ್ ಅಥವಾ ಎರಡೂ

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

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

ಎರಡನೇ ನಿರ್ಧಾರ: ದೂರದ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಯಾವ ಸಂಪನ್ಮೂಲಗಳು ಬೇಕು

ನಿಯಮಗಳನ್ನು ಬರೆಯುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿಗಳು, ಗಮ್ಯಗಳು ಮತ್ತು VPN ಒದಗಿಸಬೇಕಾದ ಸೇವೆಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. ಗಮ್ಯಗಳ ಪಟ್ಟಿ ನಂಬಿಕೆಯ ಲೇಬಲ್‌ಗಿಂತ ಉಪಯುಕ್ತ, ಏಕೆಂದರೆ ಅದು ಫೈರ್‌ವಾಲ್ ಸ್ಥಳಾಂತರವನ್ನು ತಾಳಿಕೊಳ್ಳುತ್ತದೆ.

ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರವೇಶದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡಿ. ವಿಕಿಗೆ ತಲುಪುವ ದೂರದ ಕ್ಲೈಂಟ್‌ಗೆ ಅದರಿಂದಾಗಿ ರೌಟರ್‌ನ ನಿರ್ವಾಹಕ ಪುಟ ಅಥವಾ ಹೈಪರ್‌ವೈಸರ್ ಕನ್ಸೋಲ್ ಬೇಕಿಲ್ಲ.

ಅನುಮತಿಸಿದ ಗಮ್ಯ ಮುಂದೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಬಲ್ಲದಾದರೆ, ವಲಯದ ಗಡಿ ಫೈರ್‌ವಾಲ್‌ನಲ್ಲೇ ನಿಲ್ಲುತ್ತದೆ, ಗಮ್ಯ ಮುಂದೆ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬಲ್ಲಲ್ಲ.

ಮೂರನೇ ನಿರ್ಧಾರ: ಗಡಿಯನ್ನು ಹೇಗೆ ಸಾಬೀತುಪಡಿಸುತ್ತೀರಿ

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

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

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