ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ VPN ಮೂಲಕ ಖಾಸಗಿ Container Apps ಅಪ್ ತಲುಪಿ
ಆಂತರಿಕ Container Apps ಪರಿಸರಕ್ಕೆ ಖಾಸಗಿ ಪ್ರವೇಶ, ಹೊಂದಿಕೆಯಾಗುವ ಹೋಸ್ಟ್ ಹೆಸರು ಮತ್ತು VPN ತಲುಪಬಲ್ಲ ರಿಜಾಲ್ವರ್ ಬೇಕು. ಪ್ರತಿ ಹಂತವನ್ನು ರನ್ ಮಾಡಿ, ನಂತರ ನಿರಾಕರಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.
ಈ ರನ್ಬುಕ್ ವರ್ಕ್ಲೋಡ್ ಪ್ರೊಫೈಲ್ಗಳಿರುವ Container Apps ಪರಿಸರವನ್ನು ಮತ್ತು ಆಂತರಿಕ ವರ್ಚುವಲ್-ನೆಟ್ವರ್ಕ್ ಪ್ರವೇಶವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ; ಅದನ್ನು ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ ಅನುಮೋದಿತ ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ VPN ಮೂಲಕ ತಲುಪಲಾಗುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ನ ನೇರ FQDN ಬಳಸಿ ಮತ್ತು ಪರಿಸರ ಮಟ್ಟದಲ್ಲಿ HTTP ಮಾರ್ಗಗಳಿಲ್ಲದೆ. ಪರಿಸರದ ಪ್ರವೇಶವು ಕ್ಲೈಂಟ್ನಿಂದ ತಲುಪಬಹುದಾದದ್ದು, ಅಪ್ಲಿಕೇಶನ್ನ ಇನ್ಗ್ರೆಸ್ ವ್ಯಾಪ್ತಿ ಕರೆ ಮಾಡುವವರನ್ನು ಒಪ್ಪುತ್ತದೆ, ಮತ್ತು ಹೋಸ್ಟ್ ಹೆಸರು ಖಾಸಗಿ ಪ್ರವೇಶಕ್ಕೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ. ಕೆಳಗಿನ ಪ್ರತಿ ಹಂತವು ಪರಿಶೀಲಿಸಬಹುದಾದ ಫಲಿತಾಂಶ ಮತ್ತು ನೀವು ಬದಲಾಯಿಸದ ಯಾವುದನ್ನೂ ಮುಟ್ಟದ ರೋಲ್ಬ್ಯಾಕ್ ಬಿಡುತ್ತದೆ. ನೀಡಿದ ಕ್ರಮದಲ್ಲಿ ಅವುಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ, ಏಕೆಂದರೆ ಹಂತ 1 ರಲ್ಲಿ ತಪ್ಪಾಗಿ ತೆಗೆದುಕೊಂಡ ವ್ಯಾಪ್ತಿ ನಿರ್ಣಯವನ್ನು ಮುಂದಿನ ಯಾವುದೇ ಹಂತ ಸರಿದೂಗಿಸಲಾರದು.
DNS ಮುಟ್ಟುವ ಮೊದಲು ಆಂತರಿಕ ಎಂಬ ಪದವನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಿ. ಈ ಉತ್ಪನ್ನದಲ್ಲಿ ಅದನ್ನು ಎರಡು ವಿಭಿನ್ನ ವ್ಯಾಪ್ತಿಗಳಿಗೆ ಬಳಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಅದಲುಬದಲು ಮಾಡುವುದೇ ಕೆಲಸ ಮಾಡುವ ಹೆಸರು ಇನ್ನೂ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಹಿಂತಿರುಗಿಸದಿರಲು ಸಾಮಾನ್ಯ ಕಾರಣ.
ಹಂತ 1: ಪರಿಸರ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ವ್ಯಾಪ್ತಿಯನ್ನು ನಿಗದಿಪಡಿಸಿ
ಯಾವುದೇ ದಾಖಲೆಯನ್ನು ಬದಲಾಯಿಸುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ನ ಇನ್ಗ್ರೆಸ್ ಸಂರಚನೆಯನ್ನು ಓದಿ:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
ಆಂತರಿಕ ಇನ್ಗ್ರೆಸ್ ಪರಿಸರದ VNet ಒಳಗಿನ ಪರಿಸರದ ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ನಲ್ಲಿ ಬಹಿರಂಗವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಶ್ನೆ ಲ್ಯಾಪ್ಟಾಪ್ ಇನ್ನೊಂದು ಕಂಟೇನರ್ ಅಪ್ ಆಗಿದೆಯೇ ಎಂಬುದಲ್ಲ, ಅದು ಆ VNet ತಲುಪಬಹುದೇ ಎಂಬುದು. VNet ಗೆ ಮಾರ್ಗವಿರುವ ಮತ್ತು ಪರಿಸರದ ಡೀಫಾಲ್ಟ್ ಡೊಮೇನ್ ಖಾಸಗಿ ವಲಯದ ಮೂಲಕ ಪರಿಹರಿಸಲ್ಪಡುವ VPN ಕ್ಲೈಂಟ್ ಅರ್ಹ ಕರೆದಾರ, ಮತ್ತು ಉಳಿದ ಹಂತಗಳು ನಿಖರವಾಗಿ ಅದನ್ನೇ ನಿರ್ಮಿಸುತ್ತವೆ. ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶವಿಲ್ಲದ ಆಂತರಿಕ ಪರಿಸರವು ಆಂತರಿಕ ಇನ್ಗ್ರೆಸ್ ಇರುವ ಅಪ್ಲಿಕೇಶನ್ಗಿಂತ ವಿಭಿನ್ನ ಸತ್ಯ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಹೊರ ಇನ್ಗ್ರೆಸ್ ಪರಿಸರಕ್ಕೆ ಸಾರ್ವಜನಿಕ ಬಾಗಿಲು ನೀಡುವುದಿಲ್ಲ. ವ್ಯಾಪ್ತಿಯನ್ನು ಪೋರ್ಟಲ್ನಲ್ಲಿಯೂ ಮತ್ತು ಟಿಕೆಟ್ನಲ್ಲಿಯೂ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ಮೊದಲು ಟಿಕೆಟ್ ಓದುತ್ತಾರೆ.
ಮುಂದುವರಿಯುವ ಮೊದಲು ಆ ವ್ಯಾಪ್ತಿಯನ್ನು ಸಂರಚನಾ ಮಾಲೀಕರೊಂದಿಗೆ ದೃಢೀಕರಿಸಿ, ಮತ್ತು ಗೇಟ್ ಅನ್ನು ಕಿರಿದಾಗಿ ಇರಿಸಿ: ಪರಿಸರದ VNet ಗೆ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ, ಅಥವಾ ಪರಿಸರದ ಡೀಫಾಲ್ಟ್ ಡೊಮೇನ್ ಖಾಸಗಿ ವಲಯದ ಮೂಲಕ ಪರಿಹರಿಸಲ್ಪಡದಿದ್ದರೆ, ನಿಲ್ಲಿಸಿ ಮತ್ತು ಮೊದಲು ಆ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಿ. VNet ತಲುಪಲಾಗದ ಅಥವಾ ಹೆಸರನ್ನು ಪರಿಹರಿಸಲಾಗದ ಕರೆದಾರನಿಗೆ ಮುಂದಿನ ಯಾವುದೇ ಹಂತ ಪರ್ಯಾಯವಾಗಲಾರದು.
ಹಂತ 2: ನಿಜವಾದ ಹೋಸ್ಟ್ ಹೆಸರು ಮತ್ತು ಪ್ರವೇಶ ವಿಳಾಸವನ್ನು ಸಂಗ್ರಹಿಸಿ
ಪರಿಸರದ ಡೀಫಾಲ್ಟ್ ಡೊಮೇನ್, ಅದರ ಸ್ಥಿರ ಖಾಸಗಿ ಪ್ರವೇಶ ವಿಳಾಸ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ಸಂರಚಿತ FQDN ಅನ್ನು ದಾಖಲಿಸಿ; ಅವನ್ನು ಹಳೆಯ ಸ್ಕ್ರೀನ್ಶಾಟ್ ಅಥವಾ ವಿಕಿ ಪುಟದಿಂದ ಅಲ್ಲ, ಸಂಪನ್ಮೂಲದಿಂದ ತೆಗೆದುಕೊಳ್ಳಿ:
az containerapp env show -n ENV -g RG \
--query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
--query "properties.configuration.ingress.fqdn"Container Apps ನ ಖಾಸಗಿ ಪ್ರವೇಶ ಮಾರ್ಗದರ್ಶನ ಅಪ್ಲಿಕೇಶನ್ನ ಹೋಸ್ಟ್ ಹೆಸರುಗಳನ್ನು ಅಕ್ಷತವಾಗಿ ಇರಿಸಿಕೊಂಡು ಪರಿಸರದ ಡೊಮೇನ್ ಅನ್ನು ಅದರ ಆಂತರಿಕ ವಿಳಾಸಕ್ಕೆ ಹೊಂದಿಸುವುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ನೀವು ಇಲ್ಲಿ ಕೈಯಿಂದ ನಿರ್ಮಿಸುತ್ತಿರುವ ರೂಪ ನಿಖರವಾಗಿ ಅದೇ, ಆದ್ದರಿಂದ ಹೊಸ ನಾಮಕರಣ ಯೋಜನೆಯನ್ನು ಕಲ್ಪಿಸುವ ಬದಲು ವಲಯದ ವಿಷಯವನ್ನು ಅದಕ್ಕೆ ಹೊಂದಿಸಿ.
ನೀವು ಓದಿದ ಡೊಮೇನ್ ಅಪ್ಲಿಕೇಶನ್ ವರದಿ ಮಾಡುವ FQDN ಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ನಿಲ್ಲಿಸಿ ಮತ್ತು ಈಗಲೇ ಅವನ್ನು ಹೊಂದಿಸಿ. ತಪ್ಪು ಪ್ರತ್ಯಯದ ಮೇಲೆ ವಲಯ ನಿರ್ಮಿಸುವುದು ಪರಿಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸಲ್ಪಡುವ ಮತ್ತು ಆದರೂ ತಪ್ಪು ವರ್ಚುವಲ್ ಹೋಸ್ಟ್ನಲ್ಲಿ ಇಳಿಯುವ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಹಂತ 3: ಖಾಸಗಿ ವಲಯವನ್ನು VPN ನ ರಿಜಾಲ್ವರ್ ಮಾರ್ಗದಲ್ಲಿ ಇರಿಸಿ
ಪರಿಸರದ ನಿಜವಾದ ಡೀಫಾಲ್ಟ್ ಡೊಮೇನ್ಗೆ ಬೆಂಬಲಿತ ಖಾಸಗಿ DNS ವಲಯವನ್ನು ರಚಿಸಿ ಅಥವಾ ಮತ್ತೆ ಬಳಸಿ, ದಾಖಲಿತ ವೈಲ್ಡ್ಕಾರ್ಡ್ ಮತ್ತು ವಿಳಾಸ ದಾಖಲೆಗಳು ಸ್ಥಿರ ಪ್ರವೇಶಕ್ಕೆ ತೋರಿಸುತ್ತವೆ. ಆ ವಲಯವನ್ನು ಸೂಕ್ತವಾದ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ಗೆ ಲಿಂಕ್ ಮಾಡಿ, ಮತ್ತು ಲಿಂಕ್ ಸಾಕು ಎಂದು ಊಹಿಸುವ ಬದಲು VPN ನ ಅನುಮೋದಿತ ರಿಜಾಲ್ವರ್ ಮಾರ್ಗದ ಮೂಲಕ ಖಾಸಗಿ ಪ್ರಾಧಿಕಾರವನ್ನು ತಲುಪಬಹುದಾಗಿಸಿ.
ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ಕ್ಲೈಂಟ್ಗೆ ಆ ವಲಯವನ್ನು ತಲುಪಲು ಸಾಮಾನ್ಯವಾಗಿ ಖಾಸಗಿ ರಿಜಾಲ್ವರ್ನ ಒಳಬರುವ ಎಂಡ್ಪಾಯಿಂಟ್ ಅಥವಾ ಬೆಂಬಲಿತ DNS ಫಾರ್ವರ್ಡರ್ ಬೇಕು. ವಲಯವನ್ನು ಲಿಂಕ್ ಮಾಡುವುದು ಲಿಂಕ್ ಮಾಡಿದ ನೆಟ್ವರ್ಕ್ಗಳಿಗೆ Azure ಪರಿಹರಿಸುವುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ; ಅದು ಪ್ರತಿ ಬಾಹ್ಯ ಲ್ಯಾಪ್ಟಾಪ್ನ ಸಾರ್ವಜನಿಕ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸುವುದಿಲ್ಲ. ಬೇರೆ Container Apps ನೆಟ್ವರ್ಕಿಂಗ್ ಮಾದರಿಯಿಂದ ಎರವಲು ಪಡೆದ ಖಾಸಗಿ-ಎಂಡ್ಪಾಯಿಂಟ್ DNS ವಲಯದಿಂದ ಅದನ್ನು ಬದಲಿಸಬೇಡಿ, ಏಕೆಂದರೆ ದಾಖಲೆ ಹೆಸರುಗಳು ಮತ್ತು ವಲಯದ ಪ್ರತ್ಯಯ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
ಈ ಹಂತದ ರೋಲ್ಬ್ಯಾಕ್ ಎಂದರೆ ನೀವು ಸೇರಿಸಿದ ವಲಯ ಲಿಂಕ್ ಅಥವಾ ದಾಖಲೆಯನ್ನು ತೆಗೆದುಹಾಕುವುದು. ಅವುಗಳಲ್ಲಿ ಯಾವುದು ಎಂದು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಒಂದೇ ಲಿಂಕ್ ಅನ್ನು ರದ್ದುಗೊಳಿಸಲು ಹಂಚಿಕೆಯ ವಲಯವನ್ನು ಅಳಿಸುವುದು ಎರಡನೇ ಪರಿಸರವನ್ನು ಒಡೆಯುವ ಪ್ರಸಿದ್ಧ ಮಾರ್ಗ.
ಹಂತ 4: ಹೆಸರನ್ನು ಪರೀಕ್ಷಿಸಿ, ನಂತರ ನಿರಾಕರಿಸಲಾದ ಪ್ರೇಕ್ಷಕರನ್ನು
ಹೋಸ್ಟ್ ಹೆಸರು ಮತ್ತು TLS ಗುರುತನ್ನು ಒಟ್ಟಿಗೆ ಪರೀಕ್ಷಿಸಿ, ವಿಳಾಸವನ್ನು ಮಾತ್ರವಲ್ಲ. ನಿಯಂತ್ರಿತ ಹೆಸರು-ಮ್ಯಾಪಿಂಗ್ ರೋಗನಿರ್ಣಯಕ್ಕಾಗಿ ನೀವು ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಉಳಿಸಿಕೊಂಡು ವಿಳಾಸವನ್ನು ಪಿನ್ ಮಾಡಬಹುದು:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಅಪ್ಲಿಕೇಶನ್ನ ನಿಜವಾದ FQDN ನಿಂದ ಮತ್ತು ವಿಳಾಸವನ್ನು ನಿಜವಾದ ಆಂತರಿಕ ಪ್ರವೇಶದಿಂದ ಬದಲಿಸಿ. ಇದು ಆ ಒಂದು ವಿನಂತಿಯ ಮೇಲೆ ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಮತ್ತು DNS ಒದಗಿಸುವಿಕೆ ಅಲ್ಲ. ಗುರುತಿನ ವೈಫಲ್ಯವನ್ನು ಕಾಣುವ ಉತ್ತೀರ್ಣವಾಗಿ ಪರಿವರ್ತಿಸಲು -k ಸೇರಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಪ್ರಮಾಣಪತ್ರದ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವುದೇ ನೀವು ತಪ್ಪು ಶ್ರೋತೃವನ್ನು ತಾಕುತ್ತಿದ್ದೀರಿ ಎಂಬ ಸಂಕೇತ.
ಸಂಖ್ಯಾತ್ಮಕ ವಿಳಾಸವನ್ನು ನೇರವಾಗಿ ಕೇಳುವುದು TCP 443 ಉತ್ತರಿಸುತ್ತಿದ್ದರೂ ತಪ್ಪು ವರ್ಚುವಲ್ ಹೋಸ್ಟ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು ಅಥವಾ ಮಾನ್ಯತೆಯನ್ನು ವಿಫಲಗೊಳಿಸಬಹುದು, ಆದ್ದರಿಂದ ಯಶಸ್ವಿ IP ಪರೀಕ್ಷೆಯನ್ನು ನೆಟ್ವರ್ಕ್ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯವೆಂದು ಪರಿಗಣಿಸಿ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಲ್ಲ. ಉದ್ದೇಶಿತ ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ ಸಾಮಾನ್ಯ ರಿಜಾಲ್ವರ್ ಮಾರ್ಗವು ಕ್ಲೈಂಟ್ನ DNS ಫಾರ್ವರ್ಡರ್ ಅಥವಾ ವಲಯವನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಖಾಸಗಿ ರಿಜಾಲ್ವರ್ನ ಒಳಬರುವ ಎಂಡ್ಪಾಯಿಂಟ್ ಆಗಿದೆ, ಮತ್ತು ಅಲ್ಲಿನ ವೈಫಲ್ಯ ಕಾಣೆಯಾದ ದಾಖಲೆಯಲ್ಲ, ರಿಜಾಲ್ವರ್ ತಲುಪುವಿಕೆಯ ಸಮಸ್ಯೆ. ಅದೇ ವಿನಂತಿ ಆ ಮಾರ್ಗದಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ನಂತರ ನಿರಾಕರಿಸಲಾದ ಪ್ರೇಕ್ಷಕರು ಇನ್ನೂ ನಿರಾಕರಿಸಲ್ಪಟ್ಟಿದ್ದಾರೆ ಎಂದು ದೃಢೀಕರಿಸಿ.
ಏನನ್ನು ದಾಖಲಿಸಬೇಕು ಮತ್ತು ಏನನ್ನು ರೋಲ್ಬ್ಯಾಕ್ ಮಾಡಬೇಕು
ಕಂಟೇನರ್ನ ಗುರಿ ಪೋರ್ಟ್ ಮತ್ತು ಕ್ಲೈಂಟ್ನ HTTPS ಪೋರ್ಟ್ ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್ಗಳು. ಕಂಟೇನರ್ ಅಲ್ಲಿಯೇ ಕೇಳುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಅದರ ಗುರಿ ಪೋರ್ಟ್ ಅನ್ನು VPN ಮೂಲಕ ಪ್ರಕಟಿಸಬೇಡಿ, ಮತ್ತು ಪೋರ್ಟ್ ಪರೀಕ್ಷೆ ಉತ್ತೀರ್ಣವಾಗಲು ನೆಟ್ವರ್ಕ್ ನಿಯಮವನ್ನು ವಿಸ್ತರಿಸಬೇಡಿ. ಎರಡೂ ಬದಲಾವಣೆಗಳು ಘಟನೆಯ ನಂತರವೂ ಉಳಿಯುತ್ತವೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಆರೋಪಿಸುವುದು ಕಷ್ಟ.
ಉದ್ದೇಶಿತ ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ ಅದರ ಅಧಿಕೃತ ಗುರುತು ಮತ್ತು ಸಾಮಾನ್ಯ DNS ಬಳಸಿ ಹೊಸ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಾಚರಣೆಯೊಂದಿಗೆ ಮುಗಿಸಿ, ನಂತರ ಅನಧಿಕೃತ ಕರೆದಾರ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತಾನೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ ಸಂರಚನೆಯಲ್ಲಿರುವಾಗ, ಪರಿಸರ ಮಟ್ಟದ HTTP ಮಾರ್ಗವು ಈ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಗುರಿಯಾಗಿ ಬಹಿರಂಗಪಡಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನೂ ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಆ ಮಾರ್ಗವು ಇನ್ಗ್ರೆಸ್ ವ್ಯಾಪ್ತಿ ವಿವರಿಸದ ಎರಡನೇ ಬಾಗಿಲು.
ಐದು ಮೌಲ್ಯಗಳನ್ನು ಒಟ್ಟಿಗೆ ದಾಖಲಿಸಿ: ಪರಿಸರದ ವ್ಯಾಪ್ತಿ, ಅಪ್ಲಿಕೇಶನ್ನ ಇನ್ಗ್ರೆಸ್ ವ್ಯಾಪ್ತಿ, FQDN, ಖಾಸಗಿ ಪ್ರವೇಶ ವಿಳಾಸ ಮತ್ತು ರಿಜಾಲ್ವರ್ ಮಾಲೀಕ. ಆ ಐದು ಇಡೀ ಪ್ರವೇಶ ಒಪ್ಪಂದವನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ಇದನ್ನು ಡೀಬಗ್ ಮಾಡುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ನಿಖರವಾಗಿ ಅವನ್ನೇ ಕೇಳುತ್ತಾರೆ.