NAT ਜਾਂ ਬ੍ਰਿਜ VM ਨੈੱਟਵਰਕ: VPN ਟ੍ਰੈਫਿਕ ਕੌਣ ਲਿਜਾਂਦਾ ਹੈ?

NAT ਮਹਿਮਾਨ ਹੋਸਟ ਦੀ ਸੁਰੰਗ ਤਾਂ ਹੀ ਉਧਾਰ ਲੈਂਦੇ ਹਨ ਜਦੋਂ ਕਲਾਇੰਟ ਰੂਟ ਅਨੁਸਾਰ ਸੁਰੰਗ ਬਣਾਉਂਦਾ ਹੈ; ਬ੍ਰਿਜ ਮਹਿਮਾਨ ਆਪ ਰੂਟ ਕਰਦੇ ਹਨ। ਮਹਿਮਾਨ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਢੁੱਕਵਾਂ ਮੋਡ ਚੁਣੋ।

ਬ੍ਰਿਜ ਅਤੇ NAT ਇੱਕੋ ਮਹਿਮਾਨ ਨੂੰ ਤੁਹਾਡੇ VPN ਨਾਲ ਜੋੜਨ ਦੇ ਦੋ ਤਰੀਕੇ ਨਹੀਂ ਹਨ; ਉਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਸੁਰੰਗ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਮਹਿਮਾਨ ਦੇ ਪੈਕਟ ਕਿਸ ਦੇ ਹਨ। NAT ਮੋਡ ਵਿੱਚ ਹਾਈਪਰਵਾਈਜ਼ਰ ਮਹਿਮਾਨ ਦਾ ਟ੍ਰੈਫਿਕ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ ਅਤੇ ਹੋਸਟ ਪਾਸੇ ਦੇ ਕੋਡ ਤੋਂ ਬਾਹਰ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ ਮਹਿਮਾਨ ਉਸ ਰੂਟ ਉੱਤੇ ਚੱਲਦਾ ਹੈ ਜੋ ਹੋਸਟ ਉਸ ਕੋਡ ਨੂੰ ਦਿੰਦਾ ਹੈ। ਬ੍ਰਿਜ ਮੋਡ ਵਿੱਚ ਮਹਿਮਾਨ ਭੌਤਿਕ ਖੰਡ ਵਿੱਚ ਆਪਣੀ ਲਿੰਕ-ਲੇਅਰ ਪਛਾਣ ਲੈਂਦਾ ਹੈ ਅਤੇ ਆਪਣਾ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਚੁਣਦਾ ਹੈ, ਜੋ ਹੋਸਟ ਦੀ ਸੁਰੰਗ ਨੂੰ ਉਸ ਲਈ ਅਪ੍ਰਸੰਗਿਕ ਬਣਾ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ LAN ਰਾਊਟਰ ਹੀ ਸੁਰੰਗ ਨਹੀਂ ਬਣਾ ਰਿਹਾ। ਮੈਂ VM ਨੂੰ VPN ਉੱਤੇ ਮੰਨਣਾ ਛੱਡ ਦਿੱਤਾ ਅਤੇ ਇਸਨੂੰ ਇਸ ਸਵਾਲ ਵਜੋਂ ਵੇਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕਿ ਉਸ ਮਹਿਮਾਨ ਦਾ ਡਿਫ਼ਾਲਟ ਰੂਟ ਕਿੱਧਰ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਂਚ ਹਰ ਮੋਡ ਲਈ ਕੁਝ ਮਿੰਟ ਲੈਂਦੀ ਹੈ ਅਤੇ ਅੰਦਾਜ਼ੇ ਬਿਨਾਂ ਇਸਨੂੰ ਤੈਅ ਕਰਦੀ ਹੈ।

NAT ਮਹਿਮਾਨ ਨੂੰ ਹਾਈਪਰਵਾਈਜ਼ਰ ਕੋਡ ਪਿੱਛੇ ਰੱਖਦਾ ਹੈ, ਜਿੱਥੇ ਹੋਸਟ ਦੇ ਰੂਟ ਲਾਗੂ ਹੁੰਦੇ ਹਨ

VirtualBox ਵਿੱਚ NAT ਮਹਿਮਾਨ 10.0.2.0/24 ਉੱਤੇ ਬੈਠਦਾ ਹੈ, 10.0.2.2 ਉੱਤੇ ਵਰਚੁਅਲ ਗੇਟਵੇ, 10.0.2.3 ਉੱਤੇ DNS ਪ੍ਰੌਕਸੀ, ਅਤੇ ਭੌਤਿਕ ਨੈੱਟਵਰਕ ਤੱਕ ਆਪਣਾ ਕੋਈ ਰੂਟ ਨਹੀਂ। ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਪੈਕਟ NAT ਇੰਜਣ ਲੈਂਦਾ ਹੈ, ਸਰੋਤ ਹੋਸਟ ਹੋਣ ਵਾਂਗ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ ਅਤੇ ਹੋਸਟ ਦੇ IP ਸਟੈਕ ਨੂੰ ਦਿੰਦਾ ਹੈ। ਉੱਥੋਂ ਮਹਿਮਾਨ ਦਾ ਟ੍ਰੈਫਿਕ ਹੋਸਟ ਪ੍ਰਵਾਹ ਹੈ, ਅਤੇ ਰੂਟ ਖੋਜ ਮੰਜ਼ਿਲ ਅਨੁਸਾਰ ਹੁੰਦੀ ਹੈ: ਹੋਸਟ ਉੱਤੇ 0.0.0.0/1 ਅਤੇ 128.0.0.0/1 ਸਥਾਪਿਤ ਕਰਨ ਵਾਲਾ ਪੂਰਾ-ਸੁਰੰਗ ਕਲਾਇੰਟ VM ਦੇ ਹੋਣ ਬਾਰੇ ਕਦੇ ਜਾਣੇ ਬਿਨਾਂ ਇਸਨੂੰ ਫੜ ਲੈਂਦਾ ਹੈ। Oracle ਦਾ VirtualBox ਨੈੱਟਵਰਕਿੰਗ ਅਧਿਆਇ ਇਹ ਡਿਫ਼ਾਲਟ ਮੁੱਲ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਬਿਲਡ ਉੱਤੇ ਪਤੇ ਪਰਖਣਾ ਚਾਹੋ।

libvirt ਦਾ ਡਿਫ਼ਾਲਟ ਨੈੱਟਵਰਕ 192.168.122.0/24 ਤੋਂ ਉਸੇ ਥਾਂ ਪਹੁੰਚਦਾ ਹੈ, ਜਿੱਥੇ dnsmasq ਲੀਜ਼ ਵੰਡਦਾ ਹੈ ਅਤੇ ਹੋਸਟ ਉਪਜਾਲ ਨੂੰ ਮਾਸਕਰੇਡ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਮਹਿਮਾਨ ਦੇ ਪੈਕਟ ਦੁਬਾਰਾ ਹੋਸਟ ਦੇ ਰੂਟਿੰਗ ਫ਼ੈਸਲੇ ਕੋਲ ਆਉਂਦੇ ਹਨ। ਅਪਵਾਦ ਉਹ ਕਲਾਇੰਟ ਹੈ ਜੋ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੂਟ ਦੀ ਥਾਂ ਪ੍ਰਕਿਰਿਆ ਅਨੁਸਾਰ ਚੁਣਦਾ ਹੈ। ਜੇ ਸਪਲਿਟ-ਸੁਰੰਗ ਸੂਚੀ ਵਿੱਚ ਸਿਰਫ਼ ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ, ਤਾਂ NAT ਇੰਜਣ ਉਸ ਸੂਚੀ ਵਿੱਚ ਨਹੀਂ, ਅਤੇ ਮਹਿਮਾਨ ਸੁਰੰਗ ਬਿਨਾਂ ਮਸ਼ੀਨ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਹੋਸਟ ਦਾ ਬ੍ਰਾਊਜ਼ਰ ਅਜੇ ਵੀ ਢਕਿਆ ਦਿਸਦਾ ਹੈ। ਉਹੀ ਉਪਜਾਲ, ਉਲਟ ਨਤੀਜਾ।

ਬ੍ਰਿਜ ਮਹਿਮਾਨ ਨੂੰ ਭੌਤਿਕ LAN ਉੱਤੇ ਆਪਣੀ ਥਾਂ ਦਿੰਦਾ ਹੈ

ਬ੍ਰਿਜ ਮਹਿਮਾਨ ਨੂੰ ਅਸਲ ਅਡੈਪਟਰ ਨਾਲ ਜੁੜਿਆ ਵਰਚੁਅਲ NIC ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਉਸਨੂੰ ਆਪਣਾ MAC ਪਤਾ ਮਿਲਦਾ ਹੈ ਅਤੇ ਭੌਤਿਕ ਨੈੱਟਵਰਕ ਤੋਂ DHCP ਲੀਜ਼ ਲੈਂਦਾ ਹੈ। ਉਸਦਾ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ LAN ਰਾਊਟਰ ਹੈ, ਹਾਈਪਰਵਾਈਜ਼ਰ ਨਹੀਂ, ਅਤੇ ਉਸਦੇ ਫ਼ਰੇਮ ਉਸ ਅਡੈਪਟਰ ਰਾਹੀਂ ਤਾਰ ਉੱਤੇ ਜਾਂਦੇ ਹਨ। ਹੋਸਟ ਦੇ ਸੁਰੰਗ ਰੂਟ ਹੋਸਟ ਦੀ ਸਾਰਣੀ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਕਦੇ ਨਹੀਂ ਪੁੱਛੇ ਜਾਂਦੇ, ਕਿਉਂਕਿ ਮਹਿਮਾਨ ਦੇ ਫ਼ਰੇਮ ਕਦੇ ਹੋਸਟ ਦੇ IP ਸਟੈਕ ਵਿੱਚ ਦਾਖ਼ਲ ਨਹੀਂ ਹੁੰਦੇ।

ਇਹ ਦੋਵੇਂ ਪਾਸੇ ਕੱਟਦਾ ਹੈ। mDNS ਅਤੇ SMB ਬ੍ਰਾਊਜ਼ਿੰਗ ਕੰਮ ਕਰਨ ਲੱਗਦੇ ਹਨ ਕਿਉਂਕਿ ਮਹਿਮਾਨ ਨੂੰ LAN ਦਾ ਪ੍ਰਸਾਰਣ ਟ੍ਰੈਫਿਕ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਮਹਿਮਾਨ ਵਿਚਕਾਰ ਹੋਸਟ ਫਾਇਰਵਾਲ ਤੋਂ ਬਿਨਾਂ ਉਸੇ ਖੰਡ ਦੀਆਂ ਹੋਰ ਮਸ਼ੀਨਾਂ ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੋ ਜਾਂਦਾ ਹੈ। ਬ੍ਰਿਜ ਮੌਜੂਦਾ ਸੁਰੰਗ ਰਾਹੀਂ ਮਹਿਮਾਨ ਨੂੰ ਧੱਕਣ ਦਾ ਤਰੀਕਾ ਵੀ ਨਹੀਂ: VM ਨੂੰ ਹੋਸਟ ਦੇ WireGuard ਜਾਂ OpenVPN ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਜੋੜਨਾ ਉਹ ਕੰਮ ਨਹੀਂ ਜੋ VirtualBox ਜਾਂ libvirt ਤੁਹਾਡੇ ਲਈ ਕਰਨ। ਜੇ ਬ੍ਰਿਜ ਮਹਿਮਾਨ ਨੂੰ ਸੁਰੰਗ ਰਾਹੀਂ ਜਾਣਾ ਹੈ, ਤਾਂ ਸੁਰੰਗ ਨੂੰ ਉਸ LAN ਵਿੱਚ ਕਿਤੇ ਖ਼ਤਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਬਹਿਸ ਖ਼ਤਮ ਕਰਨ ਵਾਲੀ ਜਾਂਚ

ਦੋਵੇਂ ਮੋਡਾਂ ਵਿੱਚ ਉਹੀ ਜਾਂਚਾਂ ਚਲਾਓ ਅਤੇ ਜਵਾਬ ਲਿਖੋ:

  • ਹੋਸਟ ਉੱਤੇ curl -s https://ifconfig.me ਜਨਤਕ v4 ਪਤਾ ਦਿੰਦਾ ਹੈ।
  • ਮਹਿਮਾਨ ਵਿੱਚ ਉਹੀ ਕਮਾਂਡ, ਨਾਲੇ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਲਈ Linux ਉੱਤੇ ip route ਜਾਂ Windows ਉੱਤੇ Get-NetRoute -DestinationPrefix 0.0.0.0/0।
  • ਰਿਜ਼ੌਲਵਰ ਦੀ ਪਛਾਣ: ਮਹਿਮਾਨ ਵਿੱਚ resolvectl status ਜਾਂ cat /etc/resolv.conf, ਇਹ ਵੇਖਣ ਲਈ ਕਿ ਇਹ 10.0.2.3 ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜਾਂ LAN ਸਰਵਰ ਵੱਲ।
  • ਪਤਾ ਪਰਿਵਾਰ: ip -6 addr show scope global ਅਤੇ ਇੱਕ v6 ਬੇਨਤੀ, ਕਿਉਂਕਿ v4 ਸੁਰੰਗ ਮਹਿਮਾਨ ਕੋਲ ਹੋ ਸਕਣ ਵਾਲੇ ਗਲੋਬਲ v6 ਪਤੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ।

ਮਿਲਦੇ ਜਨਤਕ ਪਤੇ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮਹਿਮਾਨ ਹੋਸਟ ਦੇ ਰਾਹ ਉੱਤੇ ਹੈ। LAN ਦੇ ਆਮ ਨਿਕਾਸ ਨਾਲ ਮਿਲਦੇ ਮਹਿਮਾਨ ਪਤੇ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨਹੀਂ। ਜੋ ਕਦਮ ਲੋਕ ਛੱਡਦੇ ਹਨ ਉਹ ਨਿਯੰਤਰਣ ਹੈ: ਹੋਸਟ ਦੀ ਸੁਰੰਗ ਹੇਠਾਂ ਲਾਹੋ ਅਤੇ ਮਹਿਮਾਨ ਦੀ ਬੇਨਤੀ ਦੁਹਰਾਓ। ਜੇ ਮਹਿਮਾਨ ਬ੍ਰਾਊਜ਼ ਕਰਦਾ ਰਹੇ, ਤਾਂ ਉਹ ਕਦੇ ਹੋਸਟ ਦੀ ਸੁਰੰਗ ਉੱਤੇ ਨਿਰਭਰ ਨਹੀਂ ਸੀ, ਮੋਡ ਦਾ ਨਾਮ ਭਾਵੇਂ ਕੁਝ ਵੀ ਸੁਝਾਵੇ। NAT ਮੋਡ ਵਿੱਚ ਹੋਸਟ ਦੀ ਸੁਰੰਗ ਹੇਠਾਂ ਹੋਣ ਵੇਲੇ ਮਹਿਮਾਨ ਨੂੰ ਇੰਟਰਨੈੱਟ ਗੁਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਕਲਾਇੰਟ ਸੁਰੰਗ ਬਿਨਾਂ ਟ੍ਰੈਫਿਕ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਸੈੱਟ ਨਹੀਂ, ਜੋ ਆਪਣੇ ਆਪ ਵਿੱਚ ਜਾਣਨ ਯੋਗ ਹੈ।

ਦੋ ਸੰਕੇਤ ਝੂਠ ਬੋਲਦੇ ਹਨ। ਸਫਲ ping ਪਹੁੰਚ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਨਿਕਾਸ ਰਾਹ ਨਹੀਂ। ਅਤੇ DNS ਦਾ ਜਵਾਬ 10.0.2.3 ਪ੍ਰੌਕਸੀ ਹੋਸਟ ਦੇ ਰਿਜ਼ੌਲਵਰ ਰਾਹੀਂ ਦੇ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ TCP ਹੋਰ ਰੂਟ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਇੰਝ ਲੋਡ ਹੁੰਦਾ ਸਫ਼ਾ ਅਤੇ ਕਦੇ ਪੂਰਾ ਨਾ ਹੋਣ ਵਾਲਾ ਲੌਗਇਨ ਮਿਲਦਾ ਹੈ।

ਕੰਮ ਲਈ ਕਿਹੜਾ ਮੋਡ ਢੁੱਕਦਾ ਹੈ

ਮੋਡ ਰੂਟਿੰਗ ਦਾ ਫ਼ੈਸਲਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਆਦਤ ਦੀ ਥਾਂ ਲੋੜ ਅਨੁਸਾਰ ਚੁਣੋ:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

ਪਹਿਲੀ ਕਤਾਰ ਉਹ ਹੈ ਜਿੱਥੇ ਲੋਕ ਫਸਦੇ ਹਨ: NAT ਨਾਲ ਹੋਸਟ ਉੱਤੇ ਪੂਰਾ-ਸੁਰੰਗ ਕਲਾਇੰਟ ਮਹਿਮਾਨ ਨੂੰ ਢਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਤਦ ਤੱਕ ਜਦੋਂ ਕਲਾਇੰਟ ਰੂਟ ਅਨੁਸਾਰ ਸੁਰੰਗ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਹੋਸਟ ਦਾ ਉੱਪਰਲਾ ਲਿੰਕ ਉਹੀ ਸੁਰੰਗ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ ਸਿਰਫ਼ ਬ੍ਰਾਊਜ਼ਰ ਲਈ ਇਜਾਜ਼ਤ ਸੂਚੀ ਵਿੱਚ ਲਿਜਾਓ ਅਤੇ ਕਿਤੇ ਵੀ ਕੋਈ ਗਲਤੀ ਬਿਨਾਂ ਢਕਣ ਗ਼ਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਚੌਥੀ ਕਤਾਰ ਉਲਟ ਗਲਤੀ ਹੈ: ਸੁਵਿਧਾ ਲਈ ਬ੍ਰਿਜ ਕੀਤਾ ਮਹਿਮਾਨ ਜੋ ਦਫ਼ਤਰ ਦੇ LAN ਉੱਤੇ ਚੁੱਪਚਾਪ SMB ਜਾਂ SSH ਨੂੰ ਜਵਾਬ ਦੇਣ ਲੱਗਦਾ ਹੈ।

VPN ਉੱਤੇ ਮੜ੍ਹੇ ਜਾਣ ਵਾਲੇ ਨੁਕਸ

Windows ਉੱਤੇ NAT ਅਨੁਵਾਦ VirtualBox VM ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੰਦਰ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਤੀ-ਐਪ ਕਲਾਇੰਟ ਨੂੰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਲਈ ਆਮ ਨਿਯਮ ਦੀ ਥਾਂ ਉਹੀ ਚਿੱਤਰ ਆਪਣੀ ਸੂਚੀ ਵਿੱਚ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਕਲਾਇੰਟ ਅਪਡੇਟ ਆਪਣੀ ਪ੍ਰਕਿਰਿਆ ਸੂਚੀ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ NAT ਮਹਿਮਾਨ ਪਹਿਲਾਂ ਢਕਣ ਗੁਆਉਂਦੇ ਹਨ, ਅਤੇ ਰਿਪੋਰਟ ਹੋਸਟ ਠੀਕ ਹੁੰਦਿਆਂ LAN ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੇ ਪਰ ਇੰਟਰਨੈੱਟ ਤੱਕ ਨਾ ਪਹੁੰਚਣ ਵਾਲੇ VM ਵਾਂਗ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ।

Wi-Fi ਉੱਤੇ ਬ੍ਰਿਜ ਕਰਨਾ ਦੂਜਾ ਕਲਾਸਿਕ ਹੈ। ਐਕਸੈਸ ਪੁਆਇੰਟ ਬਾਹਰੀ ਸਰੋਤ MAC ਵਾਲੇ ਫ਼ਰੇਮ ਘੱਟ ਹੀ ਅੱਗੇ ਭੇਜਦੇ ਹਨ, ਇਸ ਲਈ wlan0 ਉੱਤੇ ਬ੍ਰਿਜ ਜਾਂ ਤਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜਾਂ ਉਦੋਂ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ AP ਉੱਤੇ ਕਲਾਇੰਟ ਅਲੱਗਾਅ ਇਸਨੂੰ ਡੇਗਣਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦਾ। VirtualBox ਫਿਰ ਵੀ ਆਪਣੀ ਸੂਚੀ ਵਿੱਚ ਵਾਇਰਲੈੱਸ ਅਡੈਪਟਰ ਪੇਸ਼ ਕਰੇਗਾ। ਜੇ ਹੋਸਟ Wi-Fi ਉੱਤੇ ਹੈ ਅਤੇ ਮਹਿਮਾਨ ਨੂੰ ਬ੍ਰਿਜ ਕਰਨਾ ਹੈ, ਤਾਂ ਮੰਨਣ ਦੀ ਥਾਂ ਜਾਂਚ ਦੀ ਯੋਜਨਾ ਬਣਾਓ।

MTU ਤੀਜਾ ਹੈ। ਬ੍ਰਿਜ ਮਹਿਮਾਨ LAN ਦਾ 1500 ਬਾਈਟ MTU ਰੱਖਦਾ ਹੈ, ਅਤੇ ਜੇ ਉਹ 1420 ਉੱਤੇ ਆਪਣਾ WireGuard ਕਲਾਇੰਟ ਚਲਾਉਂਦਾ ਹੈ, ਤਾਂ ਵੱਡੇ TLS ਹੈਂਡਸ਼ੇਕ ਅਟਕ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਕਿ ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਸਫਲ ਹੁੰਦੀਆਂ ਹਨ। NAT ਹੇਠ ਹੋਸਟ ਸੁਰੰਗ ਦਾ MTU ਹੋਸਟ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਪਰ ਮਹਿਮਾਨ ਅਜੇ ਵੀ 1500 ਮੰਨਦਾ ਹੈ, ਅਤੇ don't-fragment ਬਿੱਟ ਸੈੱਟ ਵਾਲਾ UDP ਉਸੇ ਤਰ੍ਹਾਂ ਗ਼ਾਇਬ ਹੁੰਦਾ ਹੈ।

ਮੋਡ ਲਿਖੋ ਅਤੇ ਹਰ ਅਡੈਪਟਰ ਬਦਲਾਅ ਮਗਰੋਂ ਦੁਬਾਰਾ ਜਾਂਚੋ

ਮੋਡ, ਬ੍ਰਿਜ ਵਰਤਦਾ ਹੋਸਟ ਇੰਟਰਫ਼ੇਸ, ਮਹਿਮਾਨ ਦਾ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ, ਉਸਦਾ ਰਿਜ਼ੌਲਵਰ ਅਤੇ ਉਸਦੇ v4 ਤੇ v6 ਨਿਕਾਸ ਪਤੇ ਦਰਜ ਕਰੋ। ਉਹੀ ਰਿਕਾਰਡ ਅਗਲਾ ਨੁਕਸ ਸਸਤਾ ਬਣਾਉਂਦਾ ਹੈ: ਜਦੋਂ ਲੈਪਟਾਪ ਡੌਕ ਤੋਂ Wi-Fi ਉੱਤੇ ਜਾਂਦਾ ਹੈ, ਬ੍ਰਿਜ ਮਹਿਮਾਨ ਬ੍ਰਿਜ ਨਾਲ ਦੂਜੇ ਭੌਤਿਕ ਅਡੈਪਟਰ ਵੱਲ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹੋਰ ਉਪਜਾਲ ਵਿੱਚ ਦੁਬਾਰਾ ਲੀਜ਼ ਲੈ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ NAT ਮਹਿਮਾਨ ਆਪਣਾ 10.0.2.x ਪਤਾ ਰੱਖਦਾ ਹੈ ਅਤੇ ਚੁੱਪਚਾਪ ਹੋਰ ਉੱਪਰਲਾ ਲਿੰਕ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈ ਲੈਂਦਾ ਹੈ।

ਟਿਕਟ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ:

  • ਮਹਿਮਾਨ ਦਾ ਨਿਕਾਸ ਪਤਾ ਹੋਸਟ ਦੇ ਨਿਕਾਸ ਪਤੇ ਤੋਂ ਵੱਖਰਾ ਹੈ, ਇਸ ਲਈ ਉਹ ਹੋਸਟ ਦੀ ਸੁਰੰਗ ਉੱਤੇ ਨਹੀਂ।
  • ਰਿਜ਼ੌਲਵਰ 10.0.2.3 ਪ੍ਰੌਕਸੀ ਹੈ ਜਾਂ LAN ਸਰਵਰ, ਅਤੇ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿਸਨੇ ਜਵਾਬ ਦਿੱਤਾ।
  • ਜੇ ਸੁਰੰਗ ਦਾ ਡਿਜ਼ਾਈਨ ਸਿਰਫ਼ v4 ਹੈ ਤਾਂ ਮਹਿਮਾਨ ਵਿੱਚ ਕੋਈ ਗਲੋਬਲ v6 ਪਤਾ ਨਹੀਂ।
  • ਹੋਸਟ ਦੀ ਸੁਰੰਗ ਹੇਠਾਂ ਹੋਣ ਵੇਲੇ ਮਹਿਮਾਨ ਬ੍ਰਾਊਜ਼ ਕਰਨਾ ਬੰਦ ਕਰਦਾ ਹੈ, ਜਾਂ ਹੁਣ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਉਹ ਕਦੇ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਨਹੀਂ ਸੀ।
  • ਮਹਿਮਾਨ ਨੂੰ ਉਹ LAN ਪ੍ਰਸਾਰਣ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਦਿਸਦਾ ਜਿਸ ਨਾਲ ਉਸਦਾ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ।

ਸੰਬੰਧਿਤ ਲੇਖ