VPN ਹੋਸਟ 'ਤੇ ਚਲਾਉਣਾ ਜਾਂ VM ਦੇ ਅੰਦਰ? ਫ਼ੈਸਲੇ ਦੀ ਗਾਈਡ
ਟਨਲ ਦਾ ਮਾਲਕ ਤੈ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਕੀ ਢਕਦਾ ਹੈ। ਹੋਸਟ ਜਾਂ ਮਹਿਮਾਨ 'ਤੇ ਥਾਂ ਚੁਣੋ, ਫਿਰ ਮਹਿਮਾਨ ਦੇ ਅੰਦਰ ਰੂਟ, DNS ਅਤੇ ਨਿਕਾਸ ਜਾਂਚ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ।
ਮਹਿਮਾਨ ਦੇ ਅੰਦਰ ਟਨਲ ਬਣਾਉਣਾ ਅਤੇ ਉਸ ਨੂੰ ਹੋਸਟ 'ਤੇ ਬਣਾਉਣਾ—ਦੋਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਵੱਲੋਂ ਦੱਸੀ ਜਾਂਦੀ ਥਾਂ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਸਮਾਨਤਾ ਉੱਥੇ ਹੀ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ। ਮਹਿਮਾਨ ਦੀ ਮਲਕੀਅਤ ਵਾਲਾ ਟਨਲ ਆਪਣੀਆਂ ਚਾਬੀਆਂ, ਆਪਣਾ ਡਿਫ਼ਾਲਟ ਰੂਟ ਅਤੇ ਆਪਣਾ ਹੱਲ ਕਰਨ ਵਾਲਾ ਮਹਿਮਾਨ ਦੇ ਕਰਨਲ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਜਦਕਿ ਹੋਸਟ ਇਨਕ੍ਰਿਪਟ ਕੀਤੇ ਪੈਕਟ ਇੱਕ ਦੂਰ ਦੀ ਥਾਂ 'ਤੇ ਭੇਜਦਾ ਹੈ। ਹੋਸਟ ਦੀ ਮਲਕੀਅਤ ਵਾਲਾ ਟਨਲ ਇਸ ਦਾ ਉਲਟਾ ਚਿੱਤਰ ਹੈ: ਹੋਸਟ ਕਲਾਇੰਟ ਸੈਸ਼ਨ ਰੱਖਦਾ ਹੈ ਅਤੇ ਰੂਟ ਤੇ ਨੀਤੀ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਮਹਿਮਾਨ ਬਾਹਰ ਆਉਣ ਵਾਲੀ ਚੀਜ਼ ਉਧਾਰ ਲੈਂਦਾ ਹੈ। ਗ਼ਲਤ ਮਾਲਕ ਚੁਣੋ ਤਾਂ ਹਰ ਅਗਲਾ ਲੱਛਣ ਤੁਹਾਨੂੰ ਗ਼ਲਤ ਮਸ਼ੀਨ ਕੋਲ ਭੇਜੇਗਾ। ਦੋ ਹੁਕਮ ਇਹ ਸਵਾਲ ਲਗਭਗ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਤੈ ਕਰ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਸ ਗਾਈਡ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਇਹ ਹੈ ਕਿ ਜਵਾਬ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ।
ਕਲਾਇੰਟ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕ ਤੈ ਕਰੋ
ਨਿਯਮ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਸਾਈਫ਼ਰਟੈਕਸਟ ਕਿੱਥੇ ਬਣਦਾ ਹੈ, ਇਸ ਬਾਰੇ ਨਹੀਂ ਕਿ ਕਿਹੜੀ ਮਸ਼ੀਨ VPN ਆਈਕਨ ਦਿਖਾਉਂਦੀ ਹੈ। ਜੇ ਮਹਿਮਾਨ ਇਹ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਮਹਿਮਾਨ ਨੂੰ VPN ਸਰਵਰ ਤੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰੂਟ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਹੋਸਟ ਤੋਂ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਜੇ ਹੋਸਟ ਇਹ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਹੋਸਟ ਕਲਾਇੰਟ ਸਥਾਨਕ ਟ੍ਰੈਫ਼ਿਕ 'ਤੇ ਜੋ ਵੀ ਨੀਤੀ ਲਾਉਂਦਾ ਹੈ, ਮਹਿਮਾਨ ਦਾ ਹੋਸਟ-ਰਾਹ ਉਸ ਦੇ ਬਾਵਜੂਦ ਟਿਕਣਾ ਚਾਹੀਦਾ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਸਵਾਲ ਤੁਹਾਡੇ ਲਈ ਥਾਂ ਚੁਣ ਲੈਂਦੇ ਹਨ। ਕੀ ਮਹਿਮਾਨ ਦੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਹੋਸਟ 'ਤੇ ਕਿਸੇ ਕਾਰਪੋਰੇਟ ਕਲਾਇੰਟ ਨੂੰ ਪਾਰ ਕਰਨਾ ਪਵੇਗਾ? ਤਾਂ ਟਨਲ ਮਹਿਮਾਨ ਦੇ ਅੰਦਰ ਹੈ। ਕੀ ਕਈ ਮਹਿਮਾਨਾਂ ਨੂੰ ਇੱਕੋ ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਤੇ ਇੱਕੋ ਨਿਕਾਸ ਥਾਂ ਚਾਹੀਦੀ ਹੈ? ਤਾਂ ਇਹ ਹੋਸਟ 'ਤੇ ਹੈ, ਫਾਰਵਰਡਿੰਗ ਜਾਣ-ਬੁੱਝ ਕੇ ਸੈੱਟ ਕੀਤੀ। ਕੀ ਮਹਿਮਾਨ ਦਾ ਟ੍ਰੈਫ਼ਿਕ ਹੋਸਟ ਦੇ VPN ਤੋਂ ਬਾਹਰ ਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ? ਤਾਂ ਮਹਿਮਾਨ ਵਿੱਚ ਟਨਲ ਹੀ ਇੱਕੋ ਅਜਿਹੀ ਵਿਵਸਥਾ ਹੈ ਜੋ ਇਹ ਬਣਾਵਟ ਨਾਲ ਦਿੰਦੀ ਹੈ।
ਜਵਾਬ VM ਦੇ ਨਾਂ ਦੇ ਕੋਲ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਲਿਖੋ: guest-owned ਜਾਂ host-owned। ਛੇ ਮਸ਼ੀਨਾਂ ਦੀ ਲੈਬ ਵਿੱਚ ਉਹ ਨੋਟ ਹੇਠਾਂ ਦਿੱਤੇ ਕਿਸੇ ਵੀ ਕਦਮ ਨਾਲੋਂ ਵੱਧ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਨੂੰ ਉਸ ਟਨਲ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਜਿਸ ਮਸ਼ੀਨ ਵਿੱਚ ਲੌਗਇਨ ਕੀਤਾ ਉਸ ਵਿੱਚ ਕਦੇ ਸੀ ਹੀ ਨਹੀਂ।
WSL1 ਅਤੇ WSL2 ਉਲਟ ਕੇਸ ਹਨ
WSL1 ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਥਾਂ ਦਾ ਸਵਾਲ ਬਹੁਤ ਹੱਦ ਤੱਕ ਲੁਪਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਦੀਆਂ Linux ਬਾਈਨਰੀਆਂ ਅਨੁਵਾਦ ਪਰਤ ਰਾਹੀਂ Windows ਦੇ ਨੈੱਟਵਰਕ ਸਟੈਕ ਸਾਮ੍ਹਣੇ ਚੱਲਦੀਆਂ ਹਨ, ਅਤੇ Linux VPN ਕਲਾਇੰਟ ਕੋਲ ਸੈੱਟ ਕਰਨ ਲਈ ਕੋਈ ਸੁਤੰਤਰ ਇੰਟਰਫ਼ੇਸ ਨਹੀਂ। ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ Windows ਪਾਸੇ ਦਾ ਟਨਲ ਹੈ, ਅਤੇ ਵੰਡ ਕੁਝ ਵੀ ਮਲਕੀਅਤ ਬਿਨਾਂ ਨਤੀਜਾ ਵਰਤਦੀ ਹੈ।
WSL2 ਇਸ ਦੇ ਉਲਟ ਹੈ। ਇਹ Hyper-V ਵਰਚੁਅਲ ਸਵਿੱਚ ਪਿੱਛੇ ਹਲਕੀ ਯੂਟਿਲਿਟੀ VM ਵਿੱਚ ਅਸਲੀ ਕਰਨਲ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਥਾਂ-ਜਗ੍ਹਾ ਹੋਸਟ ਪਾਸੇ ਦੇ ਅਡੈਪਟਰ ਰਾਹੀਂ NAT ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ ਵੰਡ ਅੰਦਰਲਾ Linux ਕਲਾਇੰਟ ਭੌਤਿਕ Linux ਬਕਸੇ ਵਾਂਗ ਵਰਤਦਾ ਹੈ: ਇਹ tun0 ਜਾਂ wg0 ਬਣਾਉਂਦਾ ਹੈ, ਆਪਣੇ ਰੂਟ ਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਨਾਕਾਮੀ ਹੋਸਟ ਪਾਸੇ ਰਹਿੰਦੀ ਹੈ। ਜਦੋਂ Windows VPN ਕਲਾਇੰਟ ਸਥਾਨਕ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਟ੍ਰੈਫ਼ਿਕ ਰੋਕਣ ਵਾਲੀ ਨੀਤੀ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਤਾਂ ਇਹ WSL2 ਸਬਨੈੱਟ ਨੂੰ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲਾ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਮੰਨ ਕੇ NAT ਰਾਹ ਕੱਟ ਦਿੰਦਾ ਹੈ। ਫਿਰ ਵੰਡ DNS ਅਤੇ ਬਾਹਰਲੀ ਪਹੁੰਚ ਗੁਆ ਦਿੰਦੀ ਹੈ, ਜਦਕਿ ਇਸ ਦਾ ਆਪਣਾ ਟਨਲ ਅਜੇ ਤੰਦਰੁਸਤ ਹੈ: wg show ਹੈਂਡਸ਼ੇਕ ਦੱਸਦਾ ਹੈ, ip route ਸਹੀ ਦਿਸਦਾ ਹੈ, ਅਤੇ curl ਲਟਕ ਜਾਂਦਾ ਹੈ।
ਕਿਹੜਾ ਸੁਧਾਰ ਵਰਤ ਸਕਦੇ ਹੋ, ਇਹ Windows ਬਿਲਡ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਪੁਰਾਣਾ WSL ਸਬਨੈੱਟ ਲਈ ਹੋਸਟ ਕਲਾਇੰਟ ਵਿੱਚ ਇੱਕ ਛੋਟ ਹੈ, ਜੋ ਕਲਾਇੰਟ ਦੀਆਂ ਸਥਾਨਕ-ਨੈੱਟਵਰਕ ਜਾਂ ਵੰਡੀਆਂ-ਟਨਲ ਸੈਟਿੰਗਾਂ ਹੇਠ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਨਵਾਂ, ਜਿਹੜੇ Windows 11 ਬਿਲਡ ਇਸ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦੇ ਹਨ, ਸ਼ੀਸ਼ੇ ਵਾਲਾ ਨੈੱਟਵਰਕਿੰਗ ਹੈ: %UserProfile%\.wslconfig ਦੇ [wsl2] ਭਾਗ ਵਿੱਚ networkingMode=mirrored ਰੱਖੋ, wsl --shutdown ਚਲਾਓ, ਅਤੇ ਵੰਡ ਨਿੱਜੀ NAT ਸਬਨੈੱਟ ਦੀ ਥਾਂ ਹੋਸਟ ਦੇ ਇੰਟਰਫ਼ੇਸ ਸਾਂਝੇ ਕਰੇਗੀ। ਸ਼ੀਸ਼ੇ ਵਾਲਾ ਮੋਡ localhost ਅਤੇ ਆਉਂਦੇ ਪੋਰਟਾਂ ਦਾ ਵਰਤਾਓ ਵੀ ਬਦਲਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਟੌਗਲ ਨਹੀਂ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਮੰਨੋ।
NAT, ਬ੍ਰਿਜ ਅਤੇ ਹੋਸਟ ਕੀ ਦੇਖ ਸਕਦਾ ਹੈ
NAT ਹੇਠ ਮਹਿਮਾਨ ਦੇ ਟਨਲ ਪੈਕਟ VPN ਸਰਵਰ ਦੀ ਜਨਤਕ ਥਾਂ 'ਤੇ ਭੇਜੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇਨਕ੍ਰਿਪਟ ਕੀਤੇ UDP ਜਾਂ TCP ਵਜੋਂ ਹੋਸਟ ਅਡੈਪਟਰ ਰਾਹੀਂ ਬਾਹਰ ਨਿਕਲਦੇ ਹਨ। ਹੋਸਟ ਇੱਕ ਪ੍ਰਵਾਹ ਅਤੇ ਉਸ ਦੀ ਬਾਈਟ-ਗਿਣਤੀ ਦੇਖਦਾ ਹੈ, ਅੰਦਰਲੀਆਂ ਮੰਜ਼ਿਲਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ। ਬ੍ਰਿਜ ਅਡੈਪਟਰ ਹੇਠ ਮਹਿਮਾਨ ਦੀ ਭੌਤਿਕ LAN 'ਤੇ ਆਪਣੀ 2-ਪਰਤ ਪਛਾਣ ਹੁੰਦੀ ਹੈ, ਆਪਣਾ DHCP ਲੀਜ਼ ਲੈਂਦਾ ਹੈ, ਅਤੇ MAC-ਆਧਾਰਿਤ ਕਿਸੇ ਵੀ ਨੀਤੀ ਸਾਮ੍ਹਣੇ ਦੂਜੇ ਯੰਤਰ ਵਾਂਗ ਦਿਸਦਾ ਹੈ। ਕੋਈ ਵੀ ਮੋਡ ਹੋਸਟ ਨੂੰ ਟਨਲ ਦਾ ਪੇਲੋਡ ਪੜ੍ਹਨ ਨਹੀਂ ਦਿੰਦਾ; ਬ੍ਰਿਜ ਕੀਤਾ ਮਹਿਮਾਨ ਆਪਣੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਨੈੱਟਵਰਕ ਲਈ ਬੱਸ ਬਹੁਤ ਵੱਧ ਦਿਸਦਾ ਹੈ।
ਅਲੱਗਾਅ ਦੀ ਵੀ ਇੱਕ ਹੇਠਲੀ ਹੱਦ ਹੈ। ਮਹਿਮਾਨ ਉਸ ਮਸ਼ੀਨ ਤੋਂ ਲੁਕ ਨਹੀਂ ਸਕਦਾ ਜੋ ਉਸ ਦੀ ਮੈਮੋਰੀ ਦੀ ਮਾਲਕ ਹੈ, ਅਤੇ ਜੋ ਹੋਸਟ ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ ਉਹ ਮਹਿਮਾਨ ਦੀ RAM ਤੋਂ ਚਾਬੀਆਂ ਪੜ੍ਹ ਸਕਦਾ ਹੈ। ਮਹਿਮਾਨ ਵਿੱਚ ਟਨਲ ਤੁਹਾਨੂੰ ਰੂਟਿੰਗ ਹੱਦ ਅਤੇ ਮਾਲਵੇਅਰ ਹੱਦ ਦਿੰਦਾ ਹੈ, ਲੈਪਟਾਪ ਫੜੀ ਬੈਠੀ ਵਿਅਕਤੀ ਤੋਂ ਸੁਰੱਖਿਆ ਨਹੀਂ। ਦਸਤਾਵੇਜ਼ੀ ਅਡੈਪਟਰ ਮੋਡ ਚੁਣਦੇ ਸਮੇਂ ਖੁੱਲ੍ਹੇ ਰੱਖਣੇ ਚਾਹੀਦੇ ਹਨ, ਕਿਉਂਕਿ ਮੋਡ ਹੋਸਟ ਕੀ ਦੇਖਦਾ ਹੈ ਅਤੇ LAN ਕੀ ਦੇਖਦਾ ਹੈ ਦੋਵੇਂ ਬਦਲਦਾ ਹੈ।
ਗਾਈਡ: ਰੱਖੋ, ਸੈੱਟ ਕਰੋ, ਸਾਬਤ ਕਰੋ
ਇਹ ਚਾਰ ਜਾਂਚਾਂ ਨਵੇਂ ਮਹਿਮਾਨ ਸ਼ੈੱਲ ਵਿੱਚ ਕ੍ਰਮ ਨਾਲ ਚਲਾਓ, ਅਤੇ ਉਸ ਪਹਿਲੀ ਜਾਂਚ 'ਤੇ ਰੁਕੋ ਜੋ ਤੁਹਾਡੇ ਲਿਖੇ ਮਾਲਕ ਨਾਲ ਨਹੀਂ ਮਿਲਦੀ।
ip route get 1.1.1.1ਜੇtun0ਜਾਂwg0ਵਾਪਸ ਦੇਵੇ ਤਾਂ ਮਹਿਮਾਨ-ਮਲਕੀਅਤ, ਅਤੇ ਨਿੱਜੀ ਅਗਲੇ ਹੌਪ ਵਾਲਾeth0ਦੇਵੇ ਤਾਂ ਹੋਸਟ-ਮਲਕੀਅਤ।resolvectl query example.com, ਜਾਂ ਜਿੱਥੇ ਮਹਿਮਾਨ ਕੋਈ ਹੱਲ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਨਹੀਂ ਚਲਾਉਂਦਾ ਉੱਥੇ/etc/resolv.confਪੜ੍ਹੋ। ਜੋ ਟਨਲ ਟ੍ਰੈਫ਼ਿਕ ਢੋਂਦਾ ਹੈ ਪਰ DNS ਨਹੀਂ, ਉਹੀ ਸਭ ਤੋਂ ਆਮ ਅੱਧ-ਸੈੱਟ ਕੀਤੀ ਹਾਲਤ ਹੈ।- ਨਿਕਾਸ ਦੀ ਤੁਲਨਾ ਕਰੋ: ਮਹਿਮਾਨ ਵਿੱਚ
curl -4 -s https://ifconfig.meਅਤੇ ਹੋਸਟ 'ਤੇcurl.exe -4 -s https://ifconfig.me। ਵੱਖਰੀਆਂ ਥਾਵਾਂ ਦਾ ਮਤਲਬ ਹੈ ਮਹਿਮਾਨ ਟਨਲ ਦਾ ਮਾਲਕ ਹੈ, ਅਤੇ VPN 'ਤੇ ਹੋਸਟ ਨਾਲ ਘਰ ਦਾ ISP ਦਿਖਾਉਂਦਾ ਮਹਿਮਾਨ ਉਹ ਕੇਸ ਹੈ ਜਿਸ ਵਿੱਚ ਕੁਝ ਵੀ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਮਿਲਿਆ। - ਦੋਵੇਂ
-6ਨਾਲ ਦੁਹਰਾਓ। ਸਿਰਫ਼-v4 ਟਨਲ v6 ਲੀਕ ਕਰਦਾ ਹੈ, ਜਦ ਤੱਕ ਕਲਾਇੰਟ ਇਸ ਨੂੰ ਰੋਕਦਾ ਜਾਂ ਰੂਟ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਕਲਾਇੰਟ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ v6 ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਹੀ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਕਈ ਮਹਿਮਾਨ ਇੱਕ ਟਨਲ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਹੋਸਟ-ਗੇਟਵੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਹੋਸਟ ਨੂੰ ਫਾਰਵਰਡ ਅਤੇ ਅਨੁਵਾਦ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। Linux ਹੋਸਟ 'ਤੇ ਉਹ ਤਿੰਨ ਟੁਕੜੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਾ ਹੋਵੇ ਤਾਂ ਮਹਿਮਾਨ ਚੁੱਪਚਾਪ ਆਪਣੇ ਸਾਧਾਰਨ ਰੂਟ 'ਤੇ ਮੁੜ ਜਾਂਦਾ ਹੈ:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPTWireGuard ਪਾਸੇ ਹੋਸਟ ਪੀਅਰ ਦੇ AllowedIPs ਵਿੱਚ ਮਹਿਮਾਨਾਂ ਦਾ ਸਬਨੈੱਟ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ 192.168.122.0/24, ਨਹੀਂ ਤਾਂ ਵਾਪਸੀ ਪੈਕਟ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੇ ਅਤੇ ਸੈੱਟਅੱਪ ਫਾਇਰਵਾਲ ਸਮੱਸਿਆ ਵਾਂਗ ਦਿਸਦਾ ਹੈ। Windows ਹੋਸਟ Internet Connection Sharing ਜਾਂ Hyper-V ਸਵਿੱਚ 'ਤੇ NAT ਨਿਯਮ ਨਾਲ ਉਹੀ ਨਤੀਜਾ ਪਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਸ ਨੂੰ ਵੀ ਉਹੀ ਵਾਪਸੀ-ਰਾਹ ਜਾਂਚ ਚਾਹੀਦੀ ਹੈ।
ਜਦੋਂ ਲੇਆਉਟ ਅਜੇ ਖੁੱਲ੍ਹਾ ਹੈ, ਇਹ ਸਾਰਣੀ ਸਭ ਤੋਂ ਆਮ ਵਿਵਸਥਾਵਾਂ ਢਕਦੀ ਹੈ:
| Situation | Owner | Check first |
|---|---|---|
| One VM, host also on a corporate VPN | Guest | Does the host client block local networks? |
| Six lab VMs, one exit address | Host plus forwarding | ip_forward, NAT rule, server AllowedIPs |
| Malware or research VM | Guest, NAT | Snapshot age and resolver state |
| Bridged VM on an office LAN | Guest | DHCP lease and port security |
ਦੋ ਟਨਲ, ਦੋ ਮਹਿਮਾਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਟਕਰਾਅ
ਜਦੋਂ ਇੱਕੋ ਸਮੇਂ ਦੋ ਨਿਕਾਸ ਚਾਹੀਦੇ ਹਨ, ਟਿਕਣ ਵਾਲਾ ਨਮੂਨਾ ਹੈ ਪ੍ਰਤੀ ਮਹਿਮਾਨ ਇੱਕ ਟਨਲ। ਹਰ VM ਆਪਣਾ ਡਿਫ਼ਾਲਟ ਰੂਟ ਅਤੇ ਹੱਲ ਕਰਨ ਵਾਲਾ ਰੱਖਦਾ ਹੈ, ਹੋਸਟ ਆਮ ਨੈੱਟਵਰਕ 'ਤੇ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਟਨਲ ਇੱਕੋ ਰੂਟਿੰਗ ਸਾਰਣੀ ਲਈ ਕਦੇ ਨਹੀਂ ਝਗੜਦੇ। ਦੋ ਮਹਿਮਾਨਾਂ ਨੂੰ ਬ੍ਰਿਜ ਨਾਲ ਜੋੜਨਾ ਉਨ੍ਹਾਂ ਦੇ ਰੂਟ ਵੀ ਨਹੀਂ ਜੋੜਦਾ: ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਰਾਹ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਅਜੇ ਵੀ ਦੱਸਣਾ ਪੈਂਦਾ ਹੈ ਕਿ ਇਹ ਸਥਾਨਕ ਟ੍ਰੈਫ਼ਿਕ ਟਨਲ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦਾ ਹੈ।
ਹੋਸਟ ਟਨਲ ਅਤੇ ਮਹਿਮਾਨ ਟਨਲ ਇਕੱਠੇ ਚਲਾਉਣਾ ਜਾਇਜ਼ ਹੈ, ਅਤੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਨੈਸਟਿੰਗ ਕਈ ਵਾਰ ਬਿਲਕੁਲ ਉਹੀ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ—ਮਹਿਮਾਨ ਆਪਣੇ ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹ ਟਨਲ ਹੋਸਟ ਦੇ ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਰੁਕਾਵਟ ਬਣਾਉਣ ਵਾਲੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕਿਹੜੇ ਸਿਰੇ 'ਤੇ ਕਿਹੜੀ ਪਰਤ ਰਾਹੀਂ ਪਹੁੰਚਣਾ ਹੈ, ਕਿਸੇ ਨੇ ਲਿਖਿਆ ਨਹੀਂ। ਮੰਜ਼ਿਲ ਅਤੇ ਮਾਲਕ ਦੀ ਦੋ-ਕਾਲਮ ਸੂਚੀ ਰੱਖੋ, ਅਤੇ ਰੂਟ ਟਕਰਾਅ ਦੁਪਹਿਰ ਭਰ ਦੀ ਖੋਜ ਦੀ ਥਾਂ ਇੱਕ ਖੋਜ ਬਣ ਜਾਂਦਾ ਹੈ।
ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਮੁੜ-ਪ੍ਰਾਪਤੀ ਮਾਲਕ ਕੋਲ ਹੀ ਰੱਖੋ
ਮਹਿਮਾਨ ਦੇ ਅੰਦਰੋਂ ਪਰਖੋ ਨਵੀਂ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਨਾਲ: ਟ੍ਰੈਫ਼ਿਕ, ਨਾਂ-ਹੱਲ, ਦੋਵੇਂ ਥਾਂ-ਪਰਿਵਾਰ, ਅਤੇ ਟਨਲ ਡਿੱਗਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ। ਹੋਸਟ ਦਾ VPN ਆਈਕਨ ਮਹਿਮਾਨ ਦੀ ਕਵਰੇਜ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਅਤੇ ਇਸ ਪੂਰੇ ਖੇਤਰ ਵਿੱਚ ਇਹੀ ਸਭ ਤੋਂ ਆਮ ਝੂਠੀ ਪੁਸ਼ਟੀ ਹੈ।
ਮੁੜ-ਪ੍ਰਾਪਤੀ ਵੀ ਮਾਲਕ ਦੀ ਹੈ। ਮਹਿਮਾਨ-ਮਲਕੀਅਤ ਵਾਲਾ ਟਨਲ ਮਹਿਮਾਨ ਦੇ ਆਪਣੇ ਕਲਾਇੰਟ ਅਤੇ ਉਸ ਵੱਲੋਂ ਲਿਖੇ ਰੂਟਾਂ ਰਾਹੀਂ ਬਹਾਲ ਹੁੰਦਾ ਹੈ। ਹੋਸਟ-ਮਲਕੀਅਤ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਹੋਸਟ ਦੇ ਬੂਟ-ਕ੍ਰਮ ਰਾਹੀਂ ਬਹਾਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਰੀਬੂਟ ਵਿੱਚ ਨਹੀਂ ਟਿਕਦੇ ਜਦ ਤੱਕ ਕੋਈ unit ਜਾਂ ਸਟਾਰਟਅੱਪ ਕੰਮ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਾਗੂ ਨਾ ਕਰੇ। ਬਹਾਲ ਕੀਤਾ ਸਨੈਪਸ਼ਾਟ ਇੱਕ ਤੈਨਾਤੀ ਹੈ, ਰੱਦ ਨਹੀਂ, ਕਿਉਂਕਿ ਇਹ ਡਿਸਕ ਨਾਲ ਪੁਰਾਣੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਤੇ ਪੁਰਾਣੇ ਰੂਟ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ। ਕੰਮ ਮੁਕੰਮਲ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਮਾਲਕ ਅਜੇ ਵੀ ਤੁਹਾਡੀ ਲਿਖੀ ਲਾਈਨ ਨਾਲ ਮਿਲਦਾ ਹੈ, DNS ਅਤੇ ਦੋਵੇਂ ਥਾਂ-ਪਰਿਵਾਰ ਮਹਿਮਾਨ ਦੇ ਅੰਦਰ ਹੱਲ ਹੁੰਦੇ ਹਨ, ਮਰਿਆ ਟਨਲ ਕਾਲੇ ਛੇਕ ਦੀ ਥਾਂ ਵਰਤੋਂਯੋਗ ਨੈੱਟਵਰਕ ਛੱਡਦਾ ਹੈ, ਅਤੇ ਰੀਬੂਟ ਜਾਂ ਸਨੈਪਸ਼ਾਟ ਬਹਾਲੀ ਉਹੀ ਹਾਲਤ ਮੁੜ ਪੈਦਾ ਕਰਦੀ ਹੈ।