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

ਕੁਝ ਵੀ ਕਲੋਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਓ

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

ਫਿਰ ਪੁੱਛੋ ਕਿ ਕੀ ਗੈਸਟ ਟਨਲ ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਇਹੀ ਜਵਾਬ ਅੰਦਰੂਨੀ ਜਾਂ ਸਿਰਫ਼-ਹੋਸਟ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਸਵਾਲ ਹੈ ਜਿਸਨੂੰ ਬਹੁਤੀਆਂ ਲੈਬ-ਲਿਖਤਾਂ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ। ਅੰਤ ਵਿੱਚ ਪੁੱਛੋ ਕਿ ਟਨਲ ਡਿੱਗਣ 'ਤੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਟੋਪੋਲੋਜੀ ਨਹੀਂ, ਨੀਤੀ ਤੈਅ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੋ ਲੈਬ ਸਿਰਫ਼ ਖੁਸ਼ਹਾਲ ਰਾਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਉਸਨੇ ਲਗਭਗ ਕੁਝ ਵੀ ਨਹੀਂ ਪਰਖਿਆ।

What the test requiresRouted gateway VMHost-only guest
Server sees a translated source addressYes, from your own MASQUERADE ruleNo, VirtualBox NAT does it instead
The guest has exactly one egressYes, while the second adapter faces the tunnelOnly until a NAT adapter is attached
Policy is testable during a tunnel failureRules live in one placeRules live on each guest

ਤਿੰਨ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕਾਂ ਨਾਲ ਜੋੜੋ

ਤਿੰਨ ਗੈਸਟ ਅਤੇ ਦੋ ਨਾਮ ਵਾਲੇ ਸੈਗਮੈਂਟ ਵਰਤੋ, ਅਤੇ ਦੋਵਾਂ 'ਤੇ ਐਡਾਪਟਰ ਵਾਲੀ ਇਕੱਲੀ ਮਸ਼ੀਨ ਗੇਟਵੇ ਹੋਵੇ:

VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LAN

ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਲਈ ਕੋਈ ਵੱਖਰਾ ਬਣਾਉਣ ਦਾ ਕਦਮ ਨਹੀਂ ਹੈ। --intnet1 ਵਿੱਚਲੀ ਸਟ੍ਰਿੰਗ ਹੀ ਸੈਗਮੈਂਟ ਹੈ: ਦੋ ਮਸ਼ੀਨਾਂ ਇਸਨੂੰ ਸਿਰਫ਼ ਤਦ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਨਾਮ ਬਿਲਕੁਲ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਹੋਸਟ 'ਤੇ ਕੁਝ ਵੀ ਇਸ ਨਾਲ ਜੁੜਿਆ ਨਹੀਂ। ਇਹੀ ਆਖਰੀ ਗੁਣ ਲੈਬ ਦੇ ਸਾਫ਼-ਸੁਥਰੇ ਦੁਹਰਾਉ ਦਾ ਕਾਰਨ ਹੈ, ਕਿਉਂਕਿ ਹੋਸਟ ਦੇ ਰਾਊਟ, ਇਸਦਾ ਆਪਣਾ VPN ਕਲਾਇੰਟ ਅਤੇ ਇਸਦਾ ਫਾਇਰਵਾਲ ਕਿਸੇ ਹਾਦਸੇ ਨਾਲ ਗੈਸਟਾਂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੇ। ਅੰਦਰੂਨੀ ਸੈਗਮੈਂਟ ਵਿੱਚ DHCP ਸਰਵਰ ਵੀ ਨਹੀਂ ਹੁੰਦਾ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇੱਕ ਨਾ ਜੋੜੋ, ਇਸ ਲਈ ਸਥਿਰ ਪਤੇ ਸਭ ਤੋਂ ਛੋਟਾ ਰਾਹ ਹਨ।

ਕਲਾਇੰਟ ਨੂੰ ਸਿਰਫ਼ ਇਸਦਾ WAN ਪਤਾ ਦਿਓ, ਅਤੇ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਗੇਟਵੇ ਦੇ WAN ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੇ। ਸਰਵਰ ਨੂੰ LAN ਪਤਾ ਮਿਲਦਾ ਹੈ ਅਤੇ ਇਹ ਗੇਟਵੇ ਦੇ LAN ਪਤੇ ਨੂੰ ਆਪਣਾ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਬਣਾਉਂਦਾ ਹੈ। ਜੋ ਗੈਸਟ ਇੱਕ ਸੈਗਮੈਂਟ 'ਤੇ ਦੋ ਪਤੇ ਰੱਖਦਾ ਹੈ, ਜਾਂ ਦੂਜੇ ਸੈਗਮੈਂਟ ਵੱਲ ਭਟਕਿਆ ਹੋਇਆ ਰਾਊਟ ਰੱਖਦਾ ਹੈ, ਉਸ ਕੋਲ ਰਾਊਟਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਰਾਹ ਹੈ, ਅਤੇ ਹੇਠਾਂ ਦੇ ਟੈਸਟ ਤੁਹਾਨੂੰ ਝੂਠ ਬੋਲਣਗੇ।

VM ਨਾਵਾਂ ਦੇ ਕੋਲ ਮੈਂ ਚਾਰ ਪਤਿਆਂ ਅਤੇ ਦੋ ਸੈਗਮੈਂਟ ਨਾਵਾਂ ਵਾਲੀ ਟੈਕਸਟ ਫਾਈਲ ਰੱਖਦਾ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਹਰ ਸ਼ੈੱਲ ਵਿੱਚ ਪੇਸਟ ਕਰਦਾ ਹਾਂ। ਹਫ਼ਤਿਆਂ ਬਾਅਦ, ਜਦੋਂ ਪ੍ਰੋਫ਼ਾਈਲ ਬਦਲਾਅ ਕੁਝ ਤੋੜ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਹੀ ਫਾਈਲ ਪ੍ਰੋਫ਼ਾਈਲ ਡੀਬੱਗ ਕਰਨ ਅਤੇ ਆਪਣੀ ਯਾਦਸ਼ਕਤੀ ਡੀਬੱਗ ਕਰਨ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੁੰਦੀ ਹੈ।

ਜਿਸ ਸੈਗਮੈਂਟ ਵਿੱਚੋਂ ਲੀਕ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਉਸ ਲਈ ਅੰਦਰੂਨੀ ਜਾਂ ਸਿਰਫ਼-ਹੋਸਟ ਚੁਣੋ

ਸਿਰਫ਼-ਹੋਸਟ ਮੋਡ ਹੋਸਟ 'ਤੇ ਹੀ ਇੱਕ ਵਰਚੁਅਲ ਐਡਾਪਟਰ ਬਣਾਉਂਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ vboxnet0, ਅਤੇ ਹੋਸਟ ਨੂੰ ਗੈਸਟ ਦੇ ਸੈਗਮੈਂਟ 'ਤੇ ਪਤਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਪ੍ਰਸ਼ਾਸਨ ਲਈ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਅਲੱਗਾਅ ਟੈਸਟ ਲਈ ਘਾਤਕ ਹੈ, ਕਿਉਂਕਿ ਹੋਸਟ ਹੁਣ ਗੈਸਟ ਤੱਕ ਸਿੱਧਾ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਅਤੇ ਹੋਸਟ ਵਾਲੇ ਪਾਸੇ ਦੀ ਹਰ ਸੇਵਾ ਸੰਭਾਵੀ ਰਾਹ ਬਣ ਜਾਂਦੀ ਹੈ। ਅੰਦਰੂਨੀ ਮੋਡ ਵਿੱਚ ਹੋਸਟ ਐਡਾਪਟਰ ਬਿਲਕੁਲ ਨਹੀਂ ਹੁੰਦਾ। ਦੋਵੇਂ ਮੋਡ ਨੈੱਟਵਰਕ ਸੈਟਿੰਗਾਂ ਪੈਨਲ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਉਲਝ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਲੇਬਲ ਨਹੀਂ, ਦਸਤਾਵੇਜ਼ੀ ਫ਼ਰਕ ਜਾਂਚੋ (VirtualBox ਨੈੱਟਵਰਕਿੰਗ ਵੇਰਵੇ ਪੰਨਾ ਵੇਖੋ)।

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

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

ਤੁਸੀਂ ਜੋ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹੋ ਉਹੀ ਅਲੱਗਾਅ ਹੈ ਜੋ ਤੁਸੀਂ ਸੰਰਚਿਤ ਕੀਤਾ ਹੈ। ਇੱਕ ਅੰਦਰੂਨੀ ਐਡਾਪਟਰ, ਗੇਟਵੇ 'ਤੇ ਡਿਫ਼ਾਲਟ ਰਾਊਟ ਅਤੇ NAT ਐਡਾਪਟਰ ਨਾ ਹੋਣ ਵਾਲੇ ਗੈਸਟ ਕੋਲ ਗੇਟਵੇ ਨੂੰ ਟਾਲਣ ਵਾਲਾ ਰਾਹ ਨਹੀਂ ਹੁੰਦਾ। ਸਿਰਫ਼-ਹੋਸਟ ਐਡਾਪਟਰ ਅਤੇ NAT ਐਡਾਪਟਰ ਵਾਲੇ ਗੈਸਟ ਕੋਲ ਦੋ ਰਾਹ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਉਹ ਰਾਹ ਹੈ ਜੋ ਤੁਸੀਂ ਪਰਖਣਾ ਚਾਹੁੰਦੇ ਸੀ।

ਗੇਟਵੇ 'ਤੇ ਰਾਊਟ ਅਤੇ ਅਨੁਵਾਦ ਕਰੋ, ਫਿਰ ਇਸਨੂੰ ਬੰਦ ਹੋ ਕੇ ਅਸਫਲ ਹੋਣ ਦਿਓ

VirtualBox ਸੈਗਮੈਂਟਾਂ ਵਿਚਕਾਰ ਫਾਰਵਰਡ ਨਹੀਂ ਕਰਦਾ; ਗੈਸਟ ਕਰਦਾ ਹੈ। VPN ਸਰਵਰ VM ਗੇਟਵੇ ਦੇ ਪਿੱਛੇ ਹੋਣ 'ਤੇ ਫਾਰਵਰਡਿੰਗ ਸਮਰੱਥ ਕਰੋ ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਟ੍ਰੈਫ਼ਿਕ ਦਾ ਅਨੁਵਾਦ ਕਰੋ ਜਦੋਂ ਇਹ ਸਰਵਰ ਵੱਲ ਨਿਕਲਦੀ ਹੈ:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

ਉਸ ਨਿਯਮ ਨਾਲ ਸਰਵਰ ਕਲਾਇੰਟ ਦੀ ਥਾਂ ਗੇਟਵੇ ਦਾ LAN ਪਤਾ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਆਪਰੇਟਰ NAT ਪਿੱਛੇ ਦਾ ਅਸਲੀ ਕਲਾਇੰਟ ਨੈੱਟਵਰਕ ਦੇ ਸਿਰ ਨੂੰ ਇੰਝ ਹੀ ਦਿਸਦਾ ਹੈ। sysctl ਮੁੱਲ /etc/sysctl.d/ ਵਿੱਚ ਅਤੇ ਨਿਯਮ ਉਸ ਫਾਇਰਵਾਲ ਸੇਵਾ ਵਿੱਚ ਸੰਭਾਲੋ ਜੋ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਵਰਤਦੀ ਹੈ, ਨਹੀਂ ਤਾਂ ਰੀਬੂਟ ਲੈਬ ਨੂੰ ਚੁੱਪਚਾਪ ਰਾਊਟ ਕੀਤੀ ਪਰ ਅਨੁਵਾਦ ਨਾ ਕੀਤੀ ਹਾਲਤ ਵਿੱਚ ਵਾਪਸ ਲੈ ਆਵੇਗਾ।

ਫਾਰਵਰਡਿੰਗ ਅਧਿਕਾਰ ਨਹੀਂ ਹੈ। ACCEPT ਦੀ ਡਿਫ਼ਾਲਟ FORWARD ਨੀਤੀ ਅਧੀਨ, ਜਿਸ ਗੈਸਟ ਦਾ ਡਿਫ਼ਾਲਟ ਰਾਊਟ ਗੇਟਵੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਉਹ ਟਨਲ ਹੋਵੇ ਜਾਂ ਨਾ ਹੋਵੇ, ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਵੱਲੋਂ ਚੁਣੇ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਨਿਕਲਦਾ ਹੈ। ਜੇ ਗੇਟਵੇ ਕੋਲ ਪੈਕੇਜ ਇੰਸਟਾਲ ਲਈ NAT ਐਡਾਪਟਰ ਵੀ ਹੈ, ਤਾਂ ਟਨਲ ਡਿੱਗਣ ਵਾਲੇ ਪਲ ਉਹ ਐਡਾਪਟਰ ਕੰਮ ਕਰਦਾ ਅਣ-ਇੰਕ੍ਰਿਪਟਿਡ ਨਿਕਾਸ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਸਿਰਫ਼-VPN ਟੈਸਟ ਕਦੇ ਵੀ ਸਿਰਫ਼-VPN ਟੈਸਟ ਨਹੀਂ ਸੀ।

ਜਦੋਂ ਸਰਵਰ ਦੂਰ ਹੋਵੇ ਅਤੇ ਟਨਲ ਗੇਟਵੇ ਆਪ ਹੀ ਖ਼ਤਮ ਕਰੇ, ਤਾਂ ਉਹੀ ਫੈਸਲਾ ਇੰਟਰਨੈੱਟ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੇ NIC ਵੱਲ ਨਹੀਂ, ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ:

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ਟਨਲ ਦੀ ਆਪਣੀ ਬਾਹਰੀ ਢੋਆ-ਢੁਆਈ ਅਤੇ ਬੈਂਡ ਤੋਂ ਬਾਹਰ ਦਾ ਪ੍ਰਬੰਧਨ ਰਾਹ ਫਾਰਵਰਡ ਹੋਣ ਵਾਲੀ ਟ੍ਰੈਫ਼ਿਕ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਜੇ ਗੇਟਵੇ ਠੀਕ ਕਰਨ ਦਾ ਇਕੱਲਾ ਰਾਹ ਉਹੀ ਟਨਲ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਡੀਬੱਗ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਲੈਬ ਤਾਲਾਬੰਦੀ ਦੀ ਕਸਰਤ ਬਣ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਸੀਰੀਅਲ ਕੰਸੋਲ, ਸਿਰਫ਼-ਹੋਸਟ ਪ੍ਰਬੰਧਨ ਐਡਾਪਟਰ, ਜਾਂ ਜਾਣੀ-ਪਛਾਣੀ ਚੰਗੀ ਹਾਲਤ ਦਾ ਸਨੈਪਸ਼ਾਟ ਹੱਥੀਂ ਟੁੱਟੇ ਰਾਊਟਰ ਨੂੰ ਵਾਪਸ ਲੈਣ ਨਾਲੋਂ ਸਸਤਾ ਹੈ।

ਰਾਹ ਹੋਸਟ ਤੋਂ ਨਹੀਂ, ਗੈਸਟ ਤੋਂ ਪਰਖੋ

ਬਾਹਰ ਵੱਲ ਕੰਮ ਕਰੋ। ਪੱਕਾ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਗੇਟਵੇ ਦੇ WAN ਪਤੇ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਫਿਰ ਗੇਟਵੇ ਰਾਹੀਂ ਸਰਵਰ ਤੱਕ, ਫਿਰ VPN ਪੋਰਟ ਤੱਕ ਦਾ ਕਨੈਕਸ਼ਨ ਨਿਕਲਦਾ ਅਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਗੇਟਵੇ ਦੇ ਦੋਵਾਂ ਇੰਟਰਫ਼ੇਸਾਂ 'ਤੇ ਕੈਪਚਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਜਵਾਬ ਆਉਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਵਾਪਸੀ ਰਾਹ 'ਤੇ ਸੁੱਟਿਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਜਿਸਨੂੰ ਸਿਰਫ਼ ਕਲਾਇੰਟ 'ਤੇ ਕੈਪਚਰ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦਾ:

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

ਫਿਰ ਨਿਕਾਸ ਸਾਬਤ ਕਰੋ। ਗੈਸਟ ਤੋਂ ਪਤਾ-ਪ੍ਰਤੀਬਿੰਬ ਸੇਵਾ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਹ ਕਿਹੜਾ ਸਰੋਤ ਦੇਖਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਗੇਟਵੇ ਦੇ ਆਪਣੇ ਨਿਕਾਸ ਪਤੇ ਨਾਲ ਤੁਲਨਾ ਕਰੋ; ਜੇ ਜਵਾਬ ਹੋਸਟ ਦੇ ਪਤੇ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਟਨਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਰਾਹ ਮੌਜੂਦ ਹੈ। ਜਾਂਚੋ ਕਿ ਗੈਸਟ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਰਿਜ਼ੌਲਵਰ ਵਰਤਦਾ ਹੈ, ਅਤੇ IPv6 ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਜਿਸ ਸੈਗਮੈਂਟ ਵਿੱਚ IPv6 ਸਮਰੱਥ ਹੈ ਪਰ ਟਨਲ ਸਿਰਫ਼ IPv4 ਢੋਂਦੀ ਹੈ ਉਹ ਹਾਦਸੇ ਨਾਲ ਨਹੀਂ, ਡਿਜ਼ਾਈਨ ਕਰਕੇ ਲੀਕ ਹੁੰਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਇਸਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਤੋੜੋ। ਟਨਲ ਰੋਕੋ, ਜਾਂ ਇਸਦਾ ਬਾਹਰੀ ਪੋਰਟ ਬਲਾਕ ਕਰੋ, ਅਤੇ ਗੈਸਟ ਤੋਂ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹੋ। ਇਹ ਅਸਫਲ ਹੋਣਾ ਹੀ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਾਰਨ ਅਜਿਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਨਾਮ ਦੇ ਸਕੋ: ਕੋਈ ਰਾਊਟ ਨਹੀਂ, ਇੱਕ ਅਸਵੀਕਾਰ ਨਿਯਮ ਹੈ, ਜਾਂ ਰਿਜ਼ੌਲਵਰ ਮਰਿਆ ਹੋਇਆ ਹੈ। ਟਨਲ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਗੈਸਟ ਨੈੱਟਵਰਕ ਦੁਬਾਰਾ ਬਣਾਏ ਬਿਨਾਂ ਸੁਧਰ ਜਾਂਦਾ ਹੈ। ਜੇ Hamachi ਜਾਂ ZeroTier ਵਰਗਾ ਮੈਸ਼ VPN ਲੈਬ ਸਾਂਝੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਯਾਦ ਰੱਖੋ ਕਿ ਬ੍ਰਿਜ ਕੀਤਾ ਐਡਾਪਟਰ ਮੈਸ਼ ਨਹੀਂ, ਐਡਾਪਟਰ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਵੱਲੋਂ ਆਪਣਾ ਵਰਚੁਅਲ ਐਡਾਪਟਰ ਇੰਸਟਾਲ ਕਰਨ ਤੋਂ ਬਾਅਦ ਬ੍ਰਿਜ ਦੁਬਾਰਾ ਨਿਰਦੇਸ਼ਿਤ ਕਰਨਾ ਪਵੇਗਾ।

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

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

ਸੰਬੰਧਿਤ ਲੇਖ