ಶಾಖೆ ಮತ್ತು ಪ್ರಯೋಗಾಲಯದ ನಡುವಿನ ಸಂಪರ್ಕಕ್ಕಾಗಿ ರೂಟೆಡ್ VPN ಅಥವಾ ಬ್ರಿಡ್ಜ್ಡ್ LAN

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

ಸಂಪರ್ಕಿಸಲು ಎರಡು ಮಾರ್ಗಗಳು, ಒಂದು ಸ್ಪಷ್ಟ ರಾಜಿ

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

ಬ್ರಿಡ್ಜ್ಡ್ ಸಂಪರ್ಕವು ಒಂದೇ ಲೇಯರ್ 2 ಕ್ಷೇತ್ರವನ್ನು ಎರಡೂ ಸೈಟ್ಗಳ ಮೇಲೆ ವಿಸ್ತರಿಸುತ್ತದೆ. ಅನ್ವೇಷಣಾ ಪ್ರೋಟೋಕಾಲ್ಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಸಾಧನಗಳು ತಾವಾಗಿಯೇ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿ ಪ್ರಸಾರ, ಪ್ರತಿ ARP ವಿನಂತಿ ಮತ್ತು ಪ್ರತಿ multicast ಪ್ಯಾಕೆಟ್ ಈಗ ಸುರಂಗವನ್ನು ದಾಟುವ ಅಭ್ಯರ್ಥಿಯಾಗಿದೆ, ಅಂದರೆ ಸ್ಥಳೀಯ ವಿಭಾಗಕ್ಕಾಗಿ ನಿರ್ಮಿಸಿದ ಪ್ರೋಟೋಕಾಲ್ಗಳು ಸಾಗಿಸುವ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಸಂಚಾರ, ಬೇರೆ MTU ಮತ್ತು ಬದಲಾಗುವ ಸುತ್ತು-ಪ್ರಯಾಣ ಸಮಯವಿರುವ WAN ಗಾಗಿ ಅಲ್ಲ.

ರೂಟಿಂಗ್ ನಿಮಗೆ ಏನು ನೀಡುತ್ತದೆ

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

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

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

ನೀವು ಬಿಟ್ಟುಕೊಡುವುದು ಪ್ರಸಾರದ ಮೂಲಕ ಅನ್ವೇಷಣೆ. ಇದು ನಿಜವಾದ ನಷ್ಟ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಬ್ರಿಡ್ಜ್ ಮಾಡಿ ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ಬದಲು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬದಲಾಯಿಸಬೇಕು.

ಬ್ರಿಡ್ಜಿಂಗ್ ವೆಚ್ಚ

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

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

ಭದ್ರತಾ ವಾದವು ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ಣಯಿಸುತ್ತದೆ. ಬ್ರಿಡ್ಜ್ ಲಿಂಕ್-ಲೋಕಲ್ ಪ್ರೋಟೋಕಾಲ್ಗಳು ಕೆಲಸ ಮಾಡುವ ವಿಭಾಗವನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಶಾಖೆಯಲ್ಲಿನ ಸಾಧನವು ಹೊರಗಿನಿಂದ ತಲುಪಬಾರದ ಪ್ರಯೋಗಾಲಯ ಸಾಧನಗಳೊಂದಿಗೆ ಮಾತನಾಡಬಹುದು. ಪ್ರಯೋಗಾಲಯದಲ್ಲಿ ಅದೇ ಚಪ್ಪಟೆ ಜಾಲದಲ್ಲಿ hypervisor, ಸಂಗ್ರಹಣಾ ಕನ್ಸೋಲ್ ಮತ್ತು ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್ ಇದ್ದರೆ, ಈಗ ಅದು ಶಾಖೆಯೊಂದಿಗೆ ಒಂದೇ ವಿಭಾಗ.

ಪ್ರಸಾರವಿಲ್ಲದ ಹೆಸರುಗಳು

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

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

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

ರೂಟೆಡ್ ವಿನ್ಯಾಸವನ್ನು ಪರೀಕ್ಷಿಸಬಹುದಾದಂತೆ ಮಾಡಿ

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

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

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