ಹಬ್-ಸ್ಪೋಕ್ ಮತ್ತು ಪೂರ್ಣ ಮೆಶ್: ನಿಮ್ಮ ಸೈಟ್ಗಳಿಗೆ ಯಾವ VPN ಟೋಪಾಲಜಿ ಸರಿಹೊಂದುತ್ತದೆ
ಎರಡು ಕೆಲಸ ಮಾಡುವ ಸುರಂಗಗಳು ಟೋಪಾಲಜಿ ಅಲ್ಲ. ಹಬ್, ಮೆಶ್ ಅಥವಾ ಕೆಲವು ನೇರ ಸಂಪರ್ಕಗಳಿರುವ ಹಬ್ ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಟ್ರಾನ್ಸಿಟ್, ವೈಫಲ್ಯ ವರ್ತನೆ ಮತ್ತು ಬದಲಾವಣೆ ವೆಚ್ಚವನ್ನು ಹೋಲಿಸಿ.
ಎರಡು ಶಾಖಾ ಕಚೇರಿಗಳು ದಿನವಿಡೀ ಪರಸ್ಪರ ಮಾತನಾಡುತ್ತವೆ, ಆದರೆ ಅವುಗಳ ನಡುವಿನ ಸುರಂಗವು ಬೇರೆ ಪ್ರದೇಶದ ಡೇಟಾಸೆಂಟರ್ ಮೂಲಕ ಸುತ್ತು ಹಾಕುತ್ತದೆ. ಪ್ರತಿ ವಿನಂತಿಯೂ ಆ ಸುತ್ತಿನ ಬೆಲೆಯನ್ನು ಎರಡು ಬಾರಿ ತೆರುತ್ತದೆ, ಮತ್ತು ಕಡತ ಸಿಂಕ್ ತಪ್ಪೆನಿಸುವವರೆಗೆ ಯಾರೂ ಅದನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ. ಟೋಪಾಲಜಿಯ ಪ್ರಶ್ನೆ ನಿಜವಾಗಿ ಇಲ್ಲಿಂದ ಆರಂಭವಾಗುತ್ತದೆ: ಯಾವ ರೇಖಾಚಿತ್ರ ಹೆಚ್ಚು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಕಾಣುತ್ತದೆ ಎಂಬುದಲ್ಲ, ನೀವು ಯಾವ ಸಂಚಾರ ಮಾದರಿಗೆ ಹಣ ತೆರುತ್ತಿದ್ದೀರಿ ಎಂಬುದು. ಎರಡೂ ವಿನ್ಯಾಸಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಅವು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ, ಬೇರೆ ಬೇರೆ ವೆಚ್ಚದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ.
ಮೊದಲು ಪೀರ್ ಸಂಬಂಧಗಳನ್ನು ಎಣಿಸಿ
ಎನ್ ಸೈಟ್ಗಳಿದ್ದರೆ, ಪೂರ್ಣ ಮೆಶ್ಗೆ ಎನ್ ಗುಣಿಸು ಎನ್ ಮೈನಸ್ ಒಂದು, ಎರಡರಿಂದ ಭಾಗಿಸಿ, ಸುರಂಗಗಳು ಬೇಕು; ಹಬ್ಗೆ ಎನ್ ಸಾಕು. ಐದು ಸೈಟ್ಗಳಲ್ಲಿ ಅದು ಹತ್ತು ವಿರುದ್ಧ ಐದು, ಇದು ಇನ್ನೂ ನಿಭಾಯಿಸಬಹುದಾದಂತೆ ಕೇಳುತ್ತದೆ. ಹದಿನೈದರಲ್ಲಿ ಅದು 105 ವಿರುದ್ಧ ಹದಿನೈದು, ಮತ್ತು ವ್ಯತ್ಯಾಸ ಇನ್ನು ಅಂಕಗಣಿತವಲ್ಲ, ಸಿಬ್ಬಂದಿ.
ಆ ಪ್ರತಿಯೊಂದು ಸಂಬಂಧವೂ ನೀವು ಹೊಂದಿರಬೇಕಾದ ಸ್ಥಿತಿಯನ್ನು ಹೊತ್ತಿರುತ್ತದೆ. IPsec ನಲ್ಲಿ ಇದರ ಅರ್ಥ ಭದ್ರತಾ ಸಂಘ, ಗುರುತು, ಕೀ ಅಥವಾ ಪ್ರಮಾಣಪತ್ರ, ಡೆಡ್-ಪೀರ್ ಪತ್ತೆ ಮತ್ತು ಪ್ರತಿ ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಕನಿಷ್ಠ ಒಂದು ರೂಟ್. WireGuard ನಲ್ಲಿ ಇದರ ಅರ್ಥ ಪ್ರತಿ ಪೀರ್ಗೆ ಒಂದು ಸಾರ್ವಜನಿಕ ಕೀ ಮತ್ತು ಒಂದು AllowedIPs ಬ್ಲಾಕ್, ಇದು ಪ್ರತಿ ಪೀರ್ಗೆ ಅಗ್ಗವಾದರೂ ಶೋಧನೆ ಸ್ವಲ್ಪವೂ ಇಲ್ಲದೆ ಬರುತ್ತದೆ: ಹೊಸ ಸೈಟ್ ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪ್ರತಿ ಹಳೆಯ ಸೈಟ್ನಲ್ಲೂ ಸಂರಚನಾ ಬದಲಾವಣೆಯೇ.
ನಿರ್ಧಾರ ರೇಖಾಚಿತ್ರವಲ್ಲ, ಸಂಚಾರ ಮಿಶ್ರಣ ಮಾಡಲಿ
ಶಾಖಾ ಸಂಚಾರ ಹೆಚ್ಚಾಗಿ ಕೇಂದ್ರ ERP ಅಥವಾ ಕಡತ ಕ್ಲಸ್ಟರ್ಗೆ ವಿನಂತಿಗಳಾಗಿದ್ದರೆ, ಹಬ್ ರಾಜಿಯಲ್ಲ, ಅದು ಸರಿಯಾದ ಆಕಾರ: ಸಂಚಾರ ಈಗಾಗಲೇ ಅಲ್ಲಿಗೆ ಹೋಗಲು ಬಯಸುತ್ತಿತ್ತು, ಮತ್ತು ಒಂದು ನೀತಿ ಬಿಂದು ಜೋಡಿ-ವಾರು ನಿಯಮಗಳ ಮೆಶ್ಗಿಂತ ಪರಿಶೀಲಿಸಲು ಸುಲಭ. ಶಾಖೆಗಳು ಪರಸ್ಪರ ಡೇಟಾ ವಿನಿಮಯ ಮಾಡಿದಾಗ — ಎರಡು ಕಚೇರಿಗಳ ನಡುವೆ ಪ್ರತಿಕೃತಿ, ಸೈಟ್ಗಳ ನಡುವೆ ಧ್ವನಿ, ಡಜನ್ ಎಂಜಿನಿಯರ್ಗಳು ದಿನವಿಡೀ ತೆರೆಯುವ CAD ಹಂಚಿಕೆ — ಮೆಶ್ ತನ್ನ ಸಂಕೀರ್ಣತೆಯನ್ನು ಗಳಿಸುತ್ತದೆ.
ಅಪರೂಪದ ಪ್ರಕರಣಗಳು ನಡುವೆ ಇರುತ್ತವೆ, ಮತ್ತು ಅವೇ ಬಹುಸಂಖ್ಯೆ. ಸಂಸ್ಥೆ ಚಾರ್ಟ್ನಿಂದ ಊಹಿಸುವ ಬದಲು ವಾದ ಮಾಡುವ ಮೊದಲು ಅಳೆಯಿರಿ.
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
ಟೇಬಲ್ ಅನ್ನು ನಿಯಮವಲ್ಲ, ತೀರ್ಪುಗಾರನಾಗಿ ಓದಿ. ನಾಲ್ಕರಲ್ಲಿ ಮೂರು ಸಾಲುಗಳು ಒಂದೇ ಕಡೆಗೆ ತೋರಿಸಿದರೆ ಸಾಮಾನ್ಯವಾಗಿ ವಿನ್ಯಾಸ ನಿರ್ಣಯವಾಗುತ್ತದೆ; ವಿಭಜನೆ ಎಂದರೆ ಮಿಶ್ರ ವಿನ್ಯಾಸ, ಬಹುಪಾಲು ಪ್ರಬುದ್ಧ ಜಾಲಗಳು ಕೊನೆಗೆ ಅದನ್ನೇ ನಡೆಸುತ್ತವೆ.
ಹಬ್ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಹೇಳಬೇಕು
ಎರಡು ಕೆಲಸ ಮಾಡುವ ಸ್ಪೋಕ್-ಟು-ಹಬ್ ಸುರಂಗಗಳು ಸ್ಪೋಕ್-ಟು-ಸ್ಪೋಕ್ ಪ್ರವೇಶವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಹಬ್ನಲ್ಲಿ IP ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿರಬೇಕು, ಪ್ರತಿ ಸ್ಪೋಕ್ ಜಾಲಕ್ಕೆ ರೂಟ್ ಬೇಕು, ಆ ಮಾರ್ಗಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡುವ ಫೈರ್ವಾಲ್ ನಿಯಮ ಬೇಕು ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಲೆಕ್ಕಹಾಕಬೇಕು; ಪ್ರತಿ ಸ್ಪೋಕ್ಗೆ ಇನ್ನೊಂದು ಸೈಟ್ನ ಪ್ರಿಫಿಕ್ಸ್ಗಳಿಗೆ ರೂಟ್ ಬೇಕು. Linux ಹಬ್ನಲ್ಲಿ ಅದು net.ipv4.ip_forward=1 ಜೊತೆಗೆ FORWARD ಚೈನ್, ಅದು ಆ ಜೋಡಿಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಡಬಾರದು; ಮತ್ತು ನೀತಿ-ಆಧಾರಿತ IPsec ನಲ್ಲಿ ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ದೂರದ ಸ್ಪೋಕ್ ಉಪಜಾಲವನ್ನು ಪಟ್ಟಿ ಮಾಡುವ ಟ್ರಾಫಿಕ್ ಸೆಲೆಕ್ಟರ್ಗಳು ಬೇಕು. strongSwan ನ ಫಾರ್ವರ್ಡಿಂಗ್ ಟಿಪ್ಪಣಿಗಳು ನೀವು ಕಳೆದುಕೊಂಡ ಪದರ ಅದೇ ಆದಾಗ ಕರ್ನಲ್ ಮತ್ತು ಫೈರ್ವಾಲ್ ಭಾಗವನ್ನು ಒಳಗೊಳ್ಳುತ್ತವೆ. ಅಗ್ಗದ ಪರೀಕ್ಷೆ ಎಂದರೆ ಒಂದು ಸ್ಪೋಕ್ನಿಂದ ಇನ್ನೊಂದರ ಸೇವೆಗೆ ಸಂಚಾರ ಕಳುಹಿಸುತ್ತಾ ಹಬ್ನ ಕೌಂಟರ್ಗಳನ್ನು ನೋಡುವುದು; ಎಂದೂ ಹೆಚ್ಚದ ನಿಯಮ ಎಂದರೆ ರೂಟ್ ಅಲ್ಲ, ಕ್ರಮ ತಪ್ಪು.
ಕೇಂದ್ರ ನೀತಿಯೇ ಉಪಯುಕ್ತ ಭಾಗ. ಶಾಖೆಗಳು ಒಂದನ್ನೊಂದು ತಲುಪದೆ ಹಂಚಿದ ಸೇವೆಗಳನ್ನು ತಲುಪಲು ಅನುಮತಿ ನೀಡಬಹುದು, ಮತ್ತು ಆ ಪ್ರವೇಶ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಬರೆದಿಡುವುದು ಯೋಗ್ಯ. ಕಾಣೆಯಾದ ರೂಟ್ಗಳು ಯಾರಾದರೂ ಓದಬಹುದಾದ ನಿಯಮಕ್ಕೆ ಕೆಟ್ಟ ಪರ್ಯಾಯ.
ಅರ್ಧ ಮುಗಿದ ಆವೃತ್ತಿಯನ್ನು ಗಮನಿಸಿ: ಸ್ಪೋಕ್ A ಹಬ್ ಮೂಲಕ ಸ್ಪೋಕ್ B ಗೆ ರೂಟ್ ಆಗುತ್ತದೆ, ಹಬ್ ಎರಡೂ ಕಡೆ ರೂಟ್ ಆಗುತ್ತದೆ, ಮತ್ತು ಹಬ್ನ ಫೈರ್ವಾಲ್ A ಯಿಂದ ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಆದರೆ B ಯಿಂದ ಅಲ್ಲ. ಮೊದಲ ದಿಕ್ಕು ಚೆನ್ನಾಗಿ ಪರೀಕ್ಷೆಯಾಗುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯದು ನೇತಾಡುತ್ತದೆ, ಅದು ರೂಟಿಂಗ್ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅಲ್ಲ.
ಮೊದಲು ವೈಫಲ್ಯವನ್ನು ವಿನ್ಯಾಸ ಮಾಡಿ, ನಂತರ ಸಾಮಾನ್ಯ ಮಾರ್ಗ
ಒಂದೇ ಹಬ್ ಹಂಚಿದ ಅವಲಂಬನೆ ಮತ್ತು ಮಾರ್ಗಸಂಚಾರದ ಕೊರಳೆ, ಮತ್ತು ಹಬ್ ವಿನ್ಯಾಸಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲಿ ತಪ್ಪಾಗುತ್ತವೆ. ಎರಡು ಹಬ್ ಎಂದರೆ ಪ್ರತಿ ಸ್ಪೋಕ್ ಎರಡು ಸುರಂಗಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಹೊರಹೋಗುವ ಮಾರ್ಗಕ್ಕೆ ಒಪ್ಪಬೇಕು; ಒಪ್ಪದಿದ್ದರೆ ಸ್ಟೇಟ್ಫುಲ್ ಫೈರ್ವಾಲ್ ಉತ್ತರಗಳನ್ನು ಬಿಡುತ್ತದೆ ಮತ್ತು ಲಕ್ಷಣ ಎಂದರೆ ತೆರೆದು ನಂತರ ಸಾಯುವ ಸಂಪರ್ಕ. ದೊಡ್ಡ ನಿಯೋಜನೆಗಳು ಇದನ್ನು ಸ್ಥಿರ ಪ್ರಿಫಿಕ್ಸ್ಗಳ ಬದಲು ಸುರಂಗಗಳ ಮೇಲಿನ ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ನಿಂದ ಪರಿಹರಿಸುತ್ತವೆ, ಅದು ಹೆಚ್ಚು ಯಂತ್ರೋಪಕರಣ ಆದರೆ ಊಹೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ನೀವು ಏನು ಆರಿಸಿದರೂ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಹೊರಹೋಗುವ ಮಾರ್ಗದ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಯಾರೂ ಪರೀಕ್ಷಿಸದ ಭಾಗ ಅದೇ.
ಮೆಶ್ ಆ ಅಪಾಯವನ್ನು ಹಂಚುತ್ತದೆ: ಒಂದು ಸೈಟ್ನ ಸಂಪರ್ಕ ಕುಸಿದರೆ ಉಳಿದವು ಪ್ರತ್ಯೇಕವಾಗುವುದಿಲ್ಲ. ಅದು ಮಾರ್ಗ ಆಯ್ಕೆ ನಿಮ್ಮನ್ನು ಬೆಚ್ಚಿಬೀಳಿಸಬಹುದಾದ ಸ್ಥಳಗಳನ್ನು ಗುಣಿಸುತ್ತದೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸೆಷನ್ಗಳು ಸಹಾಯವಿಲ್ಲದೆ ಮಾರ್ಗ ಬದಲಾವಣೆಯನ್ನು ಇನ್ನೂ ಬದುಕಲಾರವು.
ಫೇಲೋವರ್ನಾದ್ಯಂತ TCP ಸೆಷನ್ ಅನ್ನು ಯಾವ ವಿನ್ಯಾಸವೂ ತಾನೇ ಜೀವಂತವಾಗಿ ಇಡುವುದಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಲಾಗದಿದ್ದರೆ, ಟೋಪಾಲಜಿ ನಿಮ್ಮ ಸಮಸ್ಯೆ ಅಲ್ಲ.
ಬದಲಾವಣೆ ವೆಚ್ಚದಿಂದ ಆರಿಸಿ, ನಂತರ ರೂಟ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ
ಹಬ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ತಪ್ಪಾಗುವುದು ಅಲ್ಲಿಯೇ ಅಗ್ಗ, ಮತ್ತು ಸಂಚಾರ ಸಮರ್ಥಿಸುವ ಜೋಡಿಗಳಿಗೆ ನೇರ ಸುರಂಗಗಳನ್ನು ಸೇರಿಸಿ. ಆ ಮಿಶ್ರ ವಿನ್ಯಾಸ ನಿರ್ಧಾರ ಮಾಡದಿರುವಿಕೆ ಅಲ್ಲ; ಬಹುಪಾಲು ಸಂಸ್ಥೆಗಳು ಒಂದು ವರ್ಷದೊಳಗೆ ತಲುಪುವ ವಿನ್ಯಾಸವೇ ಅದು. ಮುಖ್ಯವಾದದ್ದು ಪ್ರತಿ ನೇರ ಸಂಪರ್ಕಕ್ಕೂ ಹೇಳಲಾದ ಕಾರಣ ಮತ್ತು ಒಬ್ಬ ಜವಾಬ್ದಾರ ಇರುವುದು.
ಎರಡು ರೇಖಾಚಿತ್ರಗಳನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಒಂದನ್ನಲ್ಲ. ಸಾಮಾನ್ಯ ಮಾರ್ಗಕ್ಕೆ traceroute ಪ್ರತಿ ಸೈಟ್ನಿಂದ ಪ್ರತಿ ಸೇವಾ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಚಲಾಯಿಸಿ ಮತ್ತು ಹಾಪ್ಗಳು ರೇಖಾಚಿತ್ರಕ್ಕೆ ಹೊಂದುತ್ತವೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ. ವೈಫಲ್ಯ ಮಾರ್ಗಕ್ಕೆ, ಒಂದು ಸುರಂಗವನ್ನು ಮುಚ್ಚಿ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಎಲ್ಲವೂ ಚಾಲ್ತಿಯಲ್ಲಿರುವಾಗ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ರೂಟ್ ವಿನ್ಯಾಸವಾಗಿಲ್ಲ, ಸಂರಚನೆ ಮಾತ್ರ.
ಎರಡೂ ರೇಖಾಚಿತ್ರಗಳನ್ನು ಪ್ರವೇಶ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಜೊತೆ ಇಟ್ಟುಕೊಳ್ಳಿ, ಸೈಟ್ ಸೇರಿಸಿದಾಗ ಮತ್ತೆ ನೋಡಿ; ನೀವು ನಿರ್ವಹಿಸುತ್ತಿರುವ ವೆಚ್ಚ ಮುಂದಿನ ಬದಲಾವಣೆಯ ವೆಚ್ಚ, ಈಗಿನ ಚಿತ್ರದ ಸೊಗಸಲ್ಲ.