VPN ಮೂಲಕ ಸಂಪರ್ಕಿತ ಎರಡು ಕಚೇರಿಗಳ ನಡುವಿನ ಪ್ರವೇಶವನ್ನು ಹೇಗೆ ಮಿತಿಗೊಳಿಸುವುದು

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

ಈ ಕ್ರಮದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ, ಮತ್ತು ಕೆಳಗಿನ ನೀತಿ ಹಂತಗಳು ಉತ್ತೀರ್ಣವಾಗುವವರೆಗೆ ಟನೆಲ್ ಮಾರ್ಗವನ್ನು ವಿಸ್ತರಿಸಬೇಡಿ.

ಗೇಟ್ವೇ ಮುಟ್ಟುವ ಮೊದಲು ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಬರೆಯಿರಿ

ಉಪಯುಕ್ತ ಸಾಲು ಮೂರನ್ನು ಹೆಸರಿಸುತ್ತದೆ: ಮೂಲ ಗುಂಪು, ಗಮ್ಯ ಹೋಸ್ಟ್ ಅಥವಾ ಸೇವಾ ಜಾಲ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಬಳಸುವ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಪೋರ್ಟ್. ಶಾಖೆ ಮತ್ತು ಡೇಟಾ ಸೆಂಟರ್ ನಮೂದುಗಳಲ್ಲ. ಖಾಸಗಿ DNS ಮತ್ತು ದೃಢೀಕರಣ ಸೇವೆಗಳು ತಮ್ಮದೇ ಸಾಲುಗಳನ್ನು ಪಡೆಯುವುದು ಅಪ್ಲಿಕೇಶನ್ ಅವುಗಳಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡಲಾಗದಿದ್ದಾಗ ಮಾತ್ರ.

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

ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಡಿಕ್ರಿಪ್ಟ್ ಮಾಡುವಲ್ಲಿಯೇ ಜಾರಿಗೊಳಿಸಿ

IKE ಮತ್ತು ESP ಗೆ ಅನುಮತಿ ನೀಡುವ ನಿಯಮಗಳು ಹೊರಗಿನ ಟನೆಲ್ ಅನ್ನು ಮಾತ್ರ ನಿರ್ಮಿಸುತ್ತವೆ. ಒಳಗಿನ ಸಂಚಾರ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ಗೆ ಬಹಿರಂಗವಾಗಿ ಬರುತ್ತದೆ, ಮತ್ತು ಅನುಮತಿ ಪಟ್ಟಿಯ ಸ್ಥಾನ ಅಲ್ಲಿಯೇ: ಡಿಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಸಾಧನದಲ್ಲಿ ಫಾರ್ವರ್ಡ್ ಸರಪಳಿ, ಡಿಫಾಲ್ಟ್ ಡ್ರಾಪ್, ಮ್ಯಾಟ್ರಿಕ್ಸ್ನ ಪ್ರತಿ ಸಾಲಿಗೆ ಒಂದು ನಿಯಮ. Linux ಗೇಟ್ವೇಗಳಲ್ಲಿ ಇದರರ್ಥ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿದೆ ಮತ್ತು ಫಿಲ್ಟರ್ ನಿಯಮಗಳು ಟನೆಲ್ ಸಾಧನದಲ್ಲಿವೆ, ಭೌತಿಕ ಅಪ್ಲಿಂಕ್ನಲ್ಲಲ್ಲ, ಎಂದು strongSwan ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗದರ್ಶಿ ವಿವರಿಸುತ್ತದೆ.

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

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT ಮತ್ತು ಅತಿವ್ಯಾಪ್ತಿ ಸಬ್ನೆಟ್ಗಳು ನಿಯಮಗಳನ್ನು ಬದಲಿಸುತ್ತವೆ

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

ಅತಿವ್ಯಾಪ್ತಿ ಶ್ರೇಣಿಗಳು ಇನ್ನೊಂದು ಬಲೆ. ಎರಡೂ 192.168.1.0/24 ಬಳಸುವ ಎರಡು ಕಚೇರಿಗಳನ್ನು ಒಂದು ಬದಿಯನ್ನು ಮ್ಯಾಪ್ ಮಾಡದೆ ಒಂದೇ ನೀತಿ ಕೋಷ್ಟಕದಲ್ಲಿ ವಿವರಿಸಲಾಗದು, ಮತ್ತು ಮ್ಯಾಪಿಂಗ್ ಘರ್ಷಣೆ-ರಹಿತ ವಿಳಾಸೀಕರಣಕ್ಕೆ ಪರ್ಯಾಯವಲ್ಲ. ನಂತರ ಬಿಚ್ಚಬೇಕಾದ ನಿಯಮಗಳನ್ನು ಬರೆಯುವ ಮೊದಲು ಯೋಜನೆಯನ್ನು ಸರಿಪಡಿಸಿ.

ನಿರಾಕರಣೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ, ಕೇವಲ ಯಶಸ್ಸನ್ನಲ್ಲ

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

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

ಪಟ್ಟಿಯನ್ನು ಜೀವಂತವಾಗಿರಿಸಿ

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

ಟನೆಲ್ ಹಿಂದೆಯೂ ಹೋಸ್ಟ್ ಮಟ್ಟದ ನಿರ್ಬಂಧಗಳು ಮುಖ್ಯ: ಸರ್ವರ್ನ ಸ್ವಂತ ಫೈರ್ವಾಲ್ ಶಾಖಾ ಶ್ರೇಣಿಯನ್ನು ಅದು ಪ್ರಕಟಿಸುವ ಸೇವೆಗೆ ಮಾತ್ರ ಸ್ವೀಕರಿಸಬೇಕು. ಎರಡು ಪದರಗಳು ಒಪ್ಪುವುದು ಸಂಪೂರ್ಣವಾಗಿ ನಂಬುವ ಒಂದೇ ಪದರಕ್ಕಿಂತ ಪರಿಶೀಲಿಸಲು ಸುಲಭ.