ಬೇರ್ಪಡಿಸಿದ ಟನಲ್‌ನ ಮಾರ್ಗಗಳು ಒಂದರ ಮೇಲೊಂದು ಬಂದಾಗ: ಯಾವ ಪ್ರಿಫಿಕ್ಸ್ ಗೆಲ್ಲುತ್ತದೆ
ಉದ್ದವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಹೊಂದಿಕೆ, ಮೆಟ್ರಿಕ್ ಮತ್ತು ನೀತಿ ನಿಯಮಗಳು ಒಂದರ ಮೇಲೊಂದು ಬರುವ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಯಾವ ಟನಲ್ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಮೊದಲು ಮೂಲ ವಿಳಾಸ ಮತ್ತು ಬಗೆಹರಿಸಿದ ಹೆಸರನ್ನು ಪರಿಶೀಲಿಸಿ.
ಎರಡು ಬೇರ್ಪಡಿಸಿದ ಟನಲ್ ಪ್ರೊಫೈಲ್‌ಗಳು, ಎರಡು ಖಾಸಗಿ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಮತ್ತು ಎರಡೂ ಹಕ್ಕು ಸಲ್ಲಿಸುವ ಒಂದು ಹೋಸ್ಟ್. ಲಕ್ಷಣ ಅಪರೂಪವಾಗಿ ಸ್ವಚ್ಛ ವೈಫಲ್ಯವಾಗಿರುತ್ತದೆ: ಒಂದು ಸೇವೆ ಸೋಮವಾರ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಎರಡನೇ ಕ್ಲೈಂಟ್ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಸಮಯ ಮೀರುತ್ತದೆ, ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಿದ ನಂತರ ಮತ್ತೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನೀವು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಿದ ಕ್ರಮ ಫಲಿತಾಂಶವನ್ನು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ, ಕ್ಲೈಂಟ್ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿನ ಸಾಲುಗಳ ಕ್ರಮವೂ ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಈ ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ, ಮತ್ತು ಹೊಂದಿಕೆಯಾಗದ ಮೊದಲ ಪರಿಶೀಲನೆಯಲ್ಲೇ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಹಿಂದಿನವು ನಿಜವಾದಾಗ ಮಾತ್ರ ಮುಂದಿನವುಗಳಿಗೆ ಅರ್ಥವಿದೆ.
1. ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಮೂಲವನ್ನು ಬರೆಯಿರಿ
ವಿಫಲವಾಗುವ ವಿನಂತಿ ಹೋಗುವ ನಿಖರ ವಿಳಾಸದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಹೋಸ್ಟ್ ಹೆಸರಿನಿಂದ ಅಲ್ಲ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರಿನಿಂದ ಅಲ್ಲ. ಹೆಸರನ್ನು ಒಮ್ಮೆ ಬಗೆಹರಿಸಿ, ಪ್ರತಿ ಉತ್ತರವನ್ನು ದಾಖಲಿಸಿ ಮತ್ತು ವಿಫಲವಾಗುವ ಹರಿವು ನಿಜವಾಗಿ ಬಳಸುವ ಉತ್ತರವನ್ನು ಆರಿಸಿ. ನಂತರ ಅದೇ ಹರಿವಿನ ಸ್ಥಳೀಯ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಮೂಲ ವಿಳಾಸವು ಯಾವ ನೀತಿ ನಿಯಮ ಹೊಂದುತ್ತದೆ ಮತ್ತು ಹಾಗೆಯೇ ಯಾವ ಕೋಷ್ಟಕ ನೋಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸಬಹುದು.
ಹಲವು A ದಾಖಲೆಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಹೋಗುವ ವಿನಂತಿ ವಿಫಲವಾಗಬಹುದು ಆದರೆ ಪಕ್ಕದ ವಿಳಾಸ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಇದು ಅಸ್ಥಿರ ಟನಲ್‌ನಂತೆ ಕಾಣುತ್ತದೆ ಆದರೆ ವಾಸ್ತವವಾಗಿ ಎರಡು ಬೇರೆ ಮಾರ್ಗಗಳು. ಗಮ್ಯಸ್ಥಾನವು ಹಲವು ಉತ್ತರಗಳಿರುವ ಹೆಸರಾಗಿದ್ದರೆ, ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಪ್ರತಿ ಉತ್ತರವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ.
2. ಕರ್ನೆಲ್‌ಗೆ ಯಾವ ಮಾರ್ಗವನ್ನು ಆರಿಸಿತು ಎಂದು ಕೇಳಿ
ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ಓದಿ ಉತ್ತರವನ್ನು ಊಹಿಸಬೇಡಿ. ಸ್ಟಾಕ್ ಕೇಳುವ ಅದೇ ಪ್ರಶ್ನೆಯನ್ನು ಅದೇ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಕೇಳಿ: Linux ನಲ್ಲಿ ip route get 10.20.4.10 from 10.8.0.2 ಅಥವಾ PowerShell ನಲ್ಲಿ Find-NetRoute -RemoteIPAddress 10.20.4.10. ಔಟ್‌ಪುಟ್ ನಿಜವಾಗಿ ಬಳಸಲಾಗುವ ಮಾರ್ಗವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಕೋಷ್ಟಕವನ್ನು ಓದುವಾಗ ನೀವು ನಿರೀಕ್ಷಿಸಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಬೇರೆಯಾಗಿರುತ್ತದೆ.
ಹೊಂದುವ ಮಾರ್ಗಗಳ ನಡುವೆ ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಗೆಲ್ಲುತ್ತದೆ: ಎರಡರಲ್ಲೂ ಇರುವ ವಿಳಾಸಕ್ಕೆ /24, /16 ಅನ್ನು ಸೋಲಿಸುತ್ತದೆ. ಒಂದೇ ಉದ್ದದ ಹೊಂದಿಕೆಗಳ ನಡುವೆ ಕಡಿಮೆ ಮೆಟ್ರಿಕ್ ಗೆಲ್ಲುತ್ತದೆ, ಮತ್ತು ಆಫ್ ಆಗಿರುವ ಲಿಂಕ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾದ ಮಾರ್ಗವನ್ನು ಬಿಟ್ಟುಬಿಡಲಾಗುತ್ತದೆ. ಒಂದೇ /24 ಅನ್ನು ಒಂದೇ ಮೆಟ್ರಿಕ್‌ನೊಂದಿಗೆ ತಳ್ಳುವ ಎರಡು ಟನಲ್‌ಗಳು ಬೇರೆ ಸಂದರ್ಭ: ಕರ್ನೆಲ್ ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಇಟ್ಟುಕೊಂಡು ಅವುಗಳ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಫಲಿತಾಂಶವು ಕ್ಲೈಂಟ್‌ಗಳು ಸಂಪರ್ಕಿಸಿದ ಕ್ರಮವನ್ನು ಅನುಸರಿಸುವ ಬದಲು ಬದಲಾಗುತ್ತಿರಬಹುದು. ಸೋಮವಾರ-ಕೆಲಸ-ಮಾಡುತ್ತದೆ-ಮಂಗಳವಾರ-ವಿಫಲವಾಗುತ್ತದೆ ಎಂಬ ಮಾದರಿಯನ್ನು ಸೃಷ್ಟಿಸುವುದು ಈ ಪರಿಸ್ಥಿತಿಯೇ, ಮತ್ತು ಬೇರೆ ಕ್ರಮದಲ್ಲಿ ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವುದು ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.
3. ನೀತಿ ನಿಯಮವು ಹುಡುಕಾಟವನ್ನು ಬೇರೆಡೆಗೆ ತಿರುಗಿಸಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ
ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ನೋಡುವ ಮೊದಲು, ಕರ್ನೆಲ್ ತನ್ನ ನೀತಿ ನಿಯಮಗಳ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ. ಒಂದು ನಿಯಮವು ನಿರ್ದಿಷ್ಟ ಮೂಲ, ಬಳಕೆದಾರ ಅಥವಾ ಫೈರ್‌ವಾಲ್ ಗುರುತಿನಿಂದ ಬರುವ ಸಂಚಾರವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ಕೋಷ್ಟಕಕ್ಕೆ ಕಳುಹಿಸಬಹುದು, ಆದ್ದರಿಂದ ಮುಖ್ಯ ಕೋಷ್ಟಕದ ಗೆಲ್ಲುವ ಪ್ರಿಫಿಕ್ಸ್ ಆ ಹರಿವಿಗೆ ಎಂದಿಗೂ ನೋಡದೇ ಇರಬಹುದು. ip rule show ಅವುಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಕ್ರಮದಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ip route show table 100 ಆಯ್ಕೆಮಾಡಿದ ಕೋಷ್ಟಕದಲ್ಲಿ ನಿಜವಾಗಿ ಏನಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ.
ಇಲ್ಲಿ ಎರಡು ಬಲೆಗಳಿವೆ. ಖಾಲಿ ಕೋಷ್ಟಕಕ್ಕೆ ತೋರಿಸುವ ನಿಯಮವು ಮುಂದಿನ ನಿಯಮಕ್ಕೆ ಬೀಳುವ ಹುಡುಕಾಟವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಯಮವು ಏನೂ ಮಾಡದಂತೆ ಕಾಣುತ್ತದೆ. ಇನ್ನೊಂದು ಆದ್ಯತೆಯ ಸಂಖ್ಯೆಯೇ: ನಿಯಮಗಳನ್ನು ಏರಿಕೆ ಕ್ರಮದಲ್ಲಿ ಓದಲಾಗುತ್ತದೆ, ಮತ್ತು ಒಳಗೊಂಡ ಮೌಲ್ಯಗಳು 0 local, 32766 main ಮತ್ತು 32767 default. 32767 ಕ್ಕಿಂತ ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ನಿಯಮವನ್ನು ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುವ ಡೀಫಾಲ್ಟ್ ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು ನೋಡಲಾಗುತ್ತದೆ. 32767 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಂಖ್ಯೆಯ ನಿಯಮವು ಅದರ ಹಿಂದೆ ಇರುತ್ತದೆ ಮತ್ತು ಹಿಂದಿನ ಯಾವ ಕೋಷ್ಟಕವೂ ಉತ್ತರಿಸದಿದ್ದಾಗ ಮಾತ್ರ ಅದನ್ನು ತಲುಪಬಹುದು, ಇದನ್ನು main ನಲ್ಲಿನ ಸಾಮಾನ್ಯ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ತಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅದನ್ನು ಎಂದಿಗೂ ತಲುಪಲಾಗದು ಮತ್ತು ಸ್ಥಾಪಿಸಿದಂತೆ ಕಾಣುತ್ತಿದ್ದರೂ ಸದ್ದಿಲ್ಲದೆ ಏನೂ ಮಾಡುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ ನಿಯಮ ಮತ್ತು ಮಾರ್ಗ ಎರಡನ್ನೂ ಬರೆದಿದ್ದರೆ ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಮತ್ತೆ ಬರೆದ ಪ್ರೊಫೈಲ್ ಬೇರೆ ಆದ್ಯತೆಯ ಎರಡನೇ ನಿಯಮವನ್ನು ಸೇರಿಸಬಹುದು.
4. ಮಾರ್ಗ ಸಮಾನತೆಯನ್ನು ನಕಲಿ ವಿಳಾಸ ಯೋಜನೆಯಿಂದ ಬೇರ್ಪಡಿಸಿ
ಕೆಲವೊಮ್ಮೆ ಪ್ರಿಫಿಕ್ಸ್ ಸಮಸ್ಯೆಯೇ ಅಲ್ಲ. ಎರಡೂ ಸ್ಥಳಗಳು 192.168.1.0/24 ಬಳಸುತ್ತಿದ್ದರೆ ಅದೇ ವಿಳಾಸ ಎರಡು ಬೇರೆ ಹೋಸ್ಟ್‌ಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವ ಮಾರ್ಗವೂ ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾರದು. ಎರಡು ಉತ್ತರಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಹೋಸ್ಟ್ ಮಾರ್ಗವು ಇನ್ನೊಂದು ಸ್ಥಳವು ಅದೇ ಹೆಸರಿಗೆ ಉತ್ತರಿಸುವವರೆಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ನಂತರ ಅಪವಾದವು ಸದ್ದಿಲ್ಲದೆ ತಾನೇ ದೋಷವಾಗುತ್ತದೆ.
ಸೂಚನೆ ಎಂದರೆ ಗಮ್ಯ ವಿಳಾಸವು ಎರಡೂ ಮಾರ್ಗಗಳಲ್ಲಿ ಒಂದೇ ಆಗಿದ್ದು ಕೇವಲ ಉದ್ದೇಶಿತ ಮಾಲೀಕ ಮಾತ್ರ ಬೇರೆಯಾಗಿರುವುದು. ಇದು ವಿಳಾಸ ಯೋಜನೆಯ ನಿರ್ಧಾರ, ಮಾರ್ಗ ಬದಲಾವಣೆ ಅಲ್ಲ: ಒಂದು ಬದಿಯನ್ನು ಮತ್ತೆ ಸಂಖ್ಯೆ ಮಾಡಿ, ಒಂದು ಬದಿಯನ್ನು ಅನುವಾದಿಸುವ ಗೇಟ್‌ವೇ ಹಿಂದೆ ಇರಿಸಿ, ಅಥವಾ ತನ್ನ ಹೆಸರುಗಳನ್ನು ತಾನೇ ಬಗೆಹರಿಸುವ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಎರಡನೇ ಸ್ಥಳವನ್ನು ತಲುಪಿ. ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಇಳಿಸುವುದು ಅಥವಾ ಹೋಸ್ಟ್ ಅಪವಾದಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುವುದು ಘರ್ಷಣೆಯನ್ನು ಬೇರೆಡೆಗೆ ಸರಿಸುತ್ತದೆ ಅಷ್ಟೇ.
5. ಬಗೆಹರಿಸುವವನು ಮಾರ್ಗದೊಂದಿಗೆ ಒಪ್ಪುತ್ತಾನೆ ಎಂದು ಖಚಿತಪಡಿಸಿ
ತಪ್ಪು ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಬಗೆಹರಿಯುವ ಹೆಸರು ಮಾರ್ಗ ಘರ್ಷಣೆಯ ಎಲ್ಲಾ ಲಕ್ಷಣಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಒಂದೂ ಕಾರಣವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಹೋಸ್ಟ್ ಪಡೆಯುವ ಉತ್ತರವನ್ನು ಗಮ್ಯಸ್ಥಾನ ನಿಜವಾಗಿ ಬಳಸುವ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ, ಮತ್ತು ಯಾವ ಬಗೆಹರಿಸುವವನು ಉತ್ತರಿಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ. ಟನಲ್ ಒಂದು ಬಗೆಹರಿಸುವವನನ್ನು ತಳ್ಳಿದರೆ, ಟನಲ್ ಬಳಸುವ ಹರಿವುಗಳಿಗೆ ಕ್ಲೈಂಟ್ ಅದನ್ನು ಸ್ಥಾಪಿಸಬೇಕು; ಇಲ್ಲದಿದ್ದರೆ ಹೋಸ್ಟ್ ಸ್ಥಳೀಯ ಬಗೆಹರಿಸುವವನನ್ನೇ ಕೇಳುತ್ತಿರುತ್ತದೆ, ಅದು ಹುಡುಕಾಟ ಡೊಮೇನ್ ಅಥವಾ ಕ್ಯಾಶ್ ಮಾಡಿದ ದಾಖಲೆಯಿಂದ ಉತ್ತರಿಸಬಹುದು.
ಬಗೆಹರಿಸುವವನನ್ನು ನೇರವಾಗಿ ಕೇಳಿ ಮತ್ತು ಉತ್ತರಿಸಿದ ಸರ್ವರ್ ಅನ್ನು ದಾಖಲಿಸಿ. ಸಣ್ಣ TTL ಇರುವ ಕ್ಯಾಶ್ ಉತ್ತರವು, ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಮೊದಲ ವಿನಂತಿ ಐದನೆಯದಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿ ವರ್ತಿಸುವುದಕ್ಕೆ ಕಾರಣವನ್ನೂ ವಿವರಿಸಬಹುದು.
6. ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ಅನ್ವಯಿಸಿದ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಎರಡೂ ಹರಿವುಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
ತಿದ್ದುಪಡಿಯ ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಪ್ರೊಫೈಲ್ ಸಂಪಾದಕವನ್ನು ನಂಬುವ ಬದಲು ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಏನನ್ನು ಸ್ಥಾಪಿಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ. ನಿಯಮಗಳು, ಕೋಷ್ಟಕಗಳು ಮತ್ತು ಅವುಗಳಿಂದ ಬರುವ ip route get ಉತ್ತರವನ್ನು ಮತ್ತೆ ಓದಿ. ಎರಡನೇ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸುವಾಗ ತನ್ನ ಮಾರ್ಗವನ್ನು ಮತ್ತೆ ಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು ಘರ್ಷಣೆಯನ್ನು ಮತ್ತೆ ಸೃಷ್ಟಿಸಬಹುದು, ಆದ್ದರಿಂದ ಸ್ಥಿತಿ ಪರಿಶೀಲನೆ ಕೊನೆಯ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ನಡೆಯಬೇಕು, ಅದಕ್ಕಿಂತ ಮೊದಲು ಅಲ್ಲ.
ಒಂದಲ್ಲ, ಎರಡು ಹರಿವುಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ: ಹಿಂದೆ ವಿಫಲವಾಗುತ್ತಿದ್ದ ವಿನಂತಿ, ಮತ್ತು ಇನ್ನೊಂದು ಟನಲ್ ಬಳಸಬೇಕಾದ ಸಂಪನ್ಮೂಲ. ಎಲ್ಲಾ ಖಾಸಗಿ ಸಂಚಾರವನ್ನು ಒಂದೇ ಸಂಪರ್ಕಕ್ಕೆ ಸರಿಸಿದರೆ ಮೊದಲ ಪರೀಕ್ಷೆ ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ ಆದರೆ ಎರಡನೆಯದು ಒಡೆಯುತ್ತದೆ, ಇದನ್ನು ಜೋಡಿ ಪರೀಕ್ಷೆ ಮಾತ್ರ ಹಿಡಿಯುತ್ತದೆ. ನೀವು ಉಳಿಸಿಕೊಳ್ಳುವ ಪ್ರತಿ ಅಪವಾದವನ್ನೂ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಕಾರಣದೊಂದಿಗೆ ದಾಖಲಿಸಿ, ಇದರಿಂದ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಉದ್ದೇಶಪೂರ್ವಕ ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನು ಉಳಿದ ಒಂದರಿಂದ ಪ್ರತ್ಯೇಕಿಸಬಹುದು.