Azure VPN ಪ್ರಿಫಿಕ್ಸ್ ಸೇರಿಸಿದರೆ ಸಂಪರ್ಕ ಏಕೆ ಕಡಿತಗೊಳ್ಳುತ್ತದೆ

ತಪ್ಪು Azure ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ಸೇರಿಸಿದ ಪ್ರಿಫಿಕ್ಸ್ Connected ಎಂದು ವರದಿ ಮಾಡುತ್ತಾ ಏನನ್ನೂ ಮುಂದೆ ಕಳುಹಿಸದ ಸಂಪರ್ಕವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಮತ್ತು ಇದು ಈ ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ಅತ್ಯಂತ ದುಬಾರಿ ದೋಷ ಪ್ರಕಾರ. ಮೂರು ಸಂಪನ್ಮೂಲಗಳು ಒಳಗೊಂಡಿವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ದೂರದ ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಹೊಂದಿದೆ: ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್ ಗೇಟ್‌ವೇ, ದೂರದ ಬದಿಯನ್ನು ವಿವರಿಸುವ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಗೇಟ್‌ವೇ, ಮತ್ತು ಅವುಗಳನ್ನು ಸೇರಿಸುವ ಸಂಪರ್ಕ. ಪ್ರಿಫಿಕ್ಸ್ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಗೇಟ್‌ವೇಗೆ ಸೇರಿದ್ದು, ಬದಲಾವಣೆ ಜಾರಿಗೆ ಬರಲು ಸಂಪರ್ಕವನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸಬೇಕು, ಮತ್ತು ಗೇಟ್‌ವೇ ಸ್ವತಃ ಸಾಮಾನ್ಯವಾಗಿ ಮುಟ್ಟದೆ ಉಳಿಯುತ್ತದೆ. ಕ್ರಮವು ಮಾತುಕತೆಗೆ ಒಳಪಡುವುದಿಲ್ಲ, ಮತ್ತು ಪೋರ್ಟಲ್ ಅದರ ಒಂದು ಭಾಗವನ್ನು ಮಾತ್ರ ತೋರಿಸುತ್ತದೆ.

ಮೂರು ಆಬ್ಜೆಕ್ಟ್‌ಗಳು, ಅವುಗಳಲ್ಲಿ ಒಂದು ಪ್ರಿಫಿಕ್ಸ್ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ

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

ನೆನಪಿನಲ್ಲಿಡಬೇಕಾದ ಮೂರನೇ ಕಾಯ್ದಿರಿಸುವಿಕೆಯೂ ಇದೆ. GatewaySubnet ನಿರ್ವಹಿತ ಗೇಟ್‌ವೇ ಇನ್‌ಸ್ಟಾನ್ಸ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತದೆ, ನಿಖರವಾಗಿ ಆ ಹೆಸರನ್ನು ಹೊಂದಿರಬೇಕು, ಮತ್ತು Basic ಅಲ್ಲದ SKUಗಳಿಗೆ ಕನಿಷ್ಠ /27 ಇರಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ.

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

ಸಂಪರ್ಕವನ್ನೇ ಏಕೆ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ

ಸಂಪರ್ಕ ಆಬ್ಜೆಕ್ಟ್ ತನ್ನ ಇಡೀ ಜೀವಿತಾವಧಿಗೆ ಮಾತುಕತೆಯಾದ ಸಂರಚನೆಯನ್ನು ಸ್ಥಿರಗೊಳಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ದಾಖಲಾದ ಕಾರ್ಯವಿಧಾನ ಮೊದಲು ಸಂಪರ್ಕವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಗೇಟ್‌ವೇ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ, ನಂತರ ಅದೇ ಹಂಚಿಕೊಂಡ ಕೀಲಿಯೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ಮತ್ತೆ ಸೃಷ್ಟಿಸುತ್ತದೆ. ಪ್ರಿಫಿಕ್ಸ್ ಮಾತ್ರದ ಬದಲಾವಣೆಗೆ ಗೇಟ್‌ವೇ ಇನ್‌ಸ್ಟಾನ್ಸ್‌ಗಳನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸುವುದಿಲ್ಲ, ಇದು ಅಡಚಣೆಯನ್ನು ಗೇಟ್‌ವೇ ಮರುನಿಯೋಜನೆಗಿಂತ ಸಂಪರ್ಕ ಕಿತ್ತುಹಾಕುವಿಕೆಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ.

ಆ ಅಳಿಸುವಿಕೆಯೇ ಅಡಚಣೆ, ಆದ್ದರಿಂದ ತ್ವರಿತ ಸಂಪಾದನೆಗಿಂತ ಆರಂಭ ಮತ್ತು ನಿರೀಕ್ಷಿತ ಅಂತ್ಯವಿರುವ ಯೋಜಿತ ಬದಲಾವಣೆಯಾಗಿ ಪರಿಗಣಿಸಿ. PowerShellನಲ್ಲಿ ಕ್ರಮ ಚಿಕ್ಕದಾಗಿದೆ: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, ನಂತರ Set-AzLocalNetworkGateway ಹೊಸ -AddressPrefix ಸರಣಿಯೊಂದಿಗೆ, ನಂತರ New-AzVirtualNetworkGatewayConnection ಅದೇ -SharedKey ಮತ್ತು ಅದೇ ಗೇಟ್‌ವೇಗಳೊಂದಿಗೆ. ಕೀಲಿಯ ಮರುಬಳಕೆ ಮುಖ್ಯ, ಏಕೆಂದರೆ ದೂರದ ಬದಿಯನ್ನು ಮರುಸಂರಚಿಸುತ್ತಿಲ್ಲ ಮತ್ತು ಹೊಸ ಕೀಲಿ ಎಂದರೆ ದೂರದ ಸಾಧನದ ಮಾಲೀಕರೊಂದಿಗೆ ಸಮನ್ವಯ. ಆ ಸಾಧನವನ್ನು ಬೇರೆ ತಂಡ ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಏನನ್ನಾದರೂ ತೆಗೆದುಹಾಕುವ ಮೊದಲು ಅವರೊಂದಿಗೆ ಕಾಲಾವಧಿಯನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಿ.

ಗೇಟ್‌ವೇಯನ್ನೇ ಯಾವಾಗ ಮತ್ತೆ ನಿರ್ಮಿಸಬೇಕು

ಈ ಸಮಸ್ಯೆಯ ಸುತ್ತ ಸುತ್ತುವ ಎರಡನೇ ಉತ್ತರ ಗೇಟ್‌ವೇಯನ್ನು ಮತ್ತೆ ಸೃಷ್ಟಿಸಬೇಕು ಮತ್ತು ಕೀಲಿಯನ್ನು ಮತ್ತೆ ವಿನಿಮಯ ಮಾಡಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ. ಅದು ಬೇರೆ ರೀತಿಯ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಸರಿಯಾಗಿದೆ: ಗೇಟ್‌ವೇ ಪ್ರಕಾರ ಅಥವಾ SKU ಬದಲಾಯಿಸುವುದು, ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ಮತ್ತು ಸೈಟ್-ಟು-ಸೈಟ್ ನಡುವೆ ಹೋಗುವುದು, ಅಥವಾ ತನ್ನದೇ ಸಂರಚನೆ ತಪ್ಪಾಗಿರುವ ಗೇಟ್‌ವೇ ಅನ್ನು ಸರಿಪಡಿಸುವುದು. ಅಂತಹ ಬದಲಾವಣೆಗಳು ನಿಜವಾಗಿಯೂ ಗೇಟ್‌ವೇ ಸಂಪನ್ಮೂಲವನ್ನು ಬದಲಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಮರುನಿರ್ಮಾಣ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯ.

ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್‌ಗಾಗಿ ರಚಿಸಿದ ಗೇಟ್‌ವೇಗೆ ಸರಳವಾಗಿ ಸೈಟ್-ಟು-ಸೈಟ್ ಸಂಪರ್ಕ ನೀಡಲಾಗದು. ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ಸಂರಚನೆಯನ್ನು ತೆಗೆದುಹಾಕಿ ಗೇಟ್‌ವೇ ಅನ್ನು ಮತ್ತೆ ಸೃಷ್ಟಿಸಬೇಕು, ಇದು ಹೊಸ ಹಂಚಿಕೊಂಡ ಕೀಲಿ ಮತ್ತು ಹೊಸ ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೇಜನ್ನೂ ನೀಡುತ್ತದೆ.

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

ಸ್ಥಿತಿಯನ್ನು ಓದಿ, ಪೋರ್ಟಲ್ ಬ್ಯಾಡ್ಜ್ ಅಲ್ಲ

ಪೋರ್ಟಲ್‌ನ ಬ್ಯಾಡ್ಜ್‌ಗಿಂತ ಸಂಪನ್ಮೂಲದಿಂದ ಸ್ಥಿತಿಯನ್ನು ಓದಿ. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 ಹಿಂತಿರುಗಿಸುತ್ತದೆ ConnectionStatus ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ಬೈಟ್ ಕೌಂಟರ್‌ಗಳೊಂದಿಗೆ, ಮತ್ತು ಸಂಪರ್ಕಗೊಂಡಿದ್ದರೂ ಏನನ್ನೂ ಸಾಗಿಸದ ಟನೆಲ್ ಅನ್ನು ಎಂದಿಗೂ ಸ್ಥಾಪನೆಯಾಗದ ಟನೆಲ್‌ನಿಂದ ಬೇರ್ಪಡಿಸುವುದು ಈ ಕೌಂಟರ್‌ಗಳೇ.

ವರ್ಗಾವಣೆಯ ಮಧ್ಯದಲ್ಲಿ ಹೆಚ್ಚಳ ನಿಲ್ಲಿಸುವ ಕೌಂಟರ್‌ಗಳು ದೃಢೀಕರಣಕ್ಕಲ್ಲ, ಮಾರ್ಗಕ್ಕೆ ಸೂಚಿಸುತ್ತವೆ. ಸ್ವಲ್ಪವೂ ಚಲಿಸದ ಕೌಂಟರ್‌ಗಳು ಪ್ರಿಫಿಕ್ಸ್ ಗುಂಪಿಗೆ ಅಥವಾ ಹಂಚಿಕೊಂಡ ಕೀಲಿಗೆ ಸೂಚಿಸುತ್ತವೆ.

ಟೈಮರ್‌ಗಳು VPNಗೆ ತಪ್ಪಾಗಿ ಆರೋಪಿಸಲಾದ ಸಂಪರ್ಕ ಕಡಿತಗಳ ಒಂದು ವರ್ಗವನ್ನು ವಿವರಿಸುತ್ತವೆ. Azureನ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ತನ್ನ ಸಂರಚಿತ ಕಾಲಮಿತಿಯ ನಂತರ ನಿಷ್ಕ್ರಿಯ ಹರಿವುಗಳನ್ನು ಮುಚ್ಚುತ್ತದೆ, ಈ ಟಿಪ್ಪಣಿಗಳನ್ನು ಬರೆದಾಗ ಡೀಫಾಲ್ಟ್ ನಾಲ್ಕು ನಿಮಿಷಗಳು ಮತ್ತು ಮೇಲಕ್ಕೆ ಸಂರಚಿಸಬಹುದು, ಆದ್ದರಿಂದ keepalive ಇಲ್ಲದ VMನಲ್ಲಿ OpenVPN ಸರ್ವರ್ ಪ್ರತಿ ಕೆಲವು ನಿಮಿಷಗಳಿಗೊಮ್ಮೆ ಬೀಳಬಹುದು, ಉಳಿದೆಲ್ಲವೂ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತಿರುವಾಗ. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಚಕ್ರೀಯವಾಗಿ ಮರುಪ್ರಾರಂಭಿಸುವ ಗೇಟ್‌ವೇ ಸಹ VNet ಸಂಪರ್ಕವನ್ನು Web Appಗೆ ಅಡ್ಡಿಪಡಿಸಬಹುದು, ಮತ್ತು ಆ ವೈಫಲ್ಯ ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯಲ್ಲಿ ಅಲ್ಲ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಕಡೆಗಿದೆ. ಸೂಚನೆ ಎಂದರೆ ಸಂಪರ್ಕ ಕಡಿತವು ನಿಶ್ಚಿತ ಮಧ್ಯಂತರವನ್ನು ಅನುಸರಿಸುತ್ತದೆಯೇ ಅಥವಾ ನೀವು ಮಾಡಿದ ಬದಲಾವಣೆಯನ್ನು.

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

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