SaaS ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸರಿಯಾದ ಗ್ರಾಹಕ VPN ಗೆ ಹೇಗೆ ರೂಟ್ ಮಾಡುವುದು
ಅತಿವ್ಯಾಪಿಸುವ ಗ್ರಾಹಕ ಸಬ್ನೆಟ್ಗಳು ಹಂಚಿಕೆಯ ರೂಟಿಂಗ್ ಅನ್ನು ಮುರಿಯುತ್ತವೆ. ಐಸೊಲೇಶನ್ ಮಾದರಿಯನ್ನು ಆಯ್ಕೆಮಾಡಿ, ಪ್ರತಿ ಕೆಲಸವನ್ನು ಪರಿಶೀಲಿಸಿದ ಟೆನೆಂಟ್ಗೆ ಜೋಡಿಸಿ ಮತ್ತು ಪ್ರಾರಂಭಕ್ಕೆ ಮೊದಲು ಕ್ರಾಸ್-ಟೆನೆಂಟ್ ಮಾರ್ಗಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ.
ಒಂದು SaaS ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಹನ್ನೆರಡು ಗ್ರಾಹಕ ನೆಟ್ವರ್ಕ್ಗಳಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಗ್ರಾಹಕರಲ್ಲಿ ಇಬ್ಬರು ತಮ್ಮ ಪ್ರಾಥಮಿಕ ಡೇಟಾಬೇಸ್ಗೆ 10.20.0.10 ಬಳಸುತ್ತಾರೆ. ಕೆಲಸದಲ್ಲಿ ಆ ವಿಳಾಸವನ್ನು ಸ್ವೀಕರಿಸುವ ವರ್ಕರ್ಗೆ ಕೆಲಸವು ಯಾವ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ ಎಂದು ತಿಳಿಯಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ, ಮತ್ತು ಹಂಚಿಕೆಯ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಪ್ರಿಫಿಕ್ಸ್ ತೋರಿಸುವ ಸುರಂಗಕ್ಕೆ ಅದನ್ನು ಸಂತೋಷದಿಂದ ಕಳುಹಿಸುತ್ತದೆ. ಪರಿಹಾರ ಹೆಚ್ಚು ಸುರಂಗಗಳಲ್ಲ; ಪರಿಹಾರವೆಂದರೆ ಟೆನೆಂಟ್ ಗುರುತು ಮಾರ್ಗಕ್ಕೆ ಎಲ್ಲಿ ಪ್ರವೇಶಿಸುತ್ತದೆ ಮತ್ತು ವಿಳಾಸ ಯೋಜನೆಗೆ ಯಾವ ಐಸೊಲೇಶನ್ ಮಾದರಿ ಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು. ಮೂರು ಷರತ್ತುಗಳು ಆಯ್ಕೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ: ಗ್ರಾಹಕ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಅತಿವ್ಯಾಪಿಸುತ್ತವೆಯೇ, ದೋಷ ಎಷ್ಟು ದೂರ ಹರಡಬಹುದು, ಮತ್ತು ಕನೆಕ್ಟರ್ ಅನ್ನು ಯಾರು ನಿರ್ವಹಿಸುತ್ತಾರೆ.
ಎರಡು ಗ್ರಾಹಕ ಡೇಟಾಬೇಸ್ಗಳು, ಒಂದು ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸ
IP ವಿಳಾಸವು ಸ್ಥಳವೇ ಹೊರತು ಗುರುತಲ್ಲ. ವಿನಂತಿಯು ಸರ್ವರ್ ಪರಿಶೀಲಿಸಿದ ಟೆನೆಂಟ್ ಅನ್ನು ಹೊತ್ತಿರಬೇಕು, ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಪರಿಹರಿಸುವ ಮೊದಲು ಆ ಟೆನೆಂಟ್ ನೆಟ್ವರ್ಕ್ ಸಂದರ್ಭವನ್ನು ಆಯ್ಕೆಮಾಡಬೇಕು.
ಹಾಗಾಗದಿದ್ದಾಗ, ವೈಫಲ್ಯ ಶಾಂತವಾಗಿರುತ್ತದೆ. ಸಂಪರ್ಕ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಪ್ರಶ್ನೆ ಚಲಿಸುತ್ತದೆ, ಮತ್ತು ಉತ್ತರ ತಪ್ಪು ಗ್ರಾಹಕರ ಡೇಟಾಬೇಸ್ನಿಂದ ಬರುತ್ತದೆ ಏಕೆಂದರೆ ರೂಟಿಂಗ್ ಟೇಬಲ್ನಲ್ಲಿ 10.20.0.10 ಗೆ ಒಂದೇ ನಮೂದು ಇತ್ತು. DNS ಅದನ್ನು ಇನ್ನಷ್ಟು ಕೆಡಿಸುತ್ತದೆ: ಟೆನೆಂಟ್ A ಸಂದರ್ಭದಲ್ಲಿ ಪರಿಹರಿಸಲಾದ ಕ್ಯಾಶ್ ಮಾಡಿದ ಹೆಸರನ್ನು ಟೆನೆಂಟ್ B ಗಾಗಿ ಚಲಿಸುವ ಕೆಲಸ ಮತ್ತೆ ಬಳಸಬಹುದು. ಪ್ಯಾಕೆಟ್ನಲ್ಲಿ ಯಾವುದೂ ಎರಡನ್ನೂ ಪ್ರತ್ಯೇಕಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಮರುಪ್ರಯತ್ನ ತರ್ಕ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.
ಮೊದಲು ಐಸೊಲೇಶನ್ ಮಾದರಿಯನ್ನು ನಿರ್ಧರಿಸಿ
ಉತ್ಪನ್ನಗಳನ್ನು ಹೋಲಿಸುವ ಮೊದಲು ಮೂರು ಷರತ್ತುಗಳನ್ನು ಬರೆಯಿರಿ. ಅತಿವ್ಯಾಪನೆ ಒಂದು ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಹಂಚಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ; ಪ್ರಭಾವದ ತ್ರಿಜ್ಯ ರೂಟಿಂಗ್ ದೋಷವು ಬೆಂಬಲ ಟಿಕೆಟ್ ಅಥವಾ ಉಲ್ಲಂಘನೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ; ಕಾರ್ಯಾಚರಣಾ ಮಾಲೀಕತ್ವವು ಪ್ರತಿ ಟೆನೆಂಟ್ಗೆ ಕನೆಕ್ಟರ್ ಕಾರ್ಯಪಡೆಯನ್ನು ನಡೆಸಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
ಪ್ರಿಫಿಕ್ಸ್ಗಳು ವಿಭಿನ್ನವಾಗಿದ್ದರೆ ಮತ್ತು ನೀತಿಯು ನಿಯಂತ್ರಿತ ಹಬ್ ಅನ್ನು ಅನುಮತಿಸಿದರೆ, ಪ್ರತಿ ಟೆನೆಂಟ್ ರೂಟಿಂಗ್ ಟೇಬಲ್ಗಳೊಂದಿಗೆ ಒಂದು Transit Gateway ಕಾರ್ಯಸಾಧ್ಯ. ಅಟ್ಯಾಚ್ಮೆಂಟ್ ಸಂಘವು ಆ ಅಟ್ಯಾಚ್ಮೆಂಟ್ನಿಂದ ಪ್ರವೇಶಿಸುವ ಟ್ರಾಫಿಕ್ಗೆ ಬಳಸುವ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ, ಮತ್ತು ಪ್ರಸರಣವು ಟೇಬಲ್ನಲ್ಲಿ ಯಾವ ಮಾರ್ಗಗಳು ಕಾಣುತ್ತವೆ ಎಂದು ಆಯ್ಕೆಮಾಡುತ್ತದೆ. ತನ್ನ ಟೇಬಲ್ಗೆ ಮಾತ್ರ ಸಂಬಂಧಿಸಿದ ಮತ್ತು ತನ್ನ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಮಾತ್ರ ಪ್ರಸಾರ ಮಾಡುವ ಟೆನೆಂಟ್ ಅಟ್ಯಾಚ್ಮೆಂಟ್ ಹಬ್ ತಲುಪುತ್ತದೆ ಮತ್ತು ಬೇರೆ ಎಲ್ಲೂ ತಲುಪುವುದಿಲ್ಲ. ಅದು ರೂಟಿಂಗ್ ನಿರ್ಧಾರ, ಮತ್ತು ಯಾರೂ ಹಂಚಿಕೆಯ ಟೇಬಲ್ಗೆ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಸೇರಿಸದವರೆಗೆ ಅದು ಸರಿಯಾಗಿರುತ್ತದೆ.
ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಅತಿವ್ಯಾಪಿಸಿದರೆ, ರೂಟಿಂಗ್ ಮಾತ್ರ ಅವನ್ನು ಬೇರ್ಪಡಿಸಲಾರದು. ನಿಮಗೆ ಪ್ರತಿ ಟೆನೆಂಟ್ಗೆ ಪ್ರತ್ಯೇಕ ನೆಟ್ವರ್ಕ್ ಸಂದರ್ಭ ಅಥವಾ ಪ್ರತಿ ಗ್ರಾಹಕರ ಸ್ಥಳಕ್ಕೆ ಸ್ಪಷ್ಟ ಅರ್ಥ ನೀಡುವ ಅನುವಾದ ಯೋಜನೆ ಬೇಕು.
Transit Gateway ಐಸೊಲೇಶನ್ ನಿಜವಾಗಿ ಏನನ್ನು ಅರ್ಥೈಸುತ್ತದೆ
ಸಂಘ ಮತ್ತು ಪ್ರಸರಣವು ಮುಖ್ಯವಾದ ಎರಡು ನಿಯಂತ್ರಣಗಳು, ಮತ್ತು ಅವನ್ನು ಗೊಂದಲಗೊಳಿಸುವುದು ಸುಲಭ. ಸಂಘವು ಈ ಅಟ್ಯಾಚ್ಮೆಂಟ್ನ ಪ್ಯಾಕೆಟ್ ಯಾವ ಟೇಬಲ್ನಲ್ಲಿ ಹುಡುಕಲ್ಪಡುತ್ತದೆ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ; ಪ್ರಸರಣವು ಯಾವ ಟೇಬಲ್ಗಳು ಈ ಅಟ್ಯಾಚ್ಮೆಂಟ್ನ ಮಾರ್ಗಗಳನ್ನು ಕಲಿಯುತ್ತವೆ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ. ಐಸೊಲೇಶನ್ ಎರಡನ್ನೂ ಟೆನೆಂಟ್-ನಿರ್ದಿಷ್ಟವಾಗಿಸುವುದರಿಂದ ಬರುತ್ತದೆ, ಹೆಚ್ಚು ಅಟ್ಯಾಚ್ಮೆಂಟ್ಗಳನ್ನು ರಚಿಸುವುದರಿಂದ ಅಲ್ಲ.
ಡೀಫಾಲ್ಟ್ ಎಲ್ಲರಿಂದ-ಎಲ್ಲರಿಗೂ ಸಂರಚನೆ ಅನುಕೂಲಕರ ಮತ್ತು ಐಸೊಲೇಶನ್ ಅಲ್ಲ. ಪ್ರತ್ಯೇಕ ರೂಟಿಂಗ್ ಟೇಬಲ್ಗಳು ಸಂಪರ್ಕವನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತವೆ, ಆದರೆ ಒಂದೇ ರೂಟಿಂಗ್ ಸಂದರ್ಭದಲ್ಲಿ ಒಂದು ಬದಲಾಗದ ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸಕ್ಕೆ ಎರಡು ಅರ್ಥಗಳನ್ನು ನೀಡುವುದಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಟೆನೆಂಟ್ ತಿಳಿಯುವ ಮೊದಲು 10.20.0.10 ಪರಿಹರಿಸಿದರೆ, ರೂಟಿಂಗ್ ಪದರವು ಬೇಕಾದ ಮಾಹಿತಿಯನ್ನು ಈಗಾಗಲೇ ಕಳೆದುಕೊಂಡಿದೆ.
AWS 23 ಅಕ್ಟೋಬರ್ 2026 ರಂದು Transit Gateway ಮತ್ತು Cloud WAN ಗಾಗಿ ಅಟ್ಯಾಚ್ಮೆಂಟ್-ಮಟ್ಟದ 1:1 NAT ಸೇರಿಸಿತು, ಇದು ಬೆಂಬಲಿತ ಅಟ್ಯಾಚ್ಮೆಂಟ್ಗಳಿಗೆ ಅತಿವ್ಯಾಪನೆಯ ಉತ್ತರವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. Transit Gateway NAT ದಾಖಲೆ ಹೋಸ್ಟ್ ಬಿಟ್ಗಳನ್ನು ಉಳಿಸಿಕೊಂಡು ಸ್ಥಿರ, ಸ್ಥಿತಿರಹಿತ, ಸಮಾನ-ಪ್ರಿಫಿಕ್ಸ್ IPv4 ಮ್ಯಾಪಿಂಗ್ಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅದರ ಸುತ್ತ ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ಬೆಂಬಲಿತ ಅಟ್ಯಾಚ್ಮೆಂಟ್ ಪ್ರಕಾರಗಳು ಮತ್ತು ಪ್ರಾದೇಶಿಕ ನಿರ್ಬಂಧಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ಕೆಲಸವನ್ನು ಪರಿಶೀಲಿಸಿದ ಟೆನೆಂಟ್ಗೆ ಜೋಡಿಸಿ
ಪ್ರತಿ ಕೆಲಸವು ಸರ್ವರ್-ಪರಿಶೀಲಿತ ಟೆನೆಂಟ್ ಗುರುತನ್ನು ಹೊತ್ತಿರಬೇಕು, ಮತ್ತು ಆ ಗುರುತು ನಿರ್ವಾಹಕರ ಮಾಲೀಕತ್ವದ ಸಂಪರ್ಕ ದಾಖಲೆಯನ್ನು ಆಯ್ಕೆಮಾಡಬೇಕು. ದಾಖಲೆಯು ಅನುಮೋದಿತ ನೆಟ್ವರ್ಕ್ ಸಂದರ್ಭ, ಸೇವಾ ವಿಳಾಸ, ರುಜುವಾತುಗಳ ಉಲ್ಲೇಖ ಮತ್ತು ಅಲ್ಲಿ ಅನುಮತಿಸಿದ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಅವಿಶ್ವಾಸನೀಯ ವಿನಂತಿಯು ಎಂದಿಗೂ ತನ್ನದೇ VPN ಗುರುತಿಸುವಿಕೆ, ಗೇಟ್ವೇ ಅಥವಾ ಖಾಸಗಿ ಗುರಿಯನ್ನು ಒದಗಿಸಬಾರದು, ಏಕೆಂದರೆ ಮಾನ್ಯ ಲಾಗಿನ್ ಪ್ರತಿ ಸಂಪರ್ಕಿತ ಗ್ರಾಹಕರ ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಪರಿಶೋಧಿಸುವ ಅನುಮತಿ ಅಲ್ಲ.
ಪ್ರತ್ಯೇಕಿಸಿದ ಕನೆಕ್ಟರ್ಗಳ ವಿನ್ಯಾಸದಲ್ಲಿ, ಟೆನೆಂಟ್ A ಯ ಕೆಲಸವು A ಗೆ ನಿರ್ದಿಷ್ಟವಾದ ಕನೆಕ್ಟರ್ಗೆ ಹೋಗುತ್ತದೆ, ಅದು A ಯ VPC ಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು A ಯ ಅನುಮೋದಿತ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಾತ್ರ ತಲುಪಬಲ್ಲದು. ಒಂದೇ ಹೋಸ್ಟ್ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಕಂಟೇನರ್ಗಳು ಆ ಬೇರ್ಪಡಿಕೆಯನ್ನು ತಾವಾಗಿಯೇ ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ; ನೆಟ್ವರ್ಕ್ ನಾಮಸ್ಥಳಗಳು, ಮಾರ್ಗಗಳು ಮತ್ತು ನಿರ್ಗಮನ ನೀತಿಯು ಅದನ್ನು ಜಾರಿಗೊಳಿಸಬೇಕು. ಕನೆಕ್ಟರ್ಗೆ ಟೆನೆಂಟ್-ವ್ಯಾಪ್ತಿಯ ರುಜುವಾತುಗಳು ಮತ್ತು ಸರತಿಸಾಲುಗಳೂ ಬೇಕು, ಏಕೆಂದರೆ ಖಾಸಗಿ ಮಾರ್ಗವು ಹಂಚಿಕೆಯ ರಹಸ್ಯ ಅಥವಾ ಹಂಚಿಕೆಯ ಕೆಲಸದ ಅಂಶವನ್ನು ಸೀಮಿತಗೊಳಿಸುವುದಿಲ್ಲ. ಹಂಚಿಕೆಯ ಅಪ್ಲಿಕೇಶನ್ ವರ್ಕರ್ಗಳು, ನೆಟ್ವರ್ಕ್ ಸಂದರ್ಭ ಮತ್ತು ರುಜುವಾತುಗಳನ್ನು ಹೋಸ್ಟ್ಗೆ ಬದಲಾಗಿ ಟೆನೆಂಟ್ಗೆ ಆಯ್ಕೆಮಾಡುವವರೆಗೆ ಸರಿ.
ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳು ಟೆನೆಂಟ್ ಮತ್ತು ಹಂತವನ್ನು ಹೆಸರಿಸಬೇಕು: ಸುರಂಗ ಸ್ಥಾಪಿತ, ಮಾರ್ಗ ಇದೆ ಮತ್ತು ನಿಜವಾದ ಸೇವಾ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಯಿತು — ಇವು ಮೂರು ವಿಭಿನ್ನ ಸಂಕೇತಗಳು. ಚಾಲನೆಯಲ್ಲಿರುವ ಸುರಂಗಗಳ ಒಟ್ಟು ಎಣಿಕೆ ಕನೆಕ್ಟರ್ ಹಾಳಾದ ಒಂದೇ ಗ್ರಾಹಕರನ್ನು ಮರೆಮಾಡುತ್ತದೆ.
ವಿಫಲವಾಗಬೇಕಾದ ಮಾರ್ಗಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
ಪ್ರಾರಂಭಕ್ಕೆ ಮೊದಲು ಮೂರು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿ. ಅನುಮತಿಸಿದ A ಕಾರ್ಯಾಚರಣೆ ಯಶಸ್ವಿಯಾಗಬೇಕು, ಅನುಮತಿಸಿದ B ಕಾರ್ಯಾಚರಣೆ ಯಶಸ್ವಿಯಾಗಬೇಕು, ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ B ಯ ಕನೆಕ್ಟರ್ ಅಥವಾ ಅದರ ಅನುವಾದಿತ ಅಲಿಯಾಸ್ ಕಡೆಗೆ ಗುರಿಪಡಿಸಿದ A ಕೆಲಸವು ಮುಚ್ಚಿದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗಬೇಕು. ನಂತರ ಒಂದು ಸುರಂಗವನ್ನು ಮುರಿಯಿರಿ ಮತ್ತು ಕೆಲಸವು ಆ ಟೆನೆಂಟ್ಗೆ ಮಾತ್ರ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಇನ್ನೊಬ್ಬ ಗ್ರಾಹಕರ ಅದೇ ಸಂಖ್ಯೆಯ ಸಬ್ನೆಟ್ಗೆ ಹಿಂತಿರುಗದೆ. ಮರುಸ್ಥಾಪನೆಯನ್ನೂ ಪರೀಕ್ಷಿಸಬೇಕು, ಏಕೆಂದರೆ ಹಳೆಯ ಮಾರ್ಗ ಅಥವಾ ಕ್ಯಾಶ್ ಮಾಡಿದ ರುಜುವಾತುಗಳು ಅಡಚಣೆಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯಬಹುದು.
ವಾಸ್ತುಶಿಲ್ಪವು ಪ್ರತ್ಯೇಕಿಸಿದ ಕನೆಕ್ಟರ್ಗಳೊಂದಿಗೆ ಹಂಚಿಕೆಯ ವರ್ಕರ್ಗಳು ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕವಾದ ಟೆನೆಂಟ್ ಸಂಪನ್ಮೂಲಗಳಾಗಿರಬಹುದು. ಅಸ್ಥಿರವಲ್ಲದದ್ದು ಒಂದೇ: ಪರಿಶೀಲಿತ ಟೆನೆಂಟ್ ಸಂದರ್ಭವು ಮಾರ್ಗ ಮತ್ತು ರುಜುವಾತುಗಳನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಮಾರ್ಗ ಬದಲಾವಣೆ ಎಂದಿಗೂ ಟೆನೆಂಟ್ಗಳ ನಡುವೆ ಅಪ್ಲಿಕೇಶನ್ ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ.