VM ಒಳಗಿನ VPN ಮೂಲಕ ಹೋಸ್ಟ್ ಸಂಚಾರವನ್ನು ರೂಟ್ ಮಾಡುವುದು: ಆರು ಪರಿಶೀಲನೆಗಳು

ಕ್ರಮದಲ್ಲಿ ನಡೆಸುವ ಆರು ಪರಿಶೀಲನೆಗಳು, VM ತನ್ನದೇ ಹೋಸ್ಟ್ಗೆ VPN ಗೇಟ್ ಆಗಬಹುದೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಹೈಪರ್ವೈಜರ್ ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ನಿಮಗಾಗಿ ಮಾಡುವುದಿಲ್ಲ: ಸುರಂಗ ಗೆಸ್ಟ್ನದು, ರೂಟ್ ಹೋಸ್ಟ್ನದು, ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಜಾಲ ಸಾಮಾನ್ಯ ರೂಟಿಂಗ್. ಈ ಪಟ್ಟಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತೇನೆ ಏಕೆಂದರೆ ಒಂದು ಹೆಜ್ಜೆ ಬಿಟ್ಟರೆ ಯಾವಾಗಲೂ ಅದೇ ಲಕ್ಷಣ ಬರುತ್ತದೆ, ಮೌನ, ಹೋಸ್ಟ್ ಸಂತೋಷದಿಂದ ಗೆಸ್ಟ್ಗೆ ಪಿಂಗ್ ಮಾಡುತ್ತದೆ ಆದರೆ ಒಳಗಿನ ಯಾವುದನ್ನೂ ತಲುಪುವುದಿಲ್ಲ.

ಕಾರಣದಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಕಾರ್ಪೊರೇಟ್ ಕ್ಲೈಂಟ್ ಗೆಸ್ಟ್ನ ಒಳಗೆ ಮಾತ್ರ ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ, ಅಥವಾ ನೀತಿ ಅದನ್ನು ಅಲ್ಲಿಯೇ ಇಡುತ್ತದೆ, ಮತ್ತು ನಿಮಗೆ ಇನ್ನೂ ಹೋಸ್ಟ್ನಿಂದ ಒಳಗಿನ build ಸರ್ವರ್ ಬೇಕು. ಹೋಸ್ಟ್ಗೆ ಸ್ವಂತ ಕ್ಲೈಂಟ್ ಅನುಮತಿ ಇದ್ದರೆ ಅದನ್ನೇ ಮಾಡಿ: ಹೋಸ್ಟ್ನಲ್ಲಿ ಒಂದು ಸುರಂಗ ಯಾವಾಗಲೂ ಎರಡು ಜಾಲ ಮತ್ತು NAT ಗಿಂತ ಉತ್ತಮ.

ಪರಿಶೀಲನೆ 1: ಹೋಸ್ಟ್ಗೆ ವಿಳಾಸ ಕೊಡಬಹುದಾದ ಕೊಂಡಿ ಬೇಕು

ಹೋಸ್ಟ್ಗೆ ಗೆಸ್ಟ್ನ ಎರಡನೇ ಅಡಾಪ್ಟರ್ನ ಅದೇ ಪ್ರಿಫಿಕ್ಸ್ನಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಇರಬೇಕು. VirtualBox ನಲ್ಲಿ host-only, VMware Workstation ನಲ್ಲಿ host-only ಅಥವಾ ಕಸ್ಟಮ್ VMnet, QEMU/KVM ನಲ್ಲಿ ಒಳಗಿನ ಸೇತುವೆ ಅಥವಾ tap ಸಾಧನ, ಮತ್ತು Hyper-V ನಲ್ಲಿ Internal ಸ್ವಿಚ್ ಎಲ್ಲವೂ ಅರ್ಹ. ಗೆಸ್ಟ್ 192.168.56.2, ಹೋಸ್ಟ್ 192.168.56.1, ಪ್ರಿಫಿಕ್ಸ್ 192.168.56.0/24 ಪ್ರಯೋಗಾಲಯಗಳಲ್ಲಿ ನಾನು ಬಳಸುವ ಜೋಡಣೆ.

QEMU ನ ಬಳಕೆದಾರ ಮೋಡ್ ಜಾಲ (-netdev user, ಡಿಫಾಲ್ಟ್ SLIRP backend) ಮತ್ತು VirtualBox NAT ಈ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ. ಗೆಸ್ಟ್ನ ಪ್ಯಾಕೆಟ್ಗಳು ಹೋಸ್ಟ್ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಪ್ರಕ್ರಿಯೆಗೆ ತಲುಪುತ್ತವೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ ಗೆಸ್ಟ್ನ ವಿಳಾಸಗಳನ್ನು ಹೊತ್ತ ಸಾಧನವನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ ಮತ್ತು ರೂಟ್ ತೋರಿಸಲು ಏನೂ ಇರುವುದಿಲ್ಲ. Hyper-V ನ Default Switch ಸಹ ಅದೇ ಕಥೆ. ಹೋಸ್ಟ್ನಿಂದ ping 192.168.56.2 ವಿಫಲವಾದರೆ ನಿಲ್ಲಿಸಿ: ನಂತರ ಸೇರಿಸಿದ ಯಾವುದೇ ರೂಟ್ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

ಪರಿಶೀಲನೆ 2: ಗೆಸ್ಟ್ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅನುವಾದಿಸುತ್ತದೆ

ಹೋಸ್ಟ್ನಿಂದ ಬರುವ ಪ್ಯಾಕೆಟ್ಗಳು host-only ಮೂಲ ವಿಳಾಸ ಮತ್ತು ಒಳಗಿನ ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ ಬರುತ್ತವೆ, ಆದ್ದರಿಂದ ಗೆಸ್ಟ್ ಅವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಿ ನಂತರ ತನ್ನ ಸುರಂಗ ವಿಳಾಸದ ಹಿಂದೆ ಮರೆಮಾಡಬೇಕು. Linux ಗೆಸ್ಟ್ನಲ್ಲಿ ಇದರರ್ಥ ಫಾರ್ವರ್ಡಿಂಗ್, FORWARD accept ಜೋಡಿ, ಮತ್ತು ಸುರಂಗದ ಕಡೆಗೆ source NAT:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

MASQUERADE ನಿಯಮವೇ ಜನರು ಬಿಟ್ಟುಬಿಡುವ ಭಾಗ. ಕಾರ್ಪೊರೇಟ್ ರೌಟರ್ಗಳಿಗೆ 192.168.56.0/24 ಇದೆ ಎಂದು ಅಪರೂಪಕ್ಕೆ ತಿಳಿದಿರುತ್ತದೆ; ನಿಯಮದೊಂದಿಗೆ ಒಳಗಿನ ಸರ್ವರ್ಗಳು ಗೆಸ್ಟ್ನ ಸುರಂಗ ವಿಳಾಸವನ್ನು ನೋಡಿ ಅದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಉತ್ತರವು ಗೆಸ್ಟ್ಗೆ ಹಿಂತಿರುಗುವ ದಾರಿ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ.

Windows ಗೆಸ್ಟ್ ಹೆಚ್ಚು ಒಡ್ಡೊಡ್ಡಾದದ್ದು. SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ಅಡಿಯಲ್ಲಿ IPEnableRouter=1 ಅನುವಾದವಿಲ್ಲದೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಾರ್ಪೊರೇಟ್ ರೂಟಿಂಗ್ ಈಗಾಗಲೇ ನಿಮ್ಮ host-only ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಹಿಂತಿರುಗಿ ತೋರಿಸುವಲ್ಲಿಯೇ ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. Internet Connection Sharing ಅನುವಾದಿಸುತ್ತದೆ, ಆದರೆ ಹಂಚಿದ ಅಡಾಪ್ಟರ್ ಅನ್ನು 192.168.137.1 ಗೆ ಮರುಸಂಖ್ಯೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ ರೂಟ್ಗಳನ್ನು ಬರೆಯುವ ಮೊದಲು ಅದು ನಿಜವಾಗಿ ಪಡೆದ ವಿಳಾಸವನ್ನು ಓದಿ.

ಪರಿಶೀಲನೆ 3: ಹೋಸ್ಟ್ ರೂಟ್ಗಳು ಗೆಸ್ಟ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತವೆ, ಸುರಂಗವನ್ನಲ್ಲ

ಹೋಸ್ಟ್ಗೆ ಬೇಕಾದ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಮಾತ್ರ ಗೆಸ್ಟ್ ಮೂಲಕ ಕಳುಹಿಸಿ. Linux ನಲ್ಲಿ ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಒಂದು ರೂಟ್ ಸಾಕು ಮತ್ತು ಅದು ಸ್ವಚ್ಛವಾಗಿ ಹಿಂತಿರುಗುತ್ತದೆ:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Windows ನಲ್ಲಿ ಸಮಾನವಾದದ್ದು route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. ಪರೀಕ್ಷಿಸುವಾಗ -p ಬಿಡಿ, ಕೆಟ್ಟ ರೂಟ್ ಮರುಬೂಟ್ನಲ್ಲಿ ಸಾಯುತ್ತದೆ, ಮತ್ತು ಮಾರ್ಗ ಕೆಲಸ ಮಾಡಿದಾಗ ಸೇರಿಸಿ. ಹೋಸ್ಟ್ನ ಡಿಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ತೆಗೆಯಬೇಡಿ, ಹೋಸ್ಟ್ನ ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್ ಸುರಂಗ ಬಳಸಬೇಕಿದ್ದರೆ ಹೊರತುಪಡಿಸಿ; ಪೂರ್ಣ ಸುರಂಗ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಾದರೆ, ಎರಡು /1 ರೂಟ್ಗಳನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಹೈಪರ್ವೈಜರ್ ಜಾಲಕ್ಕೆ ನೇರ ರೂಟ್ ಇಟ್ಟುಕೊಳ್ಳಿ:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Windows ಹೋಸ್ಟ್ನಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಮೆಟ್ರಿಕ್ ಅನ್ನೂ ಪರಿಶೀಲಿಸಿ. host-only ಅಡಾಪ್ಟರ್ ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದಾಗ ಸೇರಿಸಿದ ರೂಟ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಉಳಿಯುತ್ತದೆ ಆದರೆ ಎಂದಿಗೂ ಸಂಚಾರ ಸಾಗಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಕಡಿಮೆ ಮೆಟ್ರಿಕ್ ಇರುವ ಎರಡನೇ ಅಡಾಪ್ಟರ್ ಅದೇ ಪ್ರಿಫಿಕ್ಸ್ನ ಹುಡುಕಾಟವನ್ನು ಗೆಲ್ಲಬಹುದು.

ಪರಿಶೀಲನೆ 4: DNS ರೂಟ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಸುರಂಗದ ಡಿಫಾಲ್ಟ್ ಅನ್ನಲ್ಲ

ರೂಟ್ಗಳು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸಾಗಿಸುತ್ತವೆ; ಯಾವ ಹೆಸರುಗಳು ಪ್ಯಾಕೆಟ್ ಉತ್ಪಾದಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ರಿಜಾಲ್ವರ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ನ ರಿಜಾಲ್ವರ್ ಬದಲಿಸುವ ಬದಲು ಕಾರ್ಪೊರೇಟ್ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಕಾರ್ಪೊರೇಟ್ ವಲಯಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಿ, ಮತ್ತು ಹೊಸ ರೂಟ್ ಈಗಾಗಲೇ ತಲುಪುವ DNS ಸರ್ವರ್ಗೆ ಅದನ್ನು ತೋರಿಸಿ. ಹೋಸ್ಟ್ನಲ್ಲಿ systemd-resolved ಇದ್ದರೆ:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Windows ನಲ್ಲಿ ಹೆಸರು ಪರಿಹಾರ ನೀತಿ ಕೋಷ್ಟಕದ ನಮೂದು ಅದೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. ಗೆಸ್ಟ್ host-only ವಿಳಾಸದಲ್ಲಿ ತನ್ನದೇ ರಿಜಾಲ್ವರ್ ಚಲಾಯಿಸುತ್ತಿದ್ದರೆ, ಅದರ ಬದಲು ಆ ವಿಳಾಸವನ್ನು ಬಳಸಿ, ಆದರೆ ಅದು loopback ನಲ್ಲಿ ಅಲ್ಲ, 192.168.56.2 ನಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿದ ನಂತರವೇ.

ನಂತರ ನಿಧಾನ ಪುಟಗಳಿಗೆ DNS ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು MTU ಪರಿಶೀಲಿಸಿ. ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್ ಹೋಸ್ಟ್ನ 1500 ಬೈಟ್ ಇಂಟರ್ಫೇಸ್ಗಿಂತ ಚಿಕ್ಕದು, ಆದ್ದರಿಂದ DF ಬಿಟ್ ಹಾಕಿ ಪೂರ್ಣ ಗಾತ್ರದ ಸೆಗ್ಮೆಂಟ್ಗಳನ್ನು ಕಳುಹಿಸುವ ಹೋಸ್ಟ್ ಅವನ್ನು ಗೆಸ್ಟ್ನ ಒಳಗೆ ಎಲ್ಲೋ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಸಾಂಪ್ರದಾಯಿಕ ಲಕ್ಷಣ ಎಂದರೆ ಕೆಲಸ ಮಾಡುವ ping ಮತ್ತು TLS ಹ್ಯಾಂಡ್ಶೇಕ್ ನಂತರ ನಿಂತುಕೊಳ್ಳುವ ಒಳಗಿನ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್. ಗೆಸ್ಟ್ನ ಫಾರ್ವರ್ಡ್ ಮಾರ್ಗದಲ್ಲಿ MSS ಅನ್ನು ಬಿಗಿಗೊಳಿಸಿ:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ಪರಿಶೀಲನೆ 5: ಎರಡೂ ತುದಿಗಳಿಂದ ಪರಿಶೀಲಿಸಿ

ಹೋಸ್ಟ್ನಿಂದ ಒಳಗಿನ ವಿಳಾಸಕ್ಕೆ traceroute ಅಥವಾ tracert ಮೊದಲ ಹಾಪ್ ಆಗಿ ಭೌತಿಕ ಗೇಟ್ವೇ ಅನ್ನಲ್ಲ, 192.168.56.2 ಅನ್ನು ತೋರಿಸಬೇಕು. ಗೆಸ್ಟ್ನಲ್ಲಿ ಅದೇ ಪ್ರಯತ್ನ ಹೊರಹೋಗುವುದನ್ನು ಗಮನಿಸಿ: tcpdump -ni any host 10.20.30.40 host-only ಬದಿಯಲ್ಲಿ ಫಾರ್ವರ್ಡ್ ಆದ ವಿನಂತಿಯನ್ನು ಮತ್ತು ಸುರಂಗದಲ್ಲಿ ಅನುವಾದಿತ ವಿನಂತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಹೊರಹೋಗಿ ಹಿಂತಿರುಗಿಯೂ ಹೋಸ್ಟ್ ಅನ್ನು ಮೌನವಾಗಿ ಬಿಡುವ ವಿನಂತಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಎರಡು ವೈಫಲ್ಯಗಳು ಇದರ ಬಹುಪಾಲನ್ನು ವಿವರಿಸುತ್ತವೆ. ಒಂದೋ NAT ನಿಯಮ ಇಲ್ಲದ ಕಾರಣ ಗೆಸ್ಟ್ನ ಸುರಂಗ host-only ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಹಿಂತಿರುಗುವ ರೂಟ್ ಹೊತ್ತಿಲ್ಲ, ಅಥವಾ ಹೋಸ್ಟ್ ರೂಟ್ ಮರುಪ್ರಾರಂಭದ ನಂತರ ಗೆಸ್ಟ್ ಇನ್ನು ಹೊಂದಿಲ್ಲದ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುತ್ತದೆ. ಹಿಂದಿನ ಅವಧಿಯ ಟಿಪ್ಪಣಿಗಳನ್ನು ನಂಬುವ ಬದಲು ip -br addr ಮತ್ತು ip route get ನಿಂದ ವಿಳಾಸಗಳನ್ನು ಮತ್ತೆ ಓದಿ.

ಪರಿಶೀಲನೆ 6: ಮರುಬೂಟ್ ಮತ್ತು ಹೈಪರ್ವೈಜರ್ ನವೀಕರಣವನ್ನು ತಾಳಿಕೊಳ್ಳುವಂತೆ ಮಾಡಿ

ಎರಡೂ ಅರ್ಧಗಳನ್ನು ಶಾಶ್ವತಗೊಳಿಸಿ: ಹೋಸ್ಟ್ನಲ್ಲಿ netplan ಅಥವಾ NetworkManager ರೂಟ್ ಸಂರಚನೆ, Windows ನಲ್ಲಿ route add ... -p, ಮತ್ತು /etc/sysctl.d/ ನಲ್ಲಿ net.ipv4.ip_forward=1 ಜೊತೆಗೆ ಗೆಸ್ಟ್ನಲ್ಲಿ ಮತ್ತೆ ಲೋಡ್ ಆಗುವ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳ ಗುಂಪು. ಸಂರಚನೆ ಪರಿಶೀಲನೆಯಾದ ಕ್ಷಣ, ಮುಂದಿನ ಕಾರ್ಪೊರೇಟ್ ಕ್ಲೈಂಟ್ ನವೀಕರಣ ಬರುವ ಮೊದಲು ಗೆಸ್ಟ್ನ snapshot ತೆಗೆದುಕೊಳ್ಳಿ.

ಹೈಪರ್ವೈಜರ್ ತನ್ನ ಅಡಾಪ್ಟರ್ಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಿದಾಗ host-only ಜಾಲಗಳು ಮರುಸಂಖ್ಯೆಯಾಗುತ್ತವೆ, ಇದು 192.168.56.0/24 ಮೇಲೆ ಕಟ್ಟಿದ ಪ್ರತಿ ರೂಟ್ ಮತ್ತು NAT ನಿಯಮವನ್ನು ಮೌನವಾಗಿ ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ. ನವೀಕರಣದ ನಂತರ ಮೊದಲ ಮೂರು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪುನರಾವರ್ತಿಸಿ; ಇದು ಒಂದು ನಿಮಿಷ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಹೋಸ್ಟ್ ತನ್ನ ರೂಟ್ ಇನ್ನೂ ಹೊಂದಿದ್ದು ಗೆಸ್ಟ್ ಹೊಸ ಉಪಜಾಲಕ್ಕೆ ಹೋಗಿರುವ ಪ್ರಕರಣವನ್ನು ಹಿಡಿಯುತ್ತದೆ.

IPv6 ಗೆ ತನ್ನದೇ ಸುತ್ತು ಬೇಕು. ip6tables ನಿಯಮಗಳು, AAAA ದಾಖಲೆಗಳು ಮತ್ತು ಹೋಸ್ಟ್ ರೂಟ್ಗಳ ಎರಡನೇ ಕುಟುಂಬ IPv4 ಸಂರಚನೆಯನ್ನು ಅನುಸರಿಸುವುದಿಲ್ಲ, ಮತ್ತು IPv6 ಮೂಲಕ ತಲುಪಬಹುದಾದ ಕಾರ್ಪೊರೇಟ್ ಸೇವೆ IPv4 ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ ಶಾಶ್ವತವಾಗಿ ಮುರಿದಂತೆ ಕಾಣುತ್ತದೆ.

ಉತ್ತೀರ್ಣವಾದರೂ ಇಲ್ಲದಿದ್ದರೂ, ಕ್ರಮವಾಗಿ: ಹೋಸ್ಟ್ ಗೆಸ್ಟ್ನ host-only ವಿಳಾಸಕ್ಕೆ ಪಿಂಗ್ ಮಾಡಬಹುದು; ಗೆಸ್ಟ್ ಸುರಂಗದ ಕಡೆಗೆ ಫಾರ್ವರ್ಡ್ ಮತ್ತು MASQUERADE ಮಾಡುತ್ತದೆ; ip route get ಒಳಗಿನ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಗೇಟ್ವೇ ಆಗಿ ಗೆಸ್ಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ; ಕಾರ್ಪೊರೇಟ್ ಹೆಸರುಗಳು ಸೀಮಿತ ರಿಜಾಲ್ವರ್ ಮೂಲಕ ಪರಿಹಾರವಾಗುತ್ತವೆ; traceroute ಗೆಸ್ಟ್ ಅನ್ನು ಮೊದಲು ತೋರಿಸುತ್ತದೆ; ಮತ್ತು ಅದೇ ಆರು ಉತ್ತರಗಳು ಮರುಬೂಟ್ ಅನ್ನು ತಾಳಿಕೊಳ್ಳುತ್ತವೆ.