ಸೈಟ್-ಟು-ಸೈಟ್ VPN ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಎರಡು ಬೇರೆ ಬೇರೆ ದೋಷಗಳು

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

ಈ ವ್ಯತ್ಯಾಸವೇ ಯಾವ ಆದೇಶಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಯೋಗ್ಯ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎರಡು ದೋಷಗಳು

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

ವಿಫಲವಾದ ಪ್ರಯತ್ನವನ್ನು ಯಾವ ಬದಿ ಪ್ರಾರಂಭಿಸಿತು ಎಂದು ಕೇಳಿ. ಆ ಒಂದು ಸತ್ಯವೇ ಅರ್ಧದಷ್ಟು ಸಂಭಾವ್ಯ ಕಾರಣಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

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

ಮೊದಲ ಸಂದರ್ಭ: ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಇಲ್ಲ

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

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

ಎರಡನೇ ಸಂದರ್ಭ: ನೀತಿ ಅದನ್ನು ಎಂದಿಗೂ ಅನುಮತಿಸಲಿಲ್ಲ

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

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

ಅದೇ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಮೊದಲು ಮತ್ತು ನಂತರ ಹೋಲಿಸಿ

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

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

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

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