ಎರಡು ಶಾಖೆಗಳ ನಡುವಿನ ಸಂಚಾರವನ್ನು Azure VPN ಗೇಟ್ವೇ ಮೂಲಕ ರೂಟ್ ಮಾಡಿ
ಒಂದೇ Azure VPN ಗೇಟ್ವೇ ಮೇಲಿನ ಎರಡು ಸೈಟ್-ಟು-ಸೈಟ್ ಸಂಪರ್ಕಗಳು ಶಾಖೆಗಳ ಸಂಚಾರವನ್ನು ಹಾಯಿಸಬಲ್ಲವು, ಆದರೆ ಎರಡೂ ತುದಿಗಳು ಪ್ರಿಫಿಕ್ಸ್ ಕಲಿತಾಗ ಮತ್ತು LAN ಮರಳು ಮಾರ್ಗವಿದ್ದಾಗ ಮಾತ್ರ.
ಎರಡು ಶಾಖೆಗಳು ತಮ್ಮ ನಡುವೆ ನೇರ ಸುರಂಗವಿಲ್ಲದೆ Azure VPN ಗೇಟ್ವೇ ಮೂಲಕ ಸಂಚಾರವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬಹುದು. ಪ್ರತಿ ಶಾಖೆಯು ಅದೇ ಗೇಟ್ವೇಗೆ ಸೈಟ್-ಟು-ಸೈಟ್ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುತ್ತದೆ, ಮತ್ತು ಗೇಟ್ವೇ ಕಲಿತ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಎರಡು ಸಂಪರ್ಕಗಳ ನಡುವೆ ರವಾನಿಸುತ್ತದೆ. ಇದನ್ನು ಕೆಲಸ ಮಾಡಿಸುವುದು ಎರಡನೇ ಸುರಂಗವಲ್ಲ, ರೂಟ್ ವಿನಿಮಯ: ಶಾಖೆ A ಶಾಖೆ B ಯ ಪ್ರಿಫಿಕ್ಸ್ ಕಲಿಯಬೇಕು, ಮತ್ತು B ಶಾಖೆ A ಯದನ್ನು ಕಲಿಯಬೇಕು. ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಮೊದಲ ವಿಫಲವಾದ ಪರಿಶೀಲನೆಯಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಮುಂದಿನ ಹಂತ ಅದನ್ನು ಅವಲಂಬಿಸಿದೆ.
ಏನನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಮೊದಲು ಪೂರ್ವಷರತ್ತುಗಳು
ಈ ವಿನ್ಯಾಸವು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದೇ ಎಂಬುದನ್ನು ನಾಲ್ಕು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ. ಗೇಟ್ವೇ ರೂಟ್-ಆಧಾರಿತವಾಗಿರಬೇಕು ಮತ್ತು BGP ಬೆಂಬಲಿಸುವ SKU ನಲ್ಲಿರಬೇಕು, ಎರಡೂ ಸಂಪರ್ಕಗಳಲ್ಲಿ BGP ಸಕ್ರಿಯವಾಗಿರಬೇಕು, ಶಾಖೆಗಳ ವಿಳಾಸ ಸ್ಥಳಗಳು ಒಂದಕ್ಕೊಂದು ತುಂಬಿಕೊಳ್ಳಬಾರದು, ಮತ್ತು ಯಾವುದೇ ಬದಿಯು ತನ್ನ ನಿಜವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಮರೆಮಾಡಲು NAT ಅನ್ನು ಅವಲಂಬಿಸಬಾರದು.
ASN ಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಯೋಜಿಸಿ. Azure ನ ದಾಖಲಿತ ಡೀಫಾಲ್ಟ್ 65515, ಮತ್ತು ಪ್ರತಿ ಶಾಖೆ ರೌಟರ್ಗೆ ಗೇಟ್ವೇ ಅಥವಾ ಇನ್ನೊಂದು ಶಾಖೆಯೊಂದಿಗೆ ಘರ್ಷಣೆಯಾಗದ ತನ್ನದೇ ಖಾಸಗಿ ASN ಬೇಕು. ಇರುವ ಗೇಟ್ವೇ ಕಾನ್ಫಿಗರೇಶನ್ ಪರಿಶೀಲಿಸದೆ ಡೀಫಾಲ್ಟ್ ಮರುಬಳಕೆ ಮಾಡುವುದು AS ಮಾರ್ಗವನ್ನು ನಂತರ ತಿರಸ್ಕರಿಸುವ ದಾರಿ.
ನೀವು VNet ಪೀರಿಂಗ್ ವರ್ತನೆಯನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತಿಲ್ಲ ಎಂದು ಸಹ ಖಚಿತಪಡಿಸಿ. ಗೇಟ್ವೇ ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಎರಡು ಸಂಪರ್ಕಗಳ ನಡುವೆ ರೂಟ್ಗಳನ್ನು ವಿನಿಮಯ ಮಾಡುತ್ತದೆ; ಅದು ಅನಿಯಂತ್ರಿತ ಪೀರಿಂಗ್ಗಳನ್ನು ಪಾರಗಾಮಿ ಮಾಡುವುದಿಲ್ಲ. ಮೂರನೇ ನೆಟ್ವರ್ಕ್ ಎರಡೂ ಶಾಖೆಗಳನ್ನು ತಲುಪಬೇಕಾದರೆ, ಅದಕ್ಕೆ ತನ್ನದೇ ಸಂಪರ್ಕ ಅಥವಾ ತನ್ನದೇ ರೂಟ್ ಮಾರ್ಗ ಬೇಕು, ಗೇಟ್ವೇ ಸಂಚಾರವನ್ನು ಹಂಚುತ್ತದೆ ಎಂಬ ಊಹೆ ಅಲ್ಲ. ಮೊದಲ ಬದಲಾವಣೆ ವಿಂಡೋ ಮೊದಲು ಆ ಗಡಿಯನ್ನು ಬರೆದಿಡಿ, ಏಕೆಂದರೆ ನಂತರ ಸೈಟ್ ಸೇರಿಸಿದಾಗ ಜನರು ಹಿಂತಿರುಗಿ ನೋಡುವ ವಿನ್ಯಾಸ ನಿರ್ಧಾರ ಅದೇ.
ಈ ಕ್ರಮದಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿ
ಪ್ರತಿ ಹಂತಕ್ಕೂ ಗಮನಿಸಬಹುದಾದ ಫಲಿತಾಂಶವಿದೆ, ಆದ್ದರಿಂದ ಅದು ಕಾಣುವವರೆಗೆ ಮುಂದೆ ಹೋಗಬೇಡಿ.
- ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ ಗೇಟ್ವೇಯಲ್ಲಿ BGP ಸಕ್ರಿಯಗೊಳಿಸಿ ಮತ್ತು ಅದರ ASN ಹಾಗೂ ಪೀರ್ ವಿಳಾಸವನ್ನು ಗುರುತಿಸಿ.
- ಪ್ರತಿ ಶಾಖೆಗೆ ಆ ಶಾಖೆಯ ನಿಜವಾದ ವಿಳಾಸ ಸ್ಥಳ, ಅದರ ASN ಮತ್ತು ಅದರ BGP ಪೀರ್ ವಿಳಾಸದೊಂದಿಗೆ ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ಗೇಟ್ವೇ ರಚಿಸಿ.
- ಪ್ರತಿ ಸೈಟ್-ಟು-ಸೈಟ್ ಸಂಪರ್ಕವನ್ನು ರಚಿಸಿ ಮತ್ತು ಸಂಪರ್ಕದ ಮೇಲೆಯೇ BGP ಸಕ್ರಿಯಗೊಳಿಸಿ.
- ಶಾಖೆ ರೌಟರ್ ಅನ್ನು ಊಹೆಯ ಮೇಲೆ ಗೇಟ್ವೇಯ ಸಾರ್ವಜನಿಕ IKE ಎಂಡ್ಪಾಯಿಂಟ್ನೊಂದಿಗಲ್ಲ, Azure ನಿಯೋಜಿಸಿದ ಗೇಟ್ವೇ ವಿಳಾಸದೊಂದಿಗೆ ಪೀರ್ ಮಾಡಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ.
ನಾಲ್ಕನೇ ಹಂತದಲ್ಲೇ ಹೆಚ್ಚಿನ ಪ್ರಯತ್ನಗಳು ನಿಲ್ಲುತ್ತವೆ. Azure ವರದಿ ಮಾಡುವ BGP ಪೀರ್ ವಿಳಾಸವೇ ಶಾಖೆ ರೌಟರ್ ನೆರೆಯವರಾಗಿ ಬಳಸಬೇಕಾದದ್ದು, ಮತ್ತು ಅದು ಜನರು ಸುರಂಗ ರೇಖಾಚಿತ್ರದಿಂದ ನಿರೀಕ್ಷಿಸುವ ವಿಳಾಸವೇ ಆಗಿರಬೇಕಿಲ್ಲ.
ಶಾಖೆಯ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನೇ ಪ್ರಚಾರ ಮಾಡಿ, ಉದಾಹರಣೆಗೆ A ಯಿಂದ 10.10.0.0/16 ಮತ್ತು B ಯಿಂದ 10.20.0.0/16. ಕಾಣೆಯಾದ ನಿರ್ದಿಷ್ಟ ನೆಟ್ವರ್ಕ್ ಮುಚ್ಚಲು ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಅಥವಾ ಅಗಲವಾದ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯನ್ನು ಪ್ರಚಾರ ಮಾಡಬೇಡಿ; ಕೊರತೆ ನಂತರ ಮೌನ ಕಪ್ಪು ಕುಳಿಯಾಗಿ ಮರಳುತ್ತದೆ.
ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ರೂಟ್ ವಿನಿಮಯ ಪರಿಶೀಲಿಸಿ
ಸಂಪರ್ಕ ಸ್ಥಿತಿ ಪರಿಶೀಲನೆ ಅಲ್ಲ. ಎರಡೂ ಸಂಪರ್ಕಗಳಲ್ಲಿ IPsec ಚಾಲನೆಯಲ್ಲಿದ್ದರೂ ಅವುಗಳ ನಡುವೆ ಯಾವುದೇ ಪ್ರಿಫಿಕ್ಸ್ ಹಾದುಹೋಗದಿರಬಹುದು. ಗೇಟ್ವೇಯ BGP ಪೀರ್ ಮತ್ತು ಅದರ ಕಲಿತ ರೂಟ್ಗಳನ್ನು ಓದಿ, ನಂತರ ಇನ್ನೊಂದು ಶಾಖೆಯ ಕಡೆಗಿನ ರೂಟ್ ಬಳಸಬಹುದಾದ ಮಾರ್ಗವಾಗಿ ಕಾಣುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP ಕೋಷ್ಟಕದಲ್ಲಿರುವ ಪ್ರಿಫಿಕ್ಸ್ ಕೂಡ ಸ್ಥಿರ ರೂಟ್ ಅಥವಾ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಮುಂದಕ್ಕೆ ರವಾನಿಸುವ ನಿರ್ಧಾರವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು. ಸ್ವೀಕರಿಸಿದ ರೂಟ್ ಮಾತ್ರವಲ್ಲ, ಆಯ್ಕೆಯಾದ ರೂಟ್ ಪರಿಶೀಲಿಸಿ.
LAN ಬದಿಯಲ್ಲಿ ಮರಳು ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿ
ಇದು Azure ನಲ್ಲಿ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಸೈಟ್ನಲ್ಲಿ ವಿಫಲವಾಗುವ ಭಾಗ. ಶಾಖೆ A ಯ ಹೋಸ್ಟ್ ತನ್ನ ಪ್ಯಾಕೆಟ್ ಅನ್ನು A ಯ VPN ರೌಟರ್ಗೆ ಕಳುಹಿಸುವುದು ಆ ರೌಟರ್ ಅದರ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಆಗಿದ್ದರೆ, ಅಥವಾ ಹೋಸ್ಟ್ ಅಥವಾ ಅದರ ಗೇಟ್ವೇ ಬಳಿ B ಯ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ರೂಟ್ ಇದ್ದರೆ ಮಾತ್ರ. ಇನ್ನೊಂದು ದಿಕ್ಕಿನಲ್ಲೂ ಅದೇ ಸತ್ಯವಾಗಿರಬೇಕು.
ಪ್ರತ್ಯೇಕ ಕೋರ್ ಸ್ವಿಚ್ LAN ನ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಆಗಿದ್ದರೆ, ಅದಕ್ಕೆ VPN ರೌಟರ್ ಕಡೆಗೆ ತೋರಿಸುವ ಇನ್ನೊಂದು ಶಾಖೆಯ ಕಡೆಗಿನ ರೂಟ್ ಬೇಕು. ಅದಿಲ್ಲದೆ ವಿನಂತಿ ಬರುತ್ತದೆ ಮತ್ತು ಉತ್ತರ ಇಂಟರ್ನೆಟ್ ಮಾರ್ಗದಿಂದ ಹೊರಡುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ತೆರೆದು ನಂತರ ನೇತಾಡುವ ಸಂಪರ್ಕ ಕಾಣುತ್ತದೆ.
ಇದನ್ನು ಸರಿಪಡಿಸಲು ಗೇಟ್ವೇ ಉಪಜಾಲದ ಮೇಲಿನ ನೆಟ್ವರ್ಕ್ ಭದ್ರತಾ ಗುಂಪಿನತ್ತ ಹೋಗಬೇಡಿ. ಆ ಉಪಜಾಲಕ್ಕೆ ತನ್ನದೇ ಅಗತ್ಯಗಳಿವೆ ಮತ್ತು ಅಲ್ಲಿ NSG ಶಾಖೆ-ಬದಿಯ ನೀತಿಯ ಬೆಂಬಲಿತ ಪರ್ಯಾಯವಲ್ಲ. ಫಿಲ್ಟರಿಂಗ್ ಶಾಖೆಗಳ ಫೈರ್ವಾಲ್ಗಳಲ್ಲಿ ಮತ್ತು ಕೆಲಸದ ಭಾರಗಳಲ್ಲಿಯೇ ಇರಬೇಕು, ಅಲ್ಲಿ ನಿಯಮಗಳನ್ನು ಮಾಲೀಕರು ಪರಿಶೀಲಿಸಬಹುದು. ಆ ನಿಯಮಗಳನ್ನು ಉಪಜಾಲದ NSG ಗೆ ಸ್ಥಳಾಂತರಿಸಿದರೆ ಮುಂದಿನ ದೋಷವನ್ನು ಡೀಬಗ್ ಮಾಡುವ ತಂಡದಿಂದಲೂ ಅವು ಮರೆಯಾಗುತ್ತವೆ.
ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಅನುಮತಿಸಿ, ನಂತರ ನಿರಾಕರಿಸಿದ ಪರೀಕ್ಷೆಯಿಂದ ಸಾಬೀತು ಮಾಡಿ
ಕಲಿತ ರೂಟ್ ಅನುಮತಿ ಅಲ್ಲ. ನಿಮಗೆ ನಿಜವಾಗಿ ಬೇಕಾದ ಮೂಲ, ಗಮ್ಯ ಮತ್ತು ಸೇವೆಯನ್ನು ಶಾಖೆಗಳ ಫೈರ್ವಾಲ್ ಮತ್ತು ಎಂಡ್ಪಾಯಿಂಟ್ ನೀತಿಯ ಮೂಲಕ ಅನುಮತಿಸಿ, ಉಳಿದದ್ದನ್ನು ನಿರಾಕರಿಸಲಾಗಿಯೇ ಬಿಡಿ.
ಶಾಖೆ A ಯ ಸಾಮಾನ್ಯ ಕೆಲಸದ ಭಾರದಿಂದ ಶಾಖೆ B ಯ ನಿಜವಾದ ಸೇವೆಗೆ ಪರೀಕ್ಷಿಸಿ, ಉತ್ತರವನ್ನು ಖಚಿತಪಡಿಸಿ, ನಂತರ ನಿಷೇಧಿತವಾಗಿ ಉಳಿಯಬೇಕಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪ್ರಯತ್ನಿಸಿ. VPN ಉಪಕರಣವೇ ಉತ್ಪಾದಿಸುವ ಸಂಚಾರ ಬೇರೆ ಮೂಲ ವಿಳಾಸ ಬಳಸಿ LAN ರೂಟಿಂಗ್ ಹಂತವನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು, ಆದ್ದರಿಂದ ರೌಟರ್ನಿಂದ ಯಶಸ್ವಿ ping ಕಾಣುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.
ನಾಲ್ಕು ಸತ್ಯಗಳನ್ನು ಬರೆದು ಮುಗಿಸಿ: ವಿನಿಮಯವಾದ ಪ್ರಿಫಿಕ್ಸ್ಗಳು, ಬಳಸಿದ ASN ಗಳು, ಪ್ರತಿ ಬದಿಯ LAN ಮರಳು ಮಾರ್ಗ, ಮತ್ತು ಸೇವೆಯನ್ನು ಅನುಮತಿಸುವ ನೀತಿ. ಅವುಗಳಲ್ಲಿ ಒಂದು ಕಾಣೆಯಾದರೆ ಸೆಟಪ್ ಮೊದಲ ಬದಲಾವಣೆಯವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ನಂತರ ಯಾರೂ ಏಕೆ ಎಂದು ವಿವರಿಸಲಾರರು.