ಯೋಜನೆ ಇಲ್ಲದೆ ಮಲ್ಟಿಕಾಸ್ಟ್ VPN ದಾಟದಿರುವುದೇಕೆ

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

ಗುಂಪು ಮತ್ತು ಅಪ್ಲಿಕೇಶನಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ

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

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

ಲಿಂಕ್-ಸ್ಥಳೀಯ ಶೋಧ ನಿಲ್ಲಬೇಕು

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

ಪುನರಾವರ್ತಕಗಳು ಮತ್ತು ಪ್ರತಿಬಿಂಬಕಗಳು ಇವೆ, ಮತ್ತು ಅವು ನಿಜವಾದ ಪರಿಣಾಮಗಳಿರುವ ನಿಜವಾದ ಸೇವೆಗಳು: ಒಂದು ಸೈಟ್ನಲ್ಲಿ ಘೋಷಿಸಿದ ಪ್ರತಿ ಹೆಸರೂ ಇನ್ನೊಂದರಲ್ಲಿ ಗೋಚರವಾಗುತ್ತದೆ, ಜನರು ಅಥವಾ ಉಪಕರಣಗಳನ್ನು ಗುರುತಿಸುವ ಸಾಧನ ಹೆಸರುಗಳೂ ಸೇರಿ. ನಿಜವಾದ ಅಗತ್ಯ ನಿರ್ದಿಷ್ಟ ಸೇವೆ ಹುಡುಕಲು ಸಿಗುವುದಾದರೆ, DNS ನಲ್ಲಿ ಪ್ರಕಟಿಸಿದ ಸೇವಾ ದಾಖಲೆ ಸಾಮಾನ್ಯವಾಗಿ ಚಿಕ್ಕ ಬದಲಾವಣೆ, ಮತ್ತು ಅದು ಹೆಸರುಗಳ ಹರಿವಿನ ಬದಲು ಒಂದು ಹೆಸರನ್ನು ಮಾತ್ರ ಬಯಲು ಮಾಡುತ್ತದೆ.

ರೂಟೆಡ್ ಮಲ್ಟಿಕಾಸ್ಟ್ಗೆ ಬೇಕಾದ ಮೂರು ವಿಷಯಗಳು

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

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

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

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

ಒಂದು ಮೂಲ ಮತ್ತು ಒಂದು ಸ್ವೀಕರಿಸುವವರಿಂದ ಸಾಬೀತುಪಡಿಸಿ

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

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

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

ಸೇವೆ ಮಾತ್ರ ಬೇಕಾದರೆ ಸೇವಾ ವಿಳಾಸವನ್ನು ಆರಿಸಿ

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

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