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 ਬੈਕਐਂਡ) ਅਤੇ 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 ਮਹਿਮਾਨ ਨੂੰ ਪਹਿਲਾਂ ਦਿਖਾਉਂਦਾ ਹੈ; ਅਤੇ ਉਹੀ ਛੇ ਜਵਾਬ ਰੀਬੂਟ ਝੱਲਦੇ ਹਨ।