ಒಂದು ಅಡಾಪ್ಟರ್‌ನಲ್ಲಿ ಎರಡು DNS ಸರ್ವರ್‌ಗಳು ನಾಮಸ್ಥಳಗಳನ್ನು ವಿಭಜಿಸುವುದಿಲ್ಲ

ಒಂದು ಅಡಾಪ್ಟರ್‌ನಲ್ಲಿ ಎರಡು ರಿಜಾಲ್ವರ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುವುದು ಒಂದು ಡೊಮೇನ್ ಅನ್ನು ಒಂದು ಸರ್ವರ್‌ಗೆ ಮತ್ತು ಇನ್ನೊಂದು ಡೊಮೇನ್ ಅನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಮಾರ್ಗದಂತೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ರಿಜಾಲ್ವರ್ ಪಟ್ಟಿಯಲ್ಲಿ ಯಾವುದೂ ಹಾಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. Windows ಹೆಸರಿನಿಂದ ಪರಿಹರಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವ ಸರ್ವರ್‌ನ್ನು ಕೇಳಬೇಕು ಎಂಬ ನಿರ್ಣಯವು ಕ್ರಮಬದ್ಧ ವಿಳಾಸ ಪಟ್ಟಿಯಿಂದ ಅಲ್ಲ, ನೀತಿ ವಸ್ತುಗಳಿಂದ ಬರುತ್ತದೆ. ಬದಲಾಯಿಸಬೇಕಾದ ಮಾನಸಿಕ ಮಾದರಿ ಸರದಿ: ಡೊಮೇನ್ A ಗಾಗಿ ಮೊದಲ ಸರ್ವರ್ ಮತ್ತು ಡೊಮೇನ್ B ಗಾಗಿ ಎರಡನೇ ಸರ್ವರ್ ಎಂಬುದಿಲ್ಲ. ಪ್ರತಿ ನಾಮಸ್ಥಳಕ್ಕೂ ಸರ್ವರ್‌ಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೆಸರಿಸುವ ನಿಯಮಗಳ ಗುಂಪಿದೆ, ಮತ್ತು ಆ ನಿಯಮಗಳು ಇದ್ದರೆ ಅಡಾಪ್ಟರ್ ಪಟ್ಟಿ ಆಸಕ್ತಿದಾಯಕವಾಗಿರುವುದಿಲ್ಲ.

ಪುರಾಣ: ಎರಡು ವಿಳಾಸಗಳು ಎರಡು ಡೊಮೇನ್‌ಗಳನ್ನು ವಿಭಜಿಸುತ್ತವೆ

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

ಕ್ರಮಬದ್ಧ ಪಟ್ಟಿಗೆ ಡೊಮೇನ್ ಎಂಬ ಪರಿಕಲ್ಪನೆ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಅದು ಉದ್ದೇಶವನ್ನು ವ್ಯಕ್ತಪಡಿಸಲಾರದು. ಪಟ್ಟಿ ವಾಸ್ತವವಾಗಿ ನಿಯಂತ್ರಿಸುವುದು ಯಾವ ಸರ್ವರ್‌ನ್ನು ಮೊದಲು ಕೇಳಲಾಗುತ್ತದೆ ಮತ್ತು ಯಾವುದನ್ನು ಎರಡನೆಯದಾಗಿ ಪ್ರಯತ್ನಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು, ಮತ್ತು ಆ ಎರಡೂ ಉತ್ತರಗಳು ಪ್ರತಿ ಹೆಸರಿಗೂ ಸಮಾನವಾಗಿ ಅನ್ವಯಿಸುತ್ತವೆ.

Windows ಆಯ್ಕೆ ಮಾಡಲು ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಬಳಸುತ್ತದೆ

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

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

ಮೊದಲ ಆಜ್ಞೆ ಯಂತ್ರದಲ್ಲಿ ಏನು ಸಂರಚಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ; ಎರಡನೆಯದು ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಏನನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಬೇರೆಡೆಯಿಂದ ಬಂದ ನಮೂದುಗಳೂ ಸೇರಿದಂತೆ. ಪರಿಣಾಮಕಾರಿ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ನಿರ್ವಹಿತ ನಾಮಸ್ಥಳಗಳಿದ್ದರೆ, ಆ ನೀತಿಯ ಮಾಲೀಕರೇ ಬದಲಾವಣೆಯನ್ನು ಕೇಳಲು ಸರಿಯಾದ ಸ್ಥಳ, ಸ್ಥಳೀಯ ನಿಯಮ ಪಟ್ಟಿಯಲ್ಲ. ಎರಡೂ ಆಜ್ಞೆಗಳು ಸ್ಥಿತಿಯನ್ನು ಮಾತ್ರ ಓದುತ್ತವೆ, ಆದ್ದರಿಂದ ಬದಲಾವಣೆಗೆ ಯಾರಾದರೂ ಒಪ್ಪುವ ಮೊದಲು ಅವುಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಏನನ್ನೂ ವೆಚ್ಚ ಮಾಡುವುದಿಲ್ಲ.

ಪ್ರತಿ ನಾಮಸ್ಥಳಕ್ಕೂ ಒಂದು ನಿಯಮ, ವಸ್ತುವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ

ಪರಿಣಾಮಕಾರಿ ಸ್ಥಿತಿ ಅರ್ಥವಾದ ನಂತರ, ಪ್ರತಿ ನಾಮಸ್ಥಳಕ್ಕೂ ಒಂದು ನಿಯಮ ರಚಿಸಿ ಮತ್ತು ಪ್ರತಿ ಆಜ್ಞೆ ಹಿಂತಿರುಗಿಸುವ ವಸ್ತುವನ್ನು ಸಂರಕ್ಷಿಸಿ. ಪ್ರದರ್ಶನ ಹೆಸರುಗಳು ಜನರಿಗೆ ಲೇಬಲ್‌ಗಳು, ಮತ್ತು ಹಿಂತಿರುಗಿಸಿದ ವಸ್ತುವಿನಲ್ಲಿನ ಅನನ್ಯ ಗುರುತಿಸುವಿಕೆಯೇ ನಂತರ ಅಳಿಸುವಿಕೆಯ ವಿಶ್ವಾಸಾರ್ಹ ಗುರಿ. ಎರಡೂ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ನಾಮಸ್ಥಳಗಳು ಮತ್ತು ರಿಜಾಲ್ವರ್‌ಗಳನ್ನು ದಾಖಲಿಸುವ ಅದೇ ಬದಲಾವಣೆ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಅವನ್ನು ರಚಿಸಿದ ಅಧಿವೇಶನವೇ ಸ್ವಚ್ಛಗೊಳಿಸುವ ಅಧಿವೇಶನವಾಗಿರುವುದಿಲ್ಲ.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

ಆರಂಭದ ಚುಕ್ಕೆ ಪ್ರತ್ಯಯ ಹೊಂದಾಣಿಕೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಯಮ app.svc.internal.example ಮತ್ತು ಅದರ ಕೆಳಗಿನ ಎಲ್ಲವನ್ನೂ ಒಳಗೊಳ್ಳುತ್ತದೆ. ಇಲ್ಲಿನ ಎರಡು ವಿಳಾಸಗಳು ಈ ಪ್ರಯೋಗಾಲಯದ ಸ್ವಂತ ಮಾರ್ಗನಿರ್ದೇಶನ ಯೋಜನೆಗೆ ಸೇರಿವೆ; ನಿಯಮವು ವಲಯವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ, ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ ಅಥವಾ ಅಂತಿಮವಾಗಿ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು Add-DnsClientNrptRule ಉಲ್ಲೇಖ ಯಾವ ನಿಯತಾಂಕ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ದಾಖಲಿಸುತ್ತದೆ.

ಈ ಆಜ್ಞೆಗಳು ಏನು ಮಾಡುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ: ಅವು ಇಡೀ ಯಂತ್ರಕ್ಕೆ ಅನ್ವಯಿಸುತ್ತವೆ, VPN ಅಧಿವೇಶನಕ್ಕೆ ಸೀಮಿತವಲ್ಲ, ಮತ್ತು ಕಿಟಕಿ ಮುಚ್ಚಿದ ನಂತರವೂ ಉಳಿಯುತ್ತವೆ. ಇದನ್ನು ಮರೆಯುವ ಪ್ರಯೋಗಾಲಯವು ಸುರಂಗ ಹೋದ ನಂತರ ನೀತಿಯನ್ನು ಬಿಟ್ಟು ಹೋಗುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಸರ್ವರ್‌ನ್ನು ಆಯ್ಕೆ ಮಾಡಿದೆ ಎಂದು ಸಾಬೀತು ಮಾಡಿ

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

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

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

ನೀವು ರಚಿಸಿದ್ದನ್ನು ನಿಖರವಾಗಿ ತೆಗೆದುಹಾಕಿ

ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ ಎಂಬುದು ಪ್ರಯೋಗಾಲಯವು ಎಚ್ಚರಿಕೆಯ ಕಥೆಯಾಗುವ ಸ್ಥಳ. ಯಂತ್ರದಲ್ಲಿನ ಪ್ರತಿ ನಿಯಮವನ್ನು ಅಳಿಸುವುದು ವೇಗವಾದದ್ದು ಮತ್ತು ಬೇರೆಯವರು ಅವಲಂಬಿಸಿರುವ ನೀತಿಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಯಮಗಳನ್ನು ರಚಿಸಿದಾಗ ಸೆರೆಹಿಡಿದ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಬಳಸಿ, ನಂತರ ಪರಿಣಾಮಕಾರಿ ಸ್ಥಿತಿಯನ್ನು ಮತ್ತೆ ಓದಿ ಯಂತ್ರವು ಆರಂಭಿಸಿದ ಸ್ಥಳಕ್ಕೆ ಮರಳಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಅವನ್ನು ರಚಿಸಿದ ಅಧಿವೇಶನ ಇಲ್ಲದಿದ್ದರೆ, ಗುರುತಿಸುವಿಕೆಗಳು ಇರುವ ಏಕೈಕ ಸ್ಥಳ ಬದಲಾವಣೆ ಟಿಪ್ಪಣಿ. ಆದ್ದರಿಂದ ಅವನ್ನು ಮೊದಲ ಆಜ್ಞೆ ಚಲಿಸುವ ಮೊದಲು ಬರೆಯಬೇಕು, ನಂತರವಲ್ಲ.

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

ಪ್ರಯೋಗಾಲಯವಲ್ಲ, ನಿಯೋಜನೆಗೆ, ಜೀವಿತಾವಧಿಯ ಪ್ರಶ್ನೆ ನಿಯಮದಷ್ಟೇ ಮುಖ್ಯ. VPN ಪ್ರೊಫೈಲ್ ನಾಮಸ್ಥಳ ನಿಯಮಗಳನ್ನು ಹೊತ್ತೊಯ್ಯಬಹುದು ಮತ್ತು ಸಂಪರ್ಕದ ನಂತರವೂ ಅವು ಉಳಿಯುತ್ತವೆಯೇ ಎಂದು ಆಯ್ಕೆ ಮಾಡಬಹುದು; ರಿಜಾಲ್ವರ್ ತಲುಪಲಾಗದಿರುವಾಗ ಉಳಿಯುವ ನಿಯಮವು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸತ್ತ ಸರ್ವರ್‌ನ್ನು ಆದ್ಯತೆ ನೀಡಲು ಬಿಡುತ್ತದೆ, ಮತ್ತು ಸಂಪರ್ಕಕ್ಕೆ ಸೀಮಿತವಾದ ನಿಯಮವು ಸುರಂಗ ಹೋದಾಗ ಮಾಯವಾಗುತ್ತದೆ. ಸೇವೆಗೆ ಈ ವರ್ತನೆಗಳಲ್ಲಿ ಯಾವುದು ಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ, ನಿಯಮ ಯಾರದ್ದು ಎಂದು ಗುರುತಿಸಿ, ಮತ್ತು ಅಧಿಕಾರದ ವಿಭಜನೆಯನ್ನು ಯಾರೋ ಪ್ರಯೋಗಾಲಯದ ನೆನಪಿನಲ್ಲಿ ಅಲ್ಲ, ಪ್ರೊಫೈಲ್‌ನ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ.