ಸೈಟ್-ಟು-ಸೈಟ್ VPN ಗೆ ಎರಡನೇ ಸಬ್ನೆಟ್ ಸೇರಿಸುವುದು: ಎರಡು ಮಾರ್ಗ
ನೀತಿ-ಆಧಾರಿತ ಟನೆಲ್‌ಗಳಿಗೆ ಎರಡೂ ಕಡೆ ಹೊಂದುವ ಸೆಲೆಕ್ಟರ್‌ಗಳು ಬೇಕು; ಮಾರ್ಗ-ಆಧಾರಿತವಕ್ಕೆ ಮಾರ್ಗ ಬೇಕು. ಸರಿಯಾದ ಮಾರ್ಗ ಆರಿಸಿ ಮತ್ತು ಮೊದಲು ಹಿಂತಿರುಗು ಮಾರ್ಗ ಸರಿಪಡಿಸಿ.
ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಸೈಟ್-ಟು-ಸೈಟ್ ಟನೆಲ್‌ಗೆ ಎರಡನೇ ಸಬ್ನೆಟ್ ಸೇರಿಸಲು ಒಂದು ವಿನ್ಯಾಸದಲ್ಲಿ ಐದು ನಿಮಿಷ, ಇನ್ನೊಂದರಲ್ಲಿ ಬಹುತೇಕ ಮಧ್ಯಾಹ್ನವಿಡೀ ಬೇಕು. ಟನೆಲ್ ನೀವು ಹೆಸರಿಸುವ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳಿಗೆ ಮಾರ್ಗಗಳನ್ನು ಅಳವಡಿಸಿದಾಗ, ನೀವು ಒಂದು ಮಾರ್ಗ ಸೇರಿಸುತ್ತೀರಿ ಮತ್ತು ಸಂಚಾರ ಅದನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಅದು ಒಂದು ಸ್ಥಿರ ಸೆಲೆಕ್ಟರ್ ಜೋಡಿಯನ್ನು ಮಾತುಕತೆ ಮಾಡಿದಾಗ, ಎರಡೂ ಕಡೆ ಹೊಂದುವ ಜೋಡಿಗೆ ಒಪ್ಪುವವರೆಗೆ ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್ ಸಂರಕ್ಷಣೆಯಿಲ್ಲದೆ ಉಳಿಯುತ್ತದೆ. ಮೂರು ಅಂಶಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ: ಪ್ರತಿ ಕಡೆಯ ಸಂರಚನೆ ನಿಜವಾಗಿ ಏನನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮಾತುಕತೆಯಾದ ಸಂಚಾರ ಚಿಕ್ಕ ಹೊಂದುವ ಜೋಡಿಗೆ ಸಂಕುಚಿತವಾಗುತ್ತದೆಯೇ, ಮತ್ತು ಹೊಸ ಶ್ರೇಣಿಯ ಹಿಂತಿರುಗು ಮಾರ್ಗ ಯಾರದ್ದು.
ಸ್ಥಿತಿ ಲೇಬಲ್ ಅಲ್ಲ, ಕರ್ನೆಲ್ ಓದಿ
ಸಂಪರ್ಕ ಎಂದು ವರದಿ ಮಾಡುವ ಟನೆಲ್ ಕನಿಷ್ಠ ಒಂದು ಚೈಲ್ಡ್ ಸಂಘವನ್ನು ಅಳವಡಿಸಿದೆ, ಆದರೆ ನೀವು ಭಾವಿಸುವುದಲ್ಲ. Linux ನಲ್ಲಿ ಕರ್ನೆಲ್ ಏನು ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ: ip xfrm policy ಸೆಲೆಕ್ಟರ್ ಜೋಡಿಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ ಮತ್ತು swanctl --list-sas (ಅಥವಾ ಹಳೆಯ ipsec statusall) ಎರಡೂ ಕಡೆ ಒಪ್ಪಿಕೊಂಡದ್ದನ್ನು ಪ್ರತಿ ದಿಕ್ಕಿನ ಸಂಚಾರ ಸೆಲೆಕ್ಟರ್‌ಗಳೊಂದಿಗೆ ತೋರಿಸುತ್ತದೆ. ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್ ಎರಡರಲ್ಲೂ ಇಲ್ಲದಿದ್ದರೆ, ಸಂರಚನಾ ಕಡತ ಏನೇ ಹೇಳಲಿ, ಅದು ಸಂರಕ್ಷಣೆಯಿಲ್ಲ.
ಇದನ್ನು ಮಾರ್ಗ ಕೋಷ್ಟಕದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಮಾರ್ಗ-ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಟನೆಲ್ ಸಾಧನವು ಸಂರಕ್ಷಿತ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳ ಮುಂದಿನ ಹಾಪ್. ನೀತಿ-ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ದೂರದ ಸಬ್ನೆಟ್‌ಗೆ ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗ ಇರುವುದಿಲ್ಲ, ಕೇವಲ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗ, ಏಕೆಂದರೆ ಸಂಚಾರವನ್ನು ಕೋಷ್ಟಕವಲ್ಲ, ನೀತಿ ಆರಿಸುತ್ತದೆ.
ನೀತಿ-ಆಧಾರಿತ ಟನೆಲ್: ಎರಡೂ ಕಡೆ ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್ ಪಟ್ಟಿ ಮಾಡಬೇಕು
strongSwan ಪರಿಭಾಷೆಯಲ್ಲಿ ಸೆಲೆಕ್ಟರ್ ಚೈಲ್ಡ್ ಸಂರಚನೆಯ local_ts ಮತ್ತು remote_ts ನಲ್ಲಿದೆ, leftsubnet ಮತ್ತು rightsubnet ರ ಉತ್ತರಾಧಿಕಾರಿಗಳು. ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್ ಎರಡೂ ಕಡೆ ಕನ್ನಡಿಯಂತೆ ಕಾಣಬೇಕು: ಸೈಟ್ A ಸ್ಥಳೀಯ ಎಂದು ಕರೆಯುವುದನ್ನು ಸೈಟ್ B ದೂರದ ಎಂದು ಕರೆಯುತ್ತದೆ. ಅಸಮಾನತೆ ಸ್ವಚ್ಛ ದೋಷವನ್ನು ಅಪರೂಪಕ್ಕೆ ನೀಡುತ್ತದೆ. ಕಡೆಗಳು ಛೇದದವರೆಗೆ ಸಂಕುಚಿತವಾಗುತ್ತವೆ, ಹಳೆಯ ಪ್ರಿಫಿಕ್ಸ್ ಕೆಲಸ ಮುಂದುವರಿಸುತ್ತದೆ ಮತ್ತು ಹೊಸದು ಮಾತ್ರ ಮೌನವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense ಅಥವಾ OPNsense ನಲ್ಲಿ ಇದರರ್ಥ ಹೊಸ ಸ್ಥಳೀಯ ಸಬ್ನೆಟ್ ಅನ್ನು ಹೊಸ ದೂರದ ಸಬ್ನೆಟ್‌ಗೆ ಜೋಡಿಸುವ ಎರಡನೇ Phase 2 ನಮೂದು, ನಂತರ ಅನ್ವಯ. ಹಳೆಯ ನಮೂದನ್ನು ಇಡಿ; ಬದಲಾಯಿಸುವುದು ಮೂಲ ಸಬ್ನೆಟ್ ಸೇರಿಸುವ ಬದಲು ಸರಿಸುತ್ತದೆ. ಇರುವ Phase 2 ಈಗಾಗಲೇ 0.0.0.0/0 ನಂತಹ ಸೂಪರ್‌ನೆಟ್ ಅಥವಾ ಸಂಕ್ಷಿಪ್ತ ಶ್ರೇಣಿಯನ್ನು ಆವರಿಸಿದ್ದರೆ, ಅದರ ಪಕ್ಕದಲ್ಲಿ ಸಣ್ಣ ನಮೂದು ಸೇರಿಸಬೇಡಿ: ಅತಿವ್ಯಾಪಿಸುವ ಸೆಲೆಕ್ಟರ್‌ಗಳು ಸ್ಪರ್ಧಾತ್ಮಕ ನೀತಿಗಳನ್ನು ಅಳವಡಿಸುತ್ತವೆ ಮತ್ತು ಮೌಲ್ಯಮಾಪನ ಕ್ರಮವು ಗೆಲ್ಲುವವರನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
IKEv1 ಪ್ರತಿ ಸಬ್ನೆಟ್ ಜೋಡಿಯನ್ನು ತನ್ನದೇ Phase 2 ಮಾಡುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ವಿನಿಮಯಕ್ಕೆ ಒಂದು ಜೋಡಿ ತೆಗೆದುಕೊಳ್ಳುವ ಕಡೆ ಉಳಿದವನ್ನು ಬಿಡುತ್ತದೆ. IKEv2 ಒಂದು ಚೈಲ್ಡ್‌ನಲ್ಲಿ ಹಲವು ಸೆಲೆಕ್ಟರ್ ಜೋಡಿಗಳನ್ನು ಒಯ್ಯಬಹುದು, ಆದರೆ ಎರಡೂ ಅನುಷ್ಠಾನಗಳು ಒಪ್ಪಿದರೆ ಮಾತ್ರ. swanctl --list-sas ನ ಪಟ್ಟಿಯೇ ಸತ್ಯ; ನೀವು ಬರೆದದ್ದು ಕೇಳಿಕೆ.
ಮಾರ್ಗ-ಆಧಾರಿತ ಟನೆಲ್: ಮಾರ್ಗವೇ ನೀತಿ
XFRM ಇಂಟರ್‌ಫೇಸ್ ಅಥವಾ VTI ಸಾಧನವು ಮಾರ್ಗ ಕೋಷ್ಟಕದ ಪ್ರಕಾರ ಸಂಚಾರ ಒಯ್ಯುತ್ತದೆ. ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಎರಡೂ ಸೈಟ್‌ಗಳಲ್ಲಿ ಸಾಧನದ ಕಡೆ ತೋರಿಸಿದರೆ, ಇಂಟರ್‌ಫೇಸ್ ಪರಿವರ್ತನೆಗೆ ಬದ್ಧವಾದ ಸ್ಥಿತಿ ಅನ್ವಯವಾಗುತ್ತದೆ. ಸಿಂಕ್ ಮಾಡಲು ಸೆಲೆಕ್ಟರ್ ಜೋಡಿ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಸಬ್ನೆಟ್‌ಗಳು ಹೆಚ್ಚಾದಂತೆ ಈ ವಿನ್ಯಾಸ ಚೆನ್ನಾಗಿ ಸ್ಕೇಲ್ ಆಗುತ್ತದೆ. strongSwan ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗದರ್ಶಿ ಕರ್ನೆಲ್ ಭಾಗವನ್ನು ವಿವರವಾಗಿ ಹೇಳುತ್ತದೆ.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard ಮುಂದೆ ಹೋಗುತ್ತದೆ. AllowedIPs ಒಂದೇ ಸಮಯದಲ್ಲಿ ಕ್ರಿಪ್ಟೋ ಅನುಮತಿ ಪಟ್ಟಿ ಮತ್ತು wg-quick ಮೂಲಕ ಮಾರ್ಗ ಕೋಷ್ಟಕದ ನಮೂದು. ಒಂದು ಕಡೆ ಮಾತ್ರ ಪ್ರಿಫಿಕ್ಸ್ ಸೇರಿಸಿದರೆ ಹ್ಯಾಂಡ್‌ಶೇಕ್, ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಮತ್ತು ಮೌನ ಸಿಗುತ್ತದೆ, ಏಕೆಂದರೆ ದೂರದ ಕಡೆ ಮೂಲವು ತನ್ನ ಪಟ್ಟಿಯಲ್ಲಿಲ್ಲದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬಿಡುತ್ತದೆ. wg set ರೂಪವು ಇಡೀ ಪಟ್ಟಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೊದಲೇ ಕೆಲಸ ಮಾಡಿದ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಮತ್ತೆ ಬರೆಯಿರಿ, ಇಲ್ಲದಿದ್ದರೆ ಅವನ್ನು ಕತ್ತರಿಸುತ್ತೀರಿ:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0wg-quick ಬದಲು wg set ಬಳಸಿದಾಗ ಆ ಎರಡನೇ ಆಜ್ಞೆ ಐಚ್ಛಿಕವಲ್ಲ. ಕರ್ನೆಲ್ ಹೊಸ ಪಟ್ಟಿಯನ್ನು ತಕ್ಷಣ ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆದರೆ ಯಾರೂ ಅದಕ್ಕೆ ಮಾರ್ಗ ಸೇರಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸ್ಥಳೀಯವಾಗಿ ರಚಿಸಿದ ಸಂಚಾರ ಇನ್ನೂ ಡಿಫಾಲ್ಟ್ ಗೇಟ್‌ವೇ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ. ಹೊಸ WireGuard ಸಬ್ನೆಟ್ ಟನೆಲ್ ಹೋಸ್ಟ್‌ನಿಂದ ಕೆಲಸ ಮಾಡಿ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಿಂದ ಮಾಡದಿರಲು ಇದೇ ಸಾಮಾನ್ಯ ಕಾರಣ.
ಹಿಂತಿರುಗು ಮಾರ್ಗ ಟನೆಲ್‌ಗಿಂತ ಹೆಚ್ಚು ಬಾರಿ ವಿಫಲವಾಗುತ್ತದೆ
ಹೊಸ ದೂರದ ಸಬ್ನೆಟ್‌ನ ಹೋಸ್ಟ್‌ಗಳು ಉತ್ತರಗಳನ್ನು VPN ಗೇಟ್‌ವೇ ಮೂಲಕ ಕಳುಹಿಸಬೇಕು. ಆ ಗೇಟ್‌ವೇ ಅವರ ಡಿಫಾಲ್ಟ್ ರೂಟರ್ ಅಲ್ಲದಿದ್ದಾಗ, ಉತ್ತರ LAN ರೂಟರ್‌ಗೆ ಹೋಗುತ್ತದೆ, ಅದು ಅದನ್ನು ಬಿಡುತ್ತದೆ ಅಥವಾ ಖಾಸಗಿ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಇಂಟರ್ನೆಟ್‌ಗೆ ರವಾನಿಸುತ್ತದೆ. ಗೇಟ್‌ವೇಯಿಂದ ಅಲ್ಲ, ದೂರದ ಕಡೆಯ ಹೋಸ್ಟ್‌ನಿಂದ ಪರೀಕ್ಷಿಸಿ: Linux ನಲ್ಲಿ ip route get 10.30.20.15 ಅಥವಾ PowerShell ನಲ್ಲಿ Find-NetRoute -RemoteIPAddress 10.30.20.15 ಹೋಸ್ಟ್ ನಿಜವಾಗಿ ಬಳಸುವ ಮುಂದಿನ ಹಾಪ್ ತೋರಿಸುತ್ತದೆ. ಉತ್ತರ ಟನೆಲ್ ಅಂತ್ಯಬಿಂದು ಅಲ್ಲದಿದ್ದರೆ, ಅಲ್ಲಿ ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಸ್ಥಿರ ಮಾರ್ಗ ಸೇರಿಸಿ.
ಹಿಂತಿರುಗು ಮಾರ್ಗ ಇಲ್ಲದ ಸೈಟ್‌ನಲ್ಲಿ ಮೂಲ NAT ಕಾನೂನುಬದ್ಧ ಪರ್ಯಾಯ ಮತ್ತು ಹಲವು hub-and-spoke ನಿಯೋಜನೆಗಳು ಪ್ರತಿ ಸರ್ವರ್ ಮುಟ್ಟದಿರುವ ದಾರಿ. ಗಮ್ಯಸ್ಥಾನದ ಕಡೆಯ ಗೇಟ್‌ವೇಯಲ್ಲೂ ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಅದನ್ನು ಅನ್ವಯಿಸಿ:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEವೆಚ್ಚ ನಿಜ. ದೂರದ ಲಾಗ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಮೂಲ ವಿಳಾಸಗಳನ್ನು ತೋರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ ಮತ್ತು ಮೂಲ ಸಬ್ನೆಟ್ ಆಧರಿಸಿದ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ಗೇಟ್‌ವೇಗೆ ಒಂದೇ ನಿಯಮವಾಗಿ ಸೇರುತ್ತವೆ. ಮಾರ್ಗ ಕಾಣೆಯಾದ ಕಾರಣವಲ್ಲ, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆರಿಸಿ.
ಫೈರ್‌ವಾಲ್‌ಗಳು ಹಿಂತಿರುಗು ಮಾರ್ಗದ ಇನ್ನೊಂದು ಅರ್ಧ. ವಲಯ-ಆಧಾರಿತ ಸಾಧನಗಳು ಇರುವ ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್‌ನ ವಲಯವನ್ನು ಹೊಸ ಸಬ್ನೆಟ್‌ಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವಿಸ್ತರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಹಳೆಯ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಬರೆದ ನಿಯಮ ಹೊಂದುವುದಿಲ್ಲ. IPsec ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಹೊಸ ಸಬ್ನೆಟ್ ಅನ್ನು ವಲಯಕ್ಕೆ ಅಥವಾ ಎರಡೂ ದಿಕ್ಕಿನ ನಿಯಮ ಜೋಡಿಗೆ ಸೇರಿಸಿ.
ಮೂರು ಪ್ರಶ್ನೆಗಳಿಂದ ನಿರ್ಧರಿಸಿ, ನಂತರ ಸಂಚಾರದಿಂದ ಪರಿಶೀಲಿಸಿ
ಸಂಕ್ಷಿಪ್ತ ರೂಪ: ಕಡೆಯ ಸಂರಚನೆ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಹೆಸರಿಸುತ್ತದೆಯೇ (ನೀತಿ-ಆಧಾರಿತ), ಅಥವಾ ಸಂಚಾರ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಮಾರ್ಗವಾಗುತ್ತದೆಯೇ (ಮಾರ್ಗ-ಆಧಾರಿತ)? ಎರಡೂ ತುದಿಗಳು ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್ ಪಟ್ಟಿ ಮಾಡುತ್ತವೆಯೇ? ಹೊಸ ಸಬ್ನೆಟ್‌ನಿಂದ ಮೂಲ ಮೂಲ ಶ್ರೇಣಿಗೆ ಹಿಂತಿರುಗುವ ದಾರಿ ಇದೆಯೇ?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
ಪರಿಶೀಲನೆ ಎಂಬುದು ಹೆಚ್ಚಿನ ಬದಲಾವಣೆಗಳು ತುಂಬಾ ಬೇಗ ಮುಚ್ಚುವ ಸ್ಥಳ. ಗೇಟ್‌ವೇಯಿಂದ ಪಿಂಗ್ ಕಡಿಮೆ ಸಾಬೀತು ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಗೇಟ್‌ವೇ ತನ್ನಿಂದಲೇ ಮೂಲವಾಗಿ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಹೋಸ್ಟ್‌ಗಿಂತ ಬೇರೆ ನೀತಿಗೆ ಹೊಂದುತ್ತದೆ. ಹೊಸ ಸಬ್ನೆಟ್‌ನ ಹೋಸ್ಟ್‌ನಿಂದ ಪಿಂಗ್ ಮಾಡಿ, ನಂತರ ಬದಲಾವಣೆಗೆ ಕಾರಣವಾದ ಅಪ್ಲಿಕೇಶನ್ ಚಲಾಯಿಸಿ ಮತ್ತು ಸ್ಥಿತಿ ಚಿಹ್ನೆಯಲ್ಲ, ಕೌಂಟರ್‌ಗಳನ್ನು ನೋಡಿ.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showನೀತಿ-ಆಧಾರಿತ ಟನೆಲ್‌ನಲ್ಲಿ ip xfrm state ನ ಕೌಂಟರ್‌ಗಳು ಎರಡೂ ದಿಕ್ಕಿನಲ್ಲಿ ಏರಬೇಕು; ಸಮತಟ್ಟಾದ ಕೌಂಟರ್ ಎಂದರೆ ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗವಾಗಿದೆ ಆದರೆ ಆಯ್ಕೆಯಾಗಿಲ್ಲ. WireGuard ನಲ್ಲಿ wg show ಪ್ರತಿ ಕಡೆಯ ವರ್ಗಾವಣೆ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಶೂನ್ಯ ಸ್ವೀಕೃತ ಬೈಟ್‌ನ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ದೂರದ ಕಡೆಯ ಪಟ್ಟಿ ಅಥವಾ ಅದರ ಹಿಂತಿರುಗು ಮಾರ್ಗಕ್ಕೆ ಸೂಚಿಸುತ್ತದೆ.
ಪ್ರಿಫಿಕ್ಸ್, ಕಡೆಯ ಸೆಲೆಕ್ಟರ್ ಅಥವಾ ಮಾರ್ಗ, ಹಿಂತಿರುಗು ಮಾರ್ಗದ ನಿರ್ಧಾರ ಮತ್ತು ಫೈರ್ವಾಲ್ ನಮೂದನ್ನು ಉಳಿದ ಟನೆಲ್ ಪಟ್ಟಿಯೊಂದಿಗೆ ದಾಖಲಿಸಿ ಮುಗಿಸಿ. ನಂತರ ಒಂದು ಗೇಟ್‌ವೇ ಮರುಬೂಟ್ ಮಾಡಿ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ: ಕೈಯಿಂದ ಸೇರಿಸಿದ ಮಾರ್ಗ ಮಾಯವಾಗುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದನ್ನು ಮತ್ತೆ ಕಂಡುಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ.