ನಿಮ್ಮ ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ ಅಪ್ಲಿಕೇಶನ್ ತಲುಪುತ್ತದೆ ಆದರೆ ಅದರ DNS ಸರ್ವರ್ ತಲುಪುವುದಿಲ್ಲ
ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ ಅಪ್ಲಿಕೇಶನ್ನ ಸಬ್ನೆಟ್ ಅನ್ನು ರೂಟ್ ಮಾಡಬಹುದು ಮತ್ತು ಆದರೂ ಪಕ್ಕದಲ್ಲಿರುವ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು. ಹೋಸ್ಟ್ ರೂಟ್ ಸೇರಿಸಿ, ನಂತರ Windows ನಿಜವಾಗಿ ಯಾವ ಸರ್ವರ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.
ಅಪ್ಲಿಕೇಶನ್ನ ಸಬ್ನೆಟ್ ಅನ್ನು ರೂಟ್ ಮಾಡುವುದು ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ನ ಸ್ಪಷ್ಟ ಭಾಗ ಮತ್ತು ಅದು ಇಡೀ ಕೆಲಸವಲ್ಲ. ರಿಸಾಲ್ವರ್ ಸಾಮಾನ್ಯವಾಗಿ ತಾನು ಸೇವೆ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್ಗಿಂತ ಬೇರೆ ವಿಳಾಸದಲ್ಲಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಟನೆಲ್ ಕೂಡ ಹುಡುಕಾಟವನ್ನು ಅದರ ಹೊರಗೆ ಬಿಡಬಹುದು. 10.80.0.0/16 ಅನ್ನು ಮಾತ್ರ ಹೊತ್ತ ಪ್ರೊಫೈಲ್ 10.90.0.53 ಗಾಗಿ ಪ್ರಶ್ನೆಯನ್ನು ಸ್ಥಳೀಯ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಖಾಸಗಿ ವಲಯವಿಲ್ಲ. ರಿಸಾಲ್ವರ್ನ ಮಾರ್ಗವನ್ನು ಸೇರಿಸಿ, ನಂತರ ಸಮಸ್ಯೆಯ ಎರಡನೇ ಅರ್ಧವನ್ನು ನೋಡಿ: ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಯಾವ ಸರ್ವರ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.
ಪುರಾಣ: ಒಂದು ರೂಟ್ ಇಡೀ ಸೇವೆಯನ್ನು ಆವರಿಸುತ್ತದೆ
ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ ಎಂಬುದು ಸಂಪರ್ಕದ ಮೂಲಕ ಹೋಗುವ ಗಮ್ಯಸ್ಥಾನಗಳ ಪಟ್ಟಿ, ಸೇವೆಯ ವಿವರಣೆಯಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ನ ಸಬ್ನೆಟ್ ಮತ್ತು ರಿಸಾಲ್ವರ್ನ ವಿಳಾಸ ಎರಡು ಗಮ್ಯಸ್ಥಾನಗಳು, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಒಂದನ್ನು ಇನ್ನೊಂದಿಲ್ಲದೆ ಹೊರಬಹುದು. ಹಾಗಾದಾಗ, ಅಪ್ಲಿಕೇಶನ್ ವಿಳಾಸದಿಂದ ತಲುಪಬಹುದಾಗಿದ್ದು ಅದರ ಹೆಸರು ವಿಫಲವಾಗುತ್ತದೆ, ಇದು ರೂಟಿಂಗ್ ಕೊರತೆಗಿಂತ DNS ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ.
ರಿಸಾಲ್ವರ್ ಸುತ್ತಲಿನ ಸಬ್ನೆಟ್ ಸಹ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಆವರಿಸುವುದಿಲ್ಲ. ಒಂದು ವಿಳಾಸಕ್ಕೆ ಹೋಸ್ಟ್ ರೂಟ್ ಆ ರಿಸಾಲ್ವರ್ಗೆ ಸಾಕು ಮತ್ತು ಅದರ ನೆರೆಹೊರೆಯವರನ್ನು ತೆರೆಯುವುದಿಲ್ಲ. ಹೋಸ್ಟ್ ರೂಟ್ನ ಅರ್ಥ ಅದೇ: ವಿನ್ಯಾಸದಿಂದ ಸಂಕುಚಿತ, ಮತ್ತು ಮುಂದಿನ ಸೇವೆ ಅದೇ ಸಬ್ನೆಟ್ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಾಗ ಮರೆಯುವುದು ಸುಲಭ.
ಹುಡುಕಾಟ ಕೆಲಸ ಮಾಡಲು ಮೂರು ವಿಷಯಗಳು ನಿಜವಾಗಿರಬೇಕು: ಕ್ಲೈಂಟ್ ರಿಸಾಲ್ವರ್ನ ವಿಳಾಸವನ್ನು ಟನೆಲ್ ಮೂಲಕ ರೂಟ್ ಮಾಡುತ್ತದೆ, ಗೇಟ್ವೇ ಆ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ರಿಸಾಲ್ವರ್ ತನಗೆ ಸಿಗುವ ಮೂಲವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಉತ್ತರವೂ ಒಪ್ಪಿದ ಮಾರ್ಗದಲ್ಲಿ ಹಿಂತಿರುಗಬೇಕು. ಇವುಗಳಲ್ಲಿ ಒಂದು ಇಲ್ಲದಿದ್ದರೆ ಲಕ್ಷಣ ಒಂದೇ ರೀತಿ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂರಚನೆಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ವಿಳಾಸಗಳ ಕೋಷ್ಟಕವನ್ನು ಬರೆದಿಡುವುದು ಯೋಗ್ಯ.
ಪ್ರೊಫೈಲ್ ಯಾವ ವಿಳಾಸಗಳನ್ನು ಹೊರಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ
ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪಟ್ಟಿ ಮಾಡಿ: ಅಪ್ಲಿಕೇಶನ್ ನೆಟ್ವರ್ಕ್, ರಿಸಾಲ್ವರ್ನ ವಿಳಾಸ ಮತ್ತು ಟನೆಲ್ ಅನ್ನೇ ಮುಕ್ತಾಯಗೊಳಿಸುವ ಸಾರ್ವಜನಿಕ ಅಂತಿಮ ಬಿಂದು. ಮೂರನೆಯದನ್ನು ಎಂದಿಗೂ ಟನೆಲ್ ಒಳಗೆ ರೂಟ್ ಮಾಡಬಾರದು, ಏಕೆಂದರೆ ಹೊರಗಿನ ಸಂಪರ್ಕಕ್ಕೆ ಟನೆಲ್ಗಿಂತ ಮೊದಲು ಇರುವ ಮಾರ್ಗ ಬೇಕು.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
DNS ಗಾಗಿ UDP ಮತ್ತು TCP ಎರಡನ್ನೂ ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಅನುಷ್ಠಾನಗಳು UDP ಜೊತೆಗೆ TCP ಅನ್ನೂ ಬೆಂಬಲಿಸುವ ನಿರೀಕ್ಷೆ ಇದೆ, ಮತ್ತು ತಡೆಯಲಾದ TCP ಮಾರ್ಗವು ಸ್ವಚ್ಛ ವಿಫಲತೆಗಳ ಬದಲು ನಿಧಾನ, ಭಾಗಶಃ ವಿಫಲತೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಖಾಸಗಿ ವಲಯವನ್ನು IPv6 ಮೂಲಕವೂ ನೀಡಿದರೆ, ಸಮಾನವಾದ ಹೋಸ್ಟ್ ವಿನಾಯಿತಿ IPv6 ವಿಳಾಸ ಮತ್ತು ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಪ್ರತ್ಯೇಕ ನಮೂದು.
ಏನನ್ನಾದರೂ ಸೇರಿಸುವ ಮೊದಲು ಪ್ರೊಫೈಲ್ ಈಗಾಗಲೇ ಏನನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂದು ದಾಖಲಿಸಿ. ನಕಲಿ ರೂಟ್ ಹಾನಿಕರವಲ್ಲ, ಆದರೆ ಅನಿರೀಕ್ಷಿತ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ರೂಟ್ ನಿಮಗೆ ನೀಡಿದ ವಿಳಾಸ ಯೋಜನೆಗಿಂತ ಬೇರೆ ಯೋಜನೆಗೆ ಪ್ರೊಫೈಲ್ ವಿನ್ಯಾಸಗೊಂಡಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ.
ಸಂಪರ್ಕದ ಮಾಲೀಕರ ಮೂಲಕ ಹೋಸ್ಟ್ ರೂಟ್ ಸೇರಿಸಿ
ಸ್ಥಳೀಯವಾಗಿ ನಿರ್ವಹಿಸಲಾದ ಸ್ಥಳೀಯ Windows ಪ್ರೊಫೈಲ್ಗೆ, ರೂಟ್ ಯಂತ್ರದ ಜಾಗತಿಕ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕಕ್ಕೆ ಅಲ್ಲ, ಸಂಪರ್ಕಕ್ಕೆ ಸೇರಿದ್ದು. ಮೊದಲು ಸೇರ್ಪಡೆಯ ಪೂರ್ವವೀಕ್ಷಣೆ ಮಾಡಿ, ನಂತರ ಪ್ರೊಫೈಲ್ ಬಳಸುವ ಅದೇ ವ್ಯಾಪ್ತಿಯೊಂದಿಗೆ ಅನ್ವಯಿಸಿ.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
ಮೊದಲ ಆದೇಶ ಏನನ್ನೂ ಸ್ಥಾಪಿಸದೆ ಬದಲಾವಣೆಯ ಪೂರ್ವವೀಕ್ಷಣೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು ಪ್ರೊಫೈಲ್ ಪ್ರಸ್ತುತ ಹೊತ್ತಿರುವ ರೂಟ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. Microsoft ನ Add-VpnConnectionRoute ಉಲ್ಲೇಖ ಪ್ರತಿ-ಬಳಕೆದಾರ ಮತ್ತು ಎಲ್ಲಾ-ಬಳಕೆದಾರ ವ್ಯಾಪ್ತಿಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ; ಎಲ್ಲಾ-ಬಳಕೆದಾರ ಪ್ರೊಫೈಲ್ಗೆ ತನ್ನದೇ ವ್ಯಾಪ್ತಿ ನಿಯತಾಂಕ ಬೇಕು, ಮತ್ತು ಎಲ್ಲಾ-ಬಳಕೆದಾರ ಪ್ರೊಫೈಲ್ ವಿರುದ್ಧ ಪ್ರತಿ-ಬಳಕೆದಾರ ಆದೇಶ ವಿಫಲವಾಗುತ್ತದೆ ಅಥವಾ ತಪ್ಪು ಸ್ಥಳಕ್ಕೆ ಬೀಳುತ್ತದೆ.
ಪ್ರೊಫೈಲ್ ನಿರ್ವಹಿಸಲ್ಪಟ್ಟಾಗ ಅಥವಾ ಮಾರಾಟಗಾರ ಕ್ಲೈಂಟ್ನಿಂದ ಬಂದಾಗ, ಬದಲಾವಣೆ ಆ ಮಾಲೀಕರಿಗೆ ಸೇರಿದ್ದು. ಸಂಪರ್ಕ ನೀತಿಯ ಮೇಲೆ ಶಾಶ್ವತ ಸಿಸ್ಟಮ್ ರೂಟ್ ಅನ್ನು ಜೋಡಿಸುವುದು ನೀತಿಯನ್ನು ಮತ್ತೆ ಅನ್ವಯಿಸುವವರೆಗೆ ಮತ್ತು ರೂಟ್ ಮಾಯವಾಗುವವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ, ಬೆಂಬಲ ಕರೆಯ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ. ಆ ವೈಫಲ್ಯ ಮೌನವಾಗಿದೆ: ರೂಟ್ ಮಾಯವಾಗುತ್ತದೆ, ಹೆಸರು ಪರಿಹರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಮತ್ತು ಯಾರೂ ಎರಡು ಘಟನೆಗಳನ್ನು ಜೋಡಿಸುವುದಿಲ್ಲ. ಬದಲಾವಣೆಯನ್ನು ಮಾಲೀಕರ ಸ್ವಂತ ದಾಖಲೆಯಲ್ಲಿ ಇರಿಸಿ, ಮುಂದಿನ ಮರುಅನ್ವಯ ಅದನ್ನು ಅಳಿಸುವ ಬದಲು ಹೊತ್ತುಕೊಳ್ಳುತ್ತದೆ.
ಅನ್ವಯಿಸಿದ ನಂತರ ರೂಟ್ ಜಾರಿಗೆ ಬಂದಿದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಪ್ರೊಫೈಲ್ ಅನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ. ಜೀವಂತ ಸಂಪರ್ಕದಲ್ಲಿ ರೂಟ್ ಬದಲಾವಣೆಗಳು ಯಾವಾಗಲೂ ತೆಗೆದುಕೊಳ್ಳಲ್ಪಡುವುದಿಲ್ಲ, ಮತ್ತು ಮರುಸಂಪರ್ಕವು ನಿಮ್ಮ ಬಳಕೆದಾರರು ನಿಜವಾಗಿ ಹೊಂದಿರುವ ಸ್ಥಿತಿಯನ್ನೂ ಮರುಸೃಷ್ಟಿಸುತ್ತದೆ.
ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಯಾವ ರಿಸಾಲ್ವರ್ ಬಳಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ
ರೂಟ್ ರಿಸಾಲ್ವರ್ಗೆ ವಿಳಾಸಗೊಳಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಯಾವ ಹೆಸರುಗಳನ್ನು ಅಲ್ಲಿಗೆ ಕಳುಹಿಸಬೇಕೆಂದು ಅದು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಆ ಆಯ್ಕೆ ಪ್ರತ್ಯೇಕ ಕಾರ್ಯವಿಧಾನ. Windows ನಲ್ಲಿ ಪರಿಣಾಮಕಾರಿ ಹೆಸರಿನ ಜಾಗದ ನಿಯಮಗಳು ಪ್ರತಿ ಡೊಮೇನ್ಗೆ ರಿಸಾಲ್ವರ್ ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಆದರೆ ಪ್ರೊಫೈಲ್ನ DNS ಸೆಟ್ಟಿಂಗ್ಗಳು ಡೀಫಾಲ್ಟ್ ಒದಗಿಸುತ್ತವೆ. ಈ ಎರಡು ಪದರಗಳು ಯಾವುದೇ ದೋಷ ಉಂಟುಮಾಡದೆ ಭಿನ್ನಾಭಿಪ್ರಾಯ ಹೊಂದಬಹುದು, ಆದ್ದರಿಂದ ನೇರ ಪ್ರಶ್ನೆ ಅರ್ಧ ಸಾಕ್ಷಿ ಮಾತ್ರ.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
ಮೊದಲ ಆದೇಶ ಜಾರಿಯಲ್ಲಿರುವ ಹೆಸರಿನ ಜಾಗದ ನೀತಿಯನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು ಖಾಸಗಿ ರಿಸಾಲ್ವರ್ಗೆ ನೇರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರನ್ನು ಕೇಳುತ್ತದೆ. ನೇರ ಉತ್ತರ ಮಾರ್ಗ ಮತ್ತು ರಿಸಾಲ್ವರ್ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂದು ಸಾಬೀತು ಮಾಡುತ್ತದೆ; ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಹುಡುಕಾಟ ಆ ಸರ್ವರ್ ಆಯ್ಕೆ ಮಾಡಿತು ಎಂದು ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ. ಅದನ್ನು ಅದೇ ಹೆಸರಿನ ಸಾಮಾನ್ಯ ಹುಡುಕಾಟ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪಡೆಯುವ ಉತ್ತರದೊಂದಿಗೆ ಹೋಲಿಸಿ.
ಕ್ಯಾಶ್ಗಳು ಮತ್ತು ಬ್ರೌಸರ್ ಮಟ್ಟದ ಸುರಕ್ಷಿತ DNS ಅನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ, ಅದು ಬಳಕೆದಾರ ಟೈಪ್ ಮಾಡಿದ ಹೆಸರುಗಳಿಗೆ ಸಿಸ್ಟಮ್ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೈಪಾಸ್ ಮಾಡಬಹುದು. ಹುಡುಕಾಟ ಪ್ರತ್ಯಯವು ಇನ್ನೊಂದು ದಾರಿತಪ್ಪಿಸುವ ಸುಳಿವು: ಅದು ಚಿಕ್ಕ ಹೆಸರನ್ನು ಸಂಪೂರ್ಣ ಅರ್ಹ ಹೆಸರಾಗಿ ವಿಸ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಯಾವ ಸರ್ವರ್ ಉತ್ತರಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ.
ಕೊನೆಯಲ್ಲಿ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಸಾಮಾನ್ಯ ಹುಡುಕಾಟವನ್ನು ಪುನರಾವರ್ತಿಸಿ, ನಂತರ ಸಾಮಾನ್ಯ ಬ್ರೌಸಿಂಗ್ ಇನ್ನೂ ತನ್ನ ಅನುಮೋದಿತ ನೀತಿಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಸಂಬಂಧವಿಲ್ಲದ ಹೆಸರು ಪರಿಹರಿಸಲು ಖಾಸಗಿ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಸಾರ್ವಜನಿಕದೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದು ಪರಿಹಾರವಲ್ಲ, ಮತ್ತು ಅದು ಖಾಸಗಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಎಂದಿಗೂ ಹೋಗಬಾರದಿದ್ದ ಸ್ಥಳಕ್ಕೆ ಮೌನವಾಗಿ ಸರಿಸುತ್ತದೆ.