ಸ್ಪ್ಲಿಟ್-ಟನೆಲ್ ದಾಖಲೆಗಳಿಗೆ ಪ್ರತಿ ಮಾರ್ಗದ ಪಕ್ಕದಲ್ಲಿ DNS ನಿಯಮ ಬೇಕು
ಮಾರ್ಗವು ವಿಳಾಸದಿಂದ ನಿರ್ಧರಿಸುತ್ತದೆ, ರಿಜಾಲ್ವರ್ ಹೆಸರಿನಿಂದ ನಿರ್ಧರಿಸುತ್ತದೆ. ಪ್ರತಿ ಹರಿವಿಗೆ ಎರಡೂ ಆಯ್ಕೆಕಾರರನ್ನು ದಾಖಲಿಸಿ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಒಂದು ಪರೀಕ್ಷೆ, ಇಲ್ಲದಿದ್ದರೆ DNS ಬದಲಾದಾಗ ಟಿಪ್ಪಣಿ ವಿಫಲವಾಗುತ್ತದೆ.
«ಕಚೇರಿ ಸಂಚಾರ VPN ಮೂಲಕ ಹೋಗುತ್ತದೆ» ಎಂದು ಹೇಳುವ ಸ್ಪ್ಲಿಟ್-ಟನೆಲ್ ಟಿಪ್ಪಣಿ ಒಂದು ನಿರ್ಧಾರವನ್ನು ದಾಖಲಿಸಿದೆ ಮತ್ತು ಇನ್ನೂ ಮೂರನ್ನು ಸೂಚಿಸಿದೆ. ಪ್ಯಾಕೆಟ್ ಪದರದಲ್ಲಿ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವು ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸದಿಂದ ಇಂಟರ್ಫೇಸ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ; ಹೆಸರಿನ ಪದರದಲ್ಲಿ ರಿಜಾಲ್ವರ್ ಪ್ರಶ್ನೆಯಿಂದ ಸರ್ವರ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಈ ಎರಡು ಆಯ್ಕೆಗಳು ಸ್ವತಂತ್ರವಾಗಿ ನಡೆಯುತ್ತವೆ. ಆದ್ದರಿಂದ ಸರಿಯಾಗಿ ದಾಖಲಾದ ಪೂರ್ವಪ್ರತ್ಯಯವು ಇನ್ನೂ ಆಂತರಿಕ ಹೆಸರನ್ನು ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ, ಅಥವಾ ಮಾರ್ಗವು ಪರಿಪೂರ್ಣವಾಗಿ ಕಾಣುತ್ತಿರುವಾಗ ಏನನ್ನೂ ಪರಿಹರಿಸದ ಯಂತ್ರವನ್ನು ಉಂಟುಮಾಡಬಹುದು.
ಎರಡು ಆಯ್ಕೆಕಾರರು, ಒಂದು ಸಂಪರ್ಕ ಪ್ರಯತ್ನ
ಅಪ್ಲಿಕೇಶನ್ files.corp.example ಗೆ ಸಂಪರ್ಕಿಸಿದಾಗ, ಪ್ಯಾಕೆಟ್ ಇರುವ ಮೊದಲು ಎರಡು ಹುಡುಕಾಟಗಳು ನಡೆಯುತ್ತವೆ. ರಿಜಾಲ್ವರ್ ಯಾವ ಸರ್ವರ್ ಪ್ರಶ್ನೆಯನ್ನು ಪಡೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ಹುಡುಕಾಟ ಡೊಮೇನ್‌ಗಳು, ಪ್ರತಿ-ಲಿಂಕ್ ರೂಟಿಂಗ್ ಡೊಮೇನ್‌ಗಳು ಅಥವಾ ಸ್ಪಷ್ಟ ಪ್ರೊಫೈಲ್ ನಿಯಮ ಬಳಸಿ ನಿರ್ಧರಿಸುತ್ತದೆ. ನಂತರ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವು ಫಲಿತ ವಿಳಾಸ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ ದೀರ್ಘತಮ ಪೂರ್ವಪ್ರತ್ಯಯ ಹೊಂದಿಕೆ ಬಳಸಿ ನಿರ್ಧರಿಸುತ್ತದೆ.
ಆ ಎರಡು ನಿರ್ಧಾರಗಳನ್ನು ಯಾವುದೂ ಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ. ಖಾಸಗಿ ವಲಯವು 10.20.4.11 ನಿಂದ ಉತ್ತರಿಸಬಹುದು, ಆದರೆ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವು 10.20.0.0/16 ಅನ್ನು ಟನೆಲ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಸಂಪರ್ಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಯಾವುದನ್ನಾದರೂ ತಿರುಗಿಸಿ, ಅದು ಇನ್ನೊಂದರಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ: ಸರಿಯಾದ DNS ನೀತಿ ಜೊತೆಗೆ ಕಾಣೆಯಾದ ಮಾರ್ಗವು ಪರಿಹರಿಸಿದ ಹೆಸರು ಮತ್ತು ಸಮಯ ಮೀರಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಸರಿಯಾದ ಮಾರ್ಗ ಜೊತೆಗೆ ಸಾರ್ವಜನಿಕ ರಿಜಾಲ್ವರ್ ಸ್ವಚ್ಛವಾಗಿ ತಪ್ಪು ಸ್ಥಳಕ್ಕೆ ಮಾರ್ಗವಾಗುವ ವಿಳಾಸವನ್ನು ನೀಡುತ್ತದೆ.
ವಿಭಜಿತ ಹಾರಿಜನ್ DNS ಇದನ್ನು ಇನ್ನಷ್ಟು ತೀಕ್ಷ್ಣಗೊಳಿಸುತ್ತದೆ. ಅದೇ ಹೆಸರು ಆಂತರಿಕ ರಿಜಾಲ್ವರ್‌ನಿಂದ ಖಾಸಗಿ ವಿಳಾಸವನ್ನು ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ನತ್ತ ಮುಖ ಮಾಡಿದ ರಿಜಾಲ್ವರ್‌ನಿಂದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು, ಆದ್ದರಿಂದ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಮಾತ್ರ ದಾಖಲಿಸುವ ಟಿಪ್ಪಣಿ ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಯಾವ ವಿಳಾಸವನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಊಹಿಸಲಾರದು. ರಿಜಾಲ್ವರ್ನ ಮಾರ್ಗವನ್ನು ಬರೆಯಿರಿ, ಇಲ್ಲದಿದ್ದರೆ ವಿಳಾಸವು ಒಂದು ಊಹೆ.
ಕೇವಲ-ಮಾರ್ಗ ಟಿಪ್ಪಣಿ ಏನನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ
ಕೇವಲ-ಮಾರ್ಗ ದಾಖಲೆಯು ಸ್ಪ್ಲಿಟ್-ಟನೆಲ್ನ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ವೈಫಲ್ಯಕ್ಕೆ ನಿಷ್ಪ್ರಯೋಜಕ: ಹೆಸರುಗಳು. ಬಳಕೆದಾರರು ಆಂತರಿಕ ಜಾಲ ಲೋಡ್ ಆಗುತ್ತಿಲ್ಲ ಎಂದು ವರದಿ ಮಾಡುತ್ತಾರೆ, ಟನೆಲ್ ಆನ್ ಆಗಿದೆ ಮತ್ತು ಪೂರ್ವಪ್ರತ್ಯಯವಿದೆ. ಟಿಕೆಟ್ ತೆಗೆದುಕೊಳ್ಳುವವರಿಗೆ ಯಾವ ರಿಜಾಲ್ವರ್ ಉತ್ತರಿಸಬೇಕಿತ್ತು ಎಂಬ ದಾಖಲೆ ಇಲ್ಲ, ತಪ್ಪು ಹುಡುಕಾಟ ಪ್ರತ್ಯಯವನ್ನು ನಿರ್ಬಂಧಿಸಿದ ಸರ್ವರ್ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ ದಾರಿ ಇಲ್ಲ, ಮತ್ತು ಹೋಲಿಸಲು ಆಧಾರ ರೇಖೆ ಇಲ್ಲ.
ಎರಡನೇ ಬಿಟ್ಟುಬಿಡುವಿಕೆ ಅಪವಾದಗಳ ಪಟ್ಟಿ. ಸ್ಪ್ಲಿಟ್-ಟನೆಲ್ ವಿನ್ಯಾಸವು ಟನೆಲ್ನ ಹೊರಗೆ ಏನು ಉಳಿಯುತ್ತದೆ ಎಂಬುದರಿಂದಲೂ ಒಳಗೆ ಏನು ಬರುತ್ತದೆ ಎಂಬುದರಿಂದಲೂ ಸಮಾನವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಹೊರಗಿಟ್ಟ ಶ್ರೇಣಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಮೊದಲು ಮುರಿಯುತ್ತವೆ, ಏಕೆಂದರೆ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಸ್ಥಳೀಯ ಮಾರ್ಗ ಅಥವಾ ಕ್ಲೈಂಟ್-ಬದಿಯ ಫಿಲ್ಟರ್ ಪ್ರೊಫೈಲ್ ಮುಟ್ಟದೆ ಉದ್ದೇಶವನ್ನು ಮೀರಿಸಬಹುದು.
ಮೂರನೆಯದು ಟನೆಲ್ನ ದೂರದ ಬದಿ. ಕ್ಲೈಂಟ್ ಮಾರ್ಗವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ತಂತಿಗೆ ಹಾಕುತ್ತದೆ ಮಾತ್ರ; ಗೇಟ್ವೇ ಇನ್ನೂ ಅದನ್ನು ಮುಂದಕ್ಕೆ ರವಾನಿಸಬೇಕು ಮತ್ತು ಹಿಂತಿರುಗುವ ದಾರಿ ಹೊಂದಿರಬೇಕು. strongSwan ನ ರವಾನೆ ಮಾರ್ಗದರ್ಶಿ ಗೇಟ್ವೇಯಲ್ಲಿನ ರವಾನೆ ಮತ್ತು ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ವೈಶಿಷ್ಟ್ಯದ ಭಾಗ ಎಂದು, ಊಹಿಸಬಹುದಾದ ಪ್ಲಂಬಿಂಗ್ನ ಭಾಗವಲ್ಲ ಎಂದು ನೆನಪಿಸುತ್ತದೆ.
ಟಿಪ್ಪಣಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಕ್ಷೇತ್ರಗಳು
ಪ್ರತಿ ಹರಿವಿಗೆ ಒಂದು ಸಾಲು, ಮತ್ತು ಹರಿವು ಎಂದರೆ ಗಮ್ಯಸ್ಥಾನ ಜೊತೆಗೆ ಹೆಸರು ಜೊತೆಗೆ ಮಾಲೀಕ. ನೈಜ ಘಟನೆಯ ಸಂಪರ್ಕದಲ್ಲಿ ಉಳಿಯುವ ಕ್ಷೇತ್ರಗಳು ಇವು:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
"ಅದು ಎಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ" ಸಾಲನ್ನು ಜನರು ಬಿಟ್ಟುಬಿಡುತ್ತಾರೆ. ಸರ್ವರ್ ತಳ್ಳುವ ಪೂರ್ವಪ್ರತ್ಯಯ, ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ ಸೇರಿಸುವ ಮಾರ್ಗ ಮತ್ತು ಶೆಲ್ನಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದ ಮಾರ್ಗ ಅವುಗಳನ್ನು ಯಾರು ಬದಲಾಯಿಸಬಹುದು ಮತ್ತು ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಅವು ಉಳಿಯುತ್ತವೆಯೇ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನವಾಗಿವೆ. ಆ ಕ್ಷೇತ್ರವಿಲ್ಲದೆ ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ಮೂರರಲ್ಲಿ ಯಾವುದನ್ನು ನೋಡುತ್ತಿದ್ದಾರೆ ಎಂದು ಹೇಳಲಾರರು.
ಪ್ರತಿ ನಿಯಮಕ್ಕೆ ಒಂದು ಪರೀಕ್ಷೆ, ಪ್ರತಿ ಟನೆಲ್ಗೆ ಅಲ್ಲ
ಪ್ರತಿ ಸಾಲಿಗೆ ಎರಡು ನಿರುಪದ್ರವ ಪರಿಶೀಲನೆಗಳು ಬೇಕು: ಒಂದು ಮಾರ್ಗವನ್ನು ಅಭ್ಯಾಸ ಮಾಡುತ್ತದೆ, ಇನ್ನೊಂದು ಹೆಸರನ್ನು. ಮಾರ್ಗಕ್ಕಾಗಿ, ಟನೆಲ್ ದಾಟಲೇಬೇಕಾದ ಯಾವುದನ್ನಾದರೂ ಕೇಳಿ ಮತ್ತು ತಲುಪುವಿಕೆಯ ಬದಲು ಮಾರ್ಗವನ್ನು ದೃಢೀಕರಿಸಿ, ಉದಾಹರಣೆಗೆ tracert -d 10.20.4.11 Windows ನಲ್ಲಿ ಅಥವಾ ip route get 10.20.4.11 Linux ನಲ್ಲಿ. ಹೆಸರಿಗಾಗಿ, ಖಾಸಗಿ ಹೆಸರನ್ನು ಪ್ರಶ್ನಿಸಿ ಮತ್ತು ಯಾವ ಸರ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂದು ದಾಖಲಿಸಿ, ಟಿಪ್ಪಣಿ ಹೆಸರಿಸುವ ರಿಜಾಲ್ವರ್ ವಿರುದ್ಧ resolvectl query files.corp.example ಅಥವಾ dig files.corp.example ಬಳಸಿ.
ಋಣಾತ್ಮಕ ನಿರೀಕ್ಷೆಯನ್ನೂ ಸೇರಿಸಿ: ಟನೆಲ್ ಆಫ್ ಆಗಿರುವಾಗ ಏನಾಗಬೇಕು. VPN ಇಲ್ಲದೆ ಬ್ಲಾಕ್ ಸಕ್ರಿಯವಾಗಿರುವ Android ಅಥವಾ iOS ಸಾಧನದಲ್ಲಿನ ಹೊರಗಿಟ್ಟ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಸಂಪರ್ಕವೇ ಇಲ್ಲದಿರಬಹುದು, ಮತ್ತು ಡೆಸ್ಕ್ಟಾಪ್ ಕ್ಲೈಂಟ್ ಟನೆಲ್ ಮರುಸಂಪರ್ಕವಾಗುತ್ತಿರುವಾಗ ಅದೇ ಅಪ್ಲಿಕೇಶನ್ ಕೆಲಸ ಮಾಡಲು ಬಿಡಬಹುದು. ಉದ್ದೇಶಿತ ಉತ್ತರವನ್ನು ದಾಖಲಿಸುವುದು "VPN ನನ್ನ ಅಪ್ಲಿಕೇಶನ್ ಮುರಿಯಿತು" ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಬಹುದಾದ ಹೇಳಿಕೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ.
ದಾಖಲೆಯನ್ನು ಸಂರಚನೆಯೊಂದಿಗೆ ಇರಿಸಿ
ಟಿಪ್ಪಣಿಯನ್ನು ಅದು ವಿವರಿಸುವ ಪ್ರೊಫೈಲ್ ಪಕ್ಕದಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ಆ ಪ್ರೊಫೈಲ್ನೊಂದಿಗೆ ಆವೃತ್ತಿ ಮಾಡಿ. ಯಾರೂ ನವೀಕರಿಸದ ವಿಕಿಯಲ್ಲಿನ ದಾಖಲೆ ಗುಲ್ಲು; ತಳ್ಳಿದ ಮಾರ್ಗಗಳು ಮತ್ತು ರಿಜಾಲ್ವರ್ ನೀತಿಯೊಂದಿಗೆ ಅದೇ ಭಂಡಾರದಲ್ಲಿನ ಕೋಷ್ಟಕವನ್ನು ಅದೇ ಬದಲಾವಣೆಯಲ್ಲಿ ಪರಿಶೀಲಿಸಬಹುದು.
ಏನಾದರೂ ಮುರಿದಾಗ, ಇನ್ನೊಂದು ಅಪವಾದ ಸೇರಿಸುವ ಮೊದಲು ಅನ್ವಯಿಸಿದ ಮಾರ್ಗ ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ರಿಜಾಲ್ವರ್ ಅನ್ನು ದಾಖಲೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ. ಮೂರು ಸಾಮಾನ್ಯ ಕಾರಣಗಳಲ್ಲಿ ಎರಡು — ಹಳೆಯ ಹೆಸರಿನ ಸ್ಥಳ ನಿಯಮ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ನೀತಿಯ ಹೊರಗಿನ ಸಹಾಯಕ ಪ್ರಕ್ರಿಯೆ — ನಿಖರವಾಗಿ VPN ದೋಷದಂತೆ ಕಾಣುತ್ತವೆ ಮತ್ತು ಟಿಪ್ಪಣಿ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಮಾತ್ರ ಪಟ್ಟಿ ಮಾಡಿದರೆ ಅಗೋಚರವಾಗಿರುತ್ತವೆ.
ಟಿಪ್ಪಣಿಯನ್ನು ಪೂರ್ಣ ಎಂದು ಹೇಳುವ ಮೊದಲು, ಅದು ಇವುಗಳಿಗೆ ಲಿಖಿತವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ: ಯಾವ ಪೂರ್ವಪ್ರತ್ಯಯ, ಯಾವ ವಿಳಾಸ ಕುಟುಂಬಕ್ಕೆ; ಯಾವ ಖಾಸಗಿ ಹೆಸರಿನ ಸ್ಥಳ, ಯಾವ ರಿಜಾಲ್ವರ್ ಉತ್ತರಿಸಿದೆ; ಯಾವ ಹೆಸರುಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಾರ್ವಜನಿಕವಾಗಿ ಉಳಿಯುತ್ತವೆ; ಪ್ರತಿ ನಿಯಮ ಎಲ್ಲಿಂದ ಸಂರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಅದರ ಮಾಲೀಕರು ಯಾರು; ಮತ್ತು ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುವ ಒಂದು ಆದೇಶ ಮತ್ತು ಹೆಸರನ್ನು ಸಾಬೀತುಪಡಿಸುವ ಒಂದು ಆದೇಶ. ಇವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಕಾಣೆಯಾದರೆ, ಮುಂದಿನ ಘಟನೆ ಶೂನ್ಯದಿಂದ ರೋಗನಿರ್ಣಯವಾಗುತ್ತದೆ.