VPN ಸಾಧನ ಸ್ಥಿತಿ ಪರಿಶೀಲನೆ ತಡೆಯುತ್ತಿಲ್ಲವೇ? ಮೊದಲು ವರದಿಯನ್ನು ಅನುಸರಿಸಿ
ನಿಮ್ಮ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಏಜೆಂಟ್ ಆರೋಗ್ಯಕರ ಸ್ಥಿತಿ ವರದಿ ಮಾಡುತ್ತದೆ, ಆದರೂ ಒಳಗಿನ ಅಪ್ಲಿಕೇಶನ್ ತೆರೆಯುತ್ತದೆ. ಸಂಗ್ರಾಹಕ, ತೀರ್ಪು ಮತ್ತು ತಡೆ ಮೂಲಕ ಸಾಗಿ, ನಂತರ ಒಂದೇ ವಿನಂತಿಯಿಂದ ನಿರಾಕರಣೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ.
ವಾರಗಳ ಹಿಂದೆ ಆ್ಯಂಟಿವೈರಸ್ ಸಹಿಗಳು ನವೀಕರಣವನ್ನು ನಿಲ್ಲಿಸಿದ ಲ್ಯಾಪ್‌ಟಾಪ್ ಇನ್ನೂ ನಿಮ್ಮ ಒಳಗಿನ ಅಪ್ಲಿಕೇಶನ್ ತೆರೆಯಲು ಸಾಧ್ಯವಾದರೆ, ನೀತಿ ದಾಖಲೆಯೇ ತಪ್ಪಾಗಿರುವ ವಿಷಯ ಎಂಬುದು ಅಪರೂಪ. ಪ್ರವೇಶ ನಿರಾಕರಿಸುವ ಮೊದಲು ಮೂರು ಪ್ರತ್ಯೇಕ ವ್ಯವಸ್ಥೆಗಳು ಒಪ್ಪಬೇಕು: ಯಾವುದೋ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಅಳೆಯುತ್ತದೆ, ಯಾವುದೋ ಆ ಮಾಪನವನ್ನು ಅನುಮತಿ ಅಥವಾ ನಿರಾಕರಣೆ ತೀರ್ಪಾಗಿ ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವುದೋ ನಿಜವಾಗಿ ಸಂಚಾರವನ್ನು ಬಿಡುತ್ತದೆ. ಅನುಸರಣೆ ಇಲ್ಲದ ಸಾಧನ ಹೇಗಾದರೂ ಒಳಗೆ ಬಂದಾಗ, ಆ ಕೊಂಡಿಗಳಲ್ಲಿ ನಿಖರವಾಗಿ ಒಂದು ಇಲ್ಲದಿರುತ್ತದೆ ಅಥವಾ ಇರಬಾರದ ಸಾಕ್ಷ್ಯವನ್ನು ನಂಬುತ್ತದೆ. ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳು ಆ ಕ್ರಮದಲ್ಲೇ ಸಾಗುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಒಂದು ನಿಲ್ಲುವ ಬಿಂದುವಿದೆ.
ತಡೆ ಕೊನೆಯ ಹಂತ, ಮೊದಲನೆಯದಲ್ಲ
ದೃಢೀಕರಣ ಮತ್ತು ಸಾಧನ ಸ್ಥಿತಿ ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ಯಶಸ್ವಿ ಲಾಗಿನ್ ಒಂದು ರುಜುವಾತು ಮಂಡಿಸಲಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಅದನ್ನು ಮಂಡಿಸಿದ ಯಂತ್ರದಲ್ಲಿ ಯಾವ ತಂತ್ರಾಂಶ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ಈ ಕಂದರವೇ ನಕಲಿಸಿದ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ ಆರೋಗ್ಯಕರ ಕಾಣುವ ಸೆಷನ್ ಅನ್ನು ಅನಾರೋಗ್ಯಕರ ಹೋಸ್ಟ್‌ಗೆ ಒಯ್ಯಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ.
ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನುಸರಣಾ ಕೆಲಸಕ್ಕೆ ಈ ಸರಪಳಿಗೆ ಪದಕೋಶ ಈಗಾಗಲೇ ಇದೆ. RFC 5209 ನಲ್ಲಿನ NEA ಉಲ್ಲೇಖ ಮಾದರಿ ಕೆಲಸವನ್ನು ಸಂಗ್ರಾಹಕ, ಮೌಲ್ಯಮಾಪನ ಹಂತ ಮತ್ತು ಜಾರಿ ಬಿಂದುವಾಗಿ ವಿಭಜಿಸುತ್ತದೆ, ಮತ್ತು ತನ್ನದೇ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಸುಳ್ಳು ಹೇಳುವ ಕ್ಲೈಂಟ್ ಮಾದರಿಯ ಹೊರಗಿದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ. ಈ ಷರತ್ತು ರೇಖಾಚಿತ್ರಕ್ಕಿಂತ ಮುಖ್ಯ: ವಿಶ್ವಾಸಾರ್ಹ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್ ಸ್ವಯಂ-ವರದಿ ಮಾಡಿದ ಮಾಪನವನ್ನು ಸತ್ಯವಾಗಿ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ.
ಸಂಗ್ರಾಹಕವನ್ನು ವ್ಯಾಪ್ತಿಯ ಬಗ್ಗೆ ಪ್ರಾಮಾಣಿಕವಾಗಿರಿಸಿ. ನಿಮ್ಮ ನೀತಿ ಹೆಸರಿಸುವ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪ್ರವೇಶ ಕೇಳುವ ಸಾಧನದಲ್ಲಿ ವರದಿ ಮಾಡಬೇಕು, ಮತ್ತು ಬಹಳ ಕಡಿಮೆ ಬೇರೆ ಏನನ್ನಾದರೂ. ಸ್ಥಾಪಿತವಾದ ಪ್ರತಿ ಪ್ಯಾಕೇಜ್ ಪಟ್ಟಿ ಮಾಡುವ ದಾಸ್ತಾನು ಏಜೆಂಟ್ ಸಾಧನ-ಸ್ಥಿತಿ ಸಂಗ್ರಾಹಕಕ್ಕಿಂತ ಬೇರೆ ಸಾಧನ, ಮತ್ತು ವ್ಯತ್ಯಾಸವು ಒಟ್ಟಿಗೆ ಧಾರಣ ಮತ್ತು ನಿಖರತೆಯ ಸಮಸ್ಯೆ. ವರದಿಯನ್ನು ಒಂದು ಸಾಧನ ಗುರುತಿಗೆ ಬಂಧಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಮೌಲ್ಯಮಾಪಕನು ಯಾವ ಯಂತ್ರಕ್ಕೆ ಈಗಷ್ಟೇ ಅನುಮತಿ ನೀಡಿದನೆಂದು ಊಹಿಸುತ್ತಿದ್ದಾನೆ.
ಕೆಂಪು ಸ್ಥಿತಿ ತೋರಿಸುವ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ನಿಯಂತ್ರಣವಲ್ಲ. ನಿರಾಕರಿಸಲಾದ ಬಳಕೆದಾರ ಇನ್ನೂ ಎಲ್ಲಿಗೆ ತಲುಪಬಲ್ಲನೆಂದು ಕೇಳಿ: ವಿಕಿ, ಫೈಲ್ ಹಂಚಿಕೆ, ಡೇಟಾಬೇಸ್ ಪೋರ್ಟ್? ಪರಿಹಾರಕ್ಕೆ ಒಂದು ಸಣ್ಣ ಮೇಲ್ಮೈ ಬೇಕು, ಮತ್ತು ಉಳಿದೆಲ್ಲವೂ ತಡೆಯ ಹಿಂದೆ ಇರಬೇಕು.
ನಿಯಮ ಓದುವ ಮೊದಲು ವರದಿ ಓದಿ
ಕ್ಲೈಂಟ್‌ನ ಹಸಿರು ಟಿಕ್‌ನಿಂದ ಅಲ್ಲ, ಮೂಲದಿಂದ ಪ್ರಾರಂಭಿಸಿ. Windows ನಲ್ಲಿ ಸ್ಥಳೀಯ ಮಾಪನ Defender ನಿಂದ ಅಥವಾ ತನ್ನನ್ನು Security Center ನಲ್ಲಿ ನೋಂದಾಯಿಸಿಕೊಂಡ ಉತ್ಪನ್ನದಿಂದ ಬರುತ್ತದೆ, ಮತ್ತು ಎರಡನ್ನೂ ಮಾರಾಟಗಾರರ ಕನ್ಸೋಲ್ ಇಲ್ಲದೆ ಓದಬಹುದು:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateಎರಡನೇ ಆಜ್ಞೆ productState ಎಂಬ ಪೂರ್ಣಾಂಕವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಅದರ ಬಿಟ್‌ಗಳು ಸಡಿಲವಾಗಿ ದಾಖಲಾಗಿವೆ ಮತ್ತು ಮಾರಾಟಗಾರರು ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ ಹಾಗೂ ನವೀನತೆಯ ಧ್ವಜಗಳನ್ನು ಬೇರೆ ಬೇರೆ ರೀತಿ ಪ್ಯಾಕ್ ಮಾಡುತ್ತಾರೆ, ಆದ್ದರಿಂದ ವಿಶ್ಲೇಷಿಸುವ ಬದಲು ದೃಢೀಕರಿಸಿ. ತೃತೀಯ ಪಕ್ಷದ ಸೂಟ್‌ಗಳು ಅನ್‌ಇನ್‌ಸ್ಟಾಲ್ ನಂತರವೂ Security Center ನಮೂದನ್ನು ಬಿಡುತ್ತವೆ, ಮತ್ತು ಅದು ಈಗ ಡಿಸ್ಕ್‌ನಲ್ಲಿಲ್ಲದ ತಂತ್ರಾಂಶದ ಬಗ್ಗೆ ವರದಿ ಮಾಡುತ್ತದೆ.
ಜನರು ಬಿಟ್ಟುಬಿಡುವ ಕ್ಷೇತ್ರ ವಯಸ್ಸು. ಸಹಿಯ ಸಮಯಮುದ್ರೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಯಂತ್ರದ ಗಡಿಯಾರಕ್ಕೆ ಹೋಲಿಸಿದಾಗ ಮಾತ್ರ ಅರ್ಥವನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಣ್ಣಿನಿಂದ ಅಂದಾಜು ಮಾಡುವ ಬದಲು ಅದನ್ನು ಮಧ್ಯಂತರವಾಗಿ ಪರಿವರ್ತಿಸಿ:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursಈಗ ನೀತಿಗೆ ಓದಲು ಒಂದು ಸಂಖ್ಯೆ ಇದೆ. ನಿಮ್ಮ ನಿಯಮ 72 ಗಂಟೆ ಎಂದು ಹೇಳಿದರೆ, ಅದು ಬಳಸುವ ಸಂಖ್ಯೆ ಅದೇ, ಮತ್ತು ಒಂದು ವಾರ ನಿದ್ರಿಸಿದ ಲ್ಯಾಪ್‌ಟಾಪ್ ಯಾರೂ ಲೇಬಲ್ ವ್ಯಾಖ್ಯಾನಿಸದೆಯೇ ವಿಫಲವಾಗುತ್ತದೆ. ಆಜ್ಞೆಯ ಪಕ್ಕದಲ್ಲಿ ಮಿತಿಯನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸಾಧನ ಬದಲಾದಾಗ ಎರಡೂ ಜಾರುತ್ತವೆ.
ಪ್ರತಿ ಸಾಧನ ಸ್ಥಿತಿಯನ್ನು ಲಿಖಿತ ತೀರ್ಪಾಗಿ ಪರಿವರ್ತಿಸಿ
ಸ್ಥಿತಿಯ ಬಗ್ಗಿನ ಬಹುತೇಕ ವಿವಾದಗಳು ವಾಸ್ತವವಾಗಿ ಅಜ್ಞಾತ ಸಾಲಿನ ಬಗ್ಗಿನ ವಿವಾದಗಳು. ಮೊದಲ ಘಟನೆಗೆ ಮೊದಲೇ ಅದನ್ನು ನಿರ್ಧರಿಸಿ, ಸಾಕ್ಷ್ಯ, ತೀರ್ಪು ಮತ್ತು ಮಾಲೀಕರನ್ನು ಹೆಸರಿಸುವ ಕೋಷ್ಟಕದಲ್ಲಿ, ಯಾರೂ ಗೇಟ್‌ವೇ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ತಕ್ಷಣ ನಿರ್ಧಾರ ಮಾಡದಂತೆ.
| Evidence the assessor has | Verdict | What it protects against |
|---|---|---|
| Timestamp inside the policy window, protective service running | Admit to normal applications | Nothing yet; the other checks still apply |
| Timestamp older than the window | Deny, admit remediation page only | Signature rollback and dormant laptops |
| Service disabled or reporting off | Deny, escalate to the endpoint owner | An agent reporting stale success |
| No report at all for this session | Treat as deny, never as healthy | Agents that fail open under load |
ಉತ್ಪನ್ನಗಳು ಭಿನ್ನವಾಗುವುದು ಕೆಳಗಿನ ಸಾಲಿನಲ್ಲೇ. ಕೆಲವು ಗೇಟ್‌ವೇಗಳು ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸಿ ಕಾರಣ ಹೇಳುತ್ತವೆ; ಇನ್ನು ಕೆಲವು ಸುರಂಗ ಏರಲು ಬಿಟ್ಟು ಸೀಮಿತ ನೀತಿ ಅನ್ವಯಿಸುತ್ತವೆ; ಕೆಲವೇ ಕೊನೆಯ ತಿಳಿದ ಉತ್ತಮ ವರದಿಗೆ ಮರಳುತ್ತವೆ. ಮೊದಲ ಎರಡು ಮಾತ್ರ ಸಮರ್ಥನೀಯ, ಮತ್ತು ನಿಮ್ಮದು ಯಾವುದು ಎಂದು ಪರೀಕ್ಷಿಸುವುದು ಯೋಗ್ಯ.
ಗುರುತು ಮತ್ತು ಅನುಮತಿಯನ್ನು ಸಹ ಅವುಗಳದೇ ಪಥಗಳಲ್ಲಿ ಇರಿಸಿ. ಪ್ರತಿ ಸ್ಥಿತಿ ಪರೀಕ್ಷೆಯನ್ನೂ ಪಾಸ್ ಮಾಡುವ ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ಸರಿಯಾದ ಮಾನವ ಅಧಿಕಾರದ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ಸಾಧನ ಪ್ರಮಾಣಪತ್ರವು ಕೀಲಿಯ ಹೊಂದಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಫೈಲ್‌ಸಿಸ್ಟಂ ಸ್ಥಿತಿಯನ್ನಲ್ಲ. ಮೂರನ್ನೂ ಒಂದೇ ಬೂಲಿಯನ್‌ಗೆ ಸ್ಕ್ವೀಜ್ ಮಾಡುವುದು ಹೆಲ್ಪ್‌ಡೆಸ್ಕ್ ಖಾತೆಗೆ ಉತ್ಪಾದನೆಗೆ ಶಾಶ್ವತ ಪ್ರವೇಶ ಸಿಗುವ ದಾರಿ.
ಜಾರಿ ಮಾರ್ಗವನ್ನು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಿಂದಲ್ಲ, ವಿನಂತಿಯಿಂದ ಪರಿಶೀಲಿಸಿ
ಜಾರಿ ಎಂಬುದು ವಿನಂತಿಯ ಗುಣ, ಆದ್ದರಿಂದ ಒಂದು ವಿನಂತಿಯಿಂದಲೇ ಅದನ್ನು ಅಳೆಯಿರಿ. ಅನುಸರಣೆ ಇಲ್ಲದ ಯಂತ್ರವನ್ನು ಸುರಂಗದ ಮೇಲೆ ಇರಿಸಿ ಮತ್ತು ನಿಜವಾದ ಬಳಕೆದಾರ ಮಾಡುವ ಕರೆಯನ್ನು ಮಾಡಿ:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthತಡೆಯಬೇಕಾದ ಸಾಧನದಿಂದ 200 ಬಂದರೆ ತೀರ್ಪು ಎಂದೂ ಡೇಟಾ ಮಾರ್ಗವನ್ನು ತಲುಪಿಲ್ಲ ಎಂದರ್ಥ. ಎರಡು ಸಾಮಾನ್ಯ ಕಾರಣಗಳು: ನೀತಿಯು ಪರೀಕ್ಷಾ ಖಾತೆ ಎಂದೂ ಸೇರದ ಗುಂಪಿಗೆ ಜೋಡಿಸಲಾಗಿದೆ, ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ VPN ಒಡೆತನದಲ್ಲಿಲ್ಲದ ಮಾರ್ಗದಲ್ಲಿ ತಲುಪಬಹುದು.
ಮೊದಲು ಮಾರ್ಗನಿರ್ದೇಶನದ ಊಹೆಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಆಂತರಿಕ ಹೆಸರು ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ಸ್ಥಳೀಯ LAN ಮೂಲಕ ತಲುಪುವ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಿದರೆ, ಸುರಂಗ ಅಪ್ರಸ್ತುತ ಮತ್ತು ಯಾವ ನೀತಿಯೂ ಅನ್ವಯವಾಗದು. ಆ ವಿಳಾಸವನ್ನು ಗೇಟ್‌ವೇ ತಳ್ಳುವ ಮಾರ್ಗದೊಂದಿಗೆ ಹೋಲಿಸಿ. OpenVPN ನಲ್ಲಿ ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ನ ನೀತಿ ಸಾಮಾನ್ಯ ಹೆಸರಿನಿಂದ ಕೀಲಿ ಹಾಕಿದ ಫೈಲ್‌ಗಳಲ್ಲಿ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ಪರಿಶೀಲಿಸುವುದು ಸುಲಭ:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17disable ಇರುವ ಫೈಲ್ ಆ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕಡಿತಗೊಳಿಸುತ್ತದೆ, ಆದರೆ push "route ..." ಸಾಲು ಎಲ್ಲಿಗೆ ತಲುಪಬಹುದೆಂಬುದನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ. ಎರಡೂ ಜಾರಿ, ಮತ್ತು ಎರಡೂ ವರದಿಯನ್ನು ಡೀಬಗ್ ಮಾಡುವವರಿಗೆ ಗೋಚರ.
ಒಂದೇ ಪ್ರಾಯೋಗಿಕ ಖಾತೆಯಲ್ಲಿ ನಾಲ್ಕು ಪ್ರಕರಣಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
ಕೊನೆಯ ಪರಿಶೀಲನೆ ಒಂದು ಸಣ್ಣ ಮ್ಯಾಟ್ರಿಕ್ಸ್, ಸುಖ ಮಾರ್ಗವಲ್ಲ. ಒಂದು ಪರೀಕ್ಷಾ ಖಾತೆಯನ್ನು ನಾಲ್ಕು ಸ್ಥಿತಿಗಳ ಮೂಲಕ ಓಡಿಸಿ: ಪ್ರಸ್ತುತ, ಅವಧಿ ಮುಗಿದ ಸಹಿ, ರಕ್ಷಣೆ ನಿಷ್ಕ್ರಿಯ, ಏಜೆಂಟ್ ಸ್ಥಾಪಿಸಿಲ್ಲ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಮೌಲ್ಯಮಾಪನ ಲಾಗ್‌ನಲ್ಲಿ ತೀರ್ಪನ್ನು, ಅಪ್ಲಿಕೇಶನ್ ಹಿಂತಿರುಗಿಸುವ HTTP ಸ್ಥಿತಿಯನ್ನು, ಮತ್ತು ಪರಿಹಾರ ಪುಟ ಲೋಡ್ ಆಯಿತೇ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ.
foreach ($case in 'current', 'stale', 'disabled', 'absent') {
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}ಎರಡು ವಿವರಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು ಸುಲಭ. ಮೊದಲು ಮರುಪ್ರಸಾರ: ಯಂತ್ರ ಆರೋಗ್ಯಕರವಾಗಿದ್ದಾಗ ತೆಗೆದುಕೊಂಡ ವರದಿಯನ್ನು ಅದೇ ಸಾಧನದ ನಂತರದ ಅವಧಿಗೆ ಸ್ವೀಕರಿಸಬಾರದು, ಆದ್ದರಿಂದ ಪ್ರಸ್ತುತ ಸಂಪರ್ಕಕ್ಕೆ ಬದ್ಧವಾದ ಸಮಯಮುದ್ರೆಯನ್ನು ಹುಡುಕಿ. ನಂತರ ತೆಗೆದುಹಾಕುವಿಕೆ: ಏಜೆಂಟ್ ಅನ್‌ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿದಾಗ ಹಳೆಯ ವರದಿಯಂತೆಯೇ ನಿರಾಕರಣೆ ಬರಬೇಕು, ಸ್ವಚ್ಛ ಪಾಸ್ ಅಲ್ಲ, ಮತ್ತು ಇದೇ ಪ್ರಕರಣವನ್ನು ಹೆಚ್ಚಾಗಿ ಎಂದೂ ಪರೀಕ್ಷಿಸುವುದಿಲ್ಲ.
ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಕೋಷ್ಟಕಕ್ಕೆ ಹೊಂದಿದಾಗ, ಮುಂದೆ ಗೇಟ್‌ವೇ ನಡೆಸುವವರಿಗೆ ಮೂರು ವಿಷಯಗಳನ್ನು ಒಪ್ಪಿಸಿ: ಆಜ್ಞೆಗಳು, ಮಿತಿ ಮತ್ತು ನಿರೀಕ್ಷಿತ ನಾಲ್ಕು ಫಲಿತಾಂಶಗಳು. ಈ ಹಸ್ತಾಂತರವೇ ನಿಜವಾದ ಡೆಲಿವರೆಬಲ್, ಏಕೆಂದರೆ ನೀತಿ ದಾಖಲೆಯಲ್ಲಿ ಮಾತ್ರ ಜೀವಿಸುವ ಸ್ಥಿತಿ ವಿನ್ಯಾಸವು ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸಾಧನ ತನ್ನ ವರದಿ ಕ್ಷೇತ್ರವನ್ನು ಬದಲಿಸಿದಾಗ ಮೊದಲ ಬಾರಿಗೆ ಜಾರುತ್ತದೆ.