ಸೈಟ್-ಟು-ಸೈಟ್ VPN: ಯಾವ ದಿಕ್ಕಿಗೆ ನಿಜವಾಗಿ ನಿಯಮ ಬೇಕು?

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

ಸ್ಟೇಟ್ಫುಲ್ ಮರಳುವ ಸಂಚಾರ ಎಣಿಕೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ

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

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

ಫೈರ್ವಾಲ್ ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಎಲ್ಲಿ ನೋಡುತ್ತದೆ

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

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

ಅಸಮ್ಮಿತ ರೌಟಿಂಗ್ ಊಹೆಯನ್ನು ಮುರಿಯುತ್ತದೆ

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

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

ನಿಜವಾದ ಮೂಲ ವಿಳಾಸಗಳೊಂದಿಗೆ ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

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

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

ದೂರದ ಗೇಟ್ವೇಯಲ್ಲಿ ಅನಿರೀಕ್ಷಿತ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಕಾಣುವ ವಿನಂತಿ ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗದ ನಿಯಮವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ತಪ್ಪು ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುವ ಪ್ರತ್ಯುತ್ತರ ಸ್ಟೇಟ್ ಹೊಂದಿಕೆಯಾಗದಿರುವುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ನಂತರ ಅನುಮೋದಿತ ವ್ಯಾಪ್ತಿಯೊಳಗಿನ ಒಂದು ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಅದರ ಹೊರಗಿನ ಒಂದನ್ನು ಪರೀಕ್ಷಿಸಿ, ಇದರಿಂದ ಮಿತಿಯನ್ನು ಊಹಿಸದೆ ತೋರಿಸಲಾಗುತ್ತದೆ.

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