OpenVPN ಮೇಲೆ SSM: ಒಂದು ಮೂಲ ಮತ್ತು ಗುಂಪನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಅನುಸರಿಸುವುದು

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

ಮೊದಲು ಮೂಲ, ಗುಂಪು ಮತ್ತು ಸ್ವೀಕರಿಸುವವರನ್ನು ನಿಗದಿಪಡಿಸಿ

ಯಾವುದೇ ಸಾಧನವನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಮೂರು ಮೌಲ್ಯಗಳನ್ನು ಬರೆಯಿರಿ: ಕಳುಹಿಸುವ ಮೂಲ ವಿಳಾಸ, ಸ್ವೀಕರಿಸುವವರು ಸೇರುವ ಗುಂಪು ವಿಳಾಸ, ಮತ್ತು ಸ್ವೀಕರಿಸುವವರು ಇರುವ ಉಪಜಾಲ. ಒಂದು ಉದಾಹರಣೆ IPv4 ಸ್ಟ್ರೀಮ್ಗೆ, 10.50.0.10 ಮೂಲ ಮತ್ತು 232.20.30.40 ಗುಂಪು ಮೂಲ-ನಿರ್ದಿಷ್ಟ ವಿನ್ಯಾಸಕ್ಕೆ ಹೊಂದುವ ಜೋಡಿ ಪ್ರಕಾರ. ಈ ಮೂರು ಮೌಲ್ಯಗಳಿಗಿಂತ ಅಸ್ಪಷ್ಟವಾದ ಯಾವುದನ್ನೂ ಪರೀಕ್ಷಿಸಲಾಗುವುದಿಲ್ಲ.

232/8 ಶ್ರೇಣಿಯು ಮೂಲ-ನಿರ್ದಿಷ್ಟ ಮಲ್ಟಿಕಾಸ್ಟ್ಗೆ ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ, ಮತ್ತು ಮಾದರಿಯನ್ನು RFC 4607 ನಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ. ನೀವು SSM ಚಲಾಯಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ನಂಬುತ್ತಿರುವಾಗ ನಿಮ್ಮ ಗುಂಪು ಆ ಶ್ರೇಣಿಯ ಹೊರಗಿದ್ದರೆ, ನಿಲ್ಲಿಸಿ ಮತ್ತು ನಿಯೋಜನೆ ನಿಜವಾಗಿ ಏನನ್ನು ಉದ್ದೇಶಿಸಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಸ್ವೀಕರಿಸುವವರ ಸೇರ್ಪಡೆ ಮತ್ತು ರೌಟರ್ನ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ನಿರ್ಧಾರ ಎರಡೂ ಮಾದರಿಯು ಸುಸಂಗತವಾಗಿರುವುದನ್ನು ಅವಲಂಬಿಸಿವೆ.

ಸ್ವೀಕರಿಸುವವರು ಮೂಲಕ್ಕೆ ಸೇರಿದ್ದಾರೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ

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

Linux ಸ್ವೀಕರಿಸುವವರಲ್ಲಿ, ಸಾಕೆಟ್ ನಿಜವಾಗಿ ಯಾವುದಕ್ಕೆ ಚಂದಾದಾರರಾಗಿದೆ ಮತ್ತು ಕರ್ನೆಲ್ ಏನನ್ನು ದಾಖಲಿಸಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ನ ಸಂರಚನಾ ಫೈಲ್ ಸಾಕ್ಷ್ಯವಲ್ಲ; ಸದಸ್ಯತ್ವ ಕೋಷ್ಟಕ ಸಾಕ್ಷ್ಯ. ಸ್ವೀಕರಿಸುವವರು ನಿಜವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಅದನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಅದನ್ನು ರಚಿಸಿದ ಪ್ರಕ್ರಿಯೆ ನಿರ್ಗಮಿಸಿದ ನಂತರವೂ ನಮೂದು ಸ್ವಲ್ಪ ಸಮಯ ಉಳಿಯಬಹುದು. ಹಿಂದಿನ ಪರೀಕ್ಷೆಯ ಹಳೆಯ ನಮೂದು ತಪ್ಪು ಆತ್ಮವಿಶ್ವಾಸದ ನಂಬಲರ್ಹ ಮೂಲವಾಗಿದೆ.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

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

ಸುರಂಗವನ್ನು ನೋಡುವ ಮೊದಲು ಹಿಂದಿನ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

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

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

ನಂತರ ಮೂಲದ TTL ನೀವು ವಿನ್ಯಾಸ ಮಾಡಿದ ರೌಟ್ ಮಾಡಿದ ಹಾಪ್ಗಳನ್ನು ದಾಟಲು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಮೊದಲ ರೌಟರ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಎರಡನೆಯದರಲ್ಲಿ ಸಾಯುವ ಸ್ಟ್ರೀಮ್ ಹೆಚ್ಚಾಗಿ TTL ಪ್ರಶ್ನೆ, ನೀತಿ ಪ್ರಶ್ನೆ ಅಲ್ಲ.

ಸಂರಚನೆಯ ಬದಲು ಕರ್ನೆಲ್ನ ಮಲ್ಟಿಕಾಸ್ಟ್ ಸ್ಥಿತಿಯನ್ನು ಓದಿ

ಸಂರಚನೆ ನೀವು ಏನನ್ನು ಕೇಳಿದಿರಿ ಎಂದು ಹೇಳುತ್ತದೆ; ಕರ್ನೆಲ್ ಏನಾಗುತ್ತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಪ್ರತಿ Linux ಹಾಪ್ನಲ್ಲಿ, ಮಲ್ಟಿಕಾಸ್ಟ್ ರೂಟಿಂಗ್ ನಮೂದುಗಳನ್ನು ಓದಿ ಮತ್ತು ನಿಖರವಾದ ಮೂಲ-ಗುಂಪು ಜೋಡಿಗೆ ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್ಗಳ ಪಟ್ಟಿ ಇದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ವೈಲ್ಡ್ಕಾರ್ಡ್ ಮೂಲದೊಂದಿಗೆ ಗುಂಪಿನ ನಮೂದು ಬೇರೆ ವಸ್ತು, ಮತ್ತು ಅದು ಮೂಲ-ನಿರ್ದಿಷ್ಟ ಹರಿವನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

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

ಸುರಂಗವು ನಿಜವಾಗಿ ಹೇಗೆ ಪ್ರತಿಕೃತಿ ಮಾಡುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ

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

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

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