VPN ਰਾਹੀਂ ਸਿਰਫ਼ ਇੱਕ ਨਿੱਜੀ ਸਬਨੈੱਟ ਕਿਵੇਂ ਭੇਜਣਾ ਹੈ

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

ਡਿਜ਼ਾਈਨ ਤੈਅ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ

ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਨੈੱਟਵਰਕ ਮਾਲਕ ਤੋਂ ਸਹੀ ਪ੍ਰੀਫ਼ਿਕਸ ਅਤੇ ਮਾਸਕ ਚਾਹੀਦਾ ਹੈ। 10.x ਨੈੱਟਵਰਕ ਪ੍ਰੀਫ਼ਿਕਸ ਨਹੀਂ ਹੈ; 10.20.0.0/16 ਪ੍ਰੀਫ਼ਿਕਸ ਹੈ। ਪੱਕਾ ਕਰੋ ਕਿ ਇਹ ਤੁਹਾਡੇ ਘਰ ਦੇ LAN, Docker ਬ੍ਰਿਜ ਜਾਂ ਤੁਹਾਡੇ ਚਲਾਏ ਕਿਸੇ ਹੋਰ VPN ਨਾਲ ਓਵਰਲੈਪ ਨਹੀਂ ਹੁੰਦਾ, ਕਿਉਂਕਿ ਓਵਰਲੈਪ ਮਾਰਗ ਨੂੰ ਧੁੰਦਲਾ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕਰਨਲ ਉਹ ਐਂਟਰੀ ਚੁਣ ਲੈਂਦਾ ਹੈ ਜੋ ਤੁਹਾਡਾ ਇਰਾਦਾ ਨਹੀਂ ਸੀ।

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

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

WireGuard: AllowedIPs ਹੀ ਮਾਰਗ ਸਾਰਣੀ ਹੈ

ਕਲਾਇੰਟ ਉੱਤੇ, AllowedIPs ਉਹਨਾਂ ਮੰਜ਼ਿਲਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਜੋ ਟਨਲ ਵਿੱਚ ਆ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ wg-quick ਹਰ ਐਂਟਰੀ ਨੂੰ ਆਮ ਮਾਰਗ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਇਸ ਲਈ ਇਸ ਕੰਮ ਦਾ ਕਲਾਇੰਟ ਅੱਧਾ ਹਿੱਸਾ ਇੱਕ ਲਾਈਨ ਹੈ।

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

ਹੁਣ ਉਸੇ ਕਲਾਇੰਟ ਲਈ ਸਰਵਰ ਦੀ ਐਂਟਰੀ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਉਹ ਦੱਸਦੀ ਹੈ ਕਿ ਸਰਵਰ ਕਲਾਇੰਟ ਨੂੰ ਕੀ ਭੇਜੇਗਾ, ਜੋ ਆਮ ਤੌਰ ਉੱਤੇ ਕਲਾਇੰਟ ਦਾ ਟਨਲ ਪਤਾ ਹੁੰਦਾ ਹੈ, ਨਿੱਜੀ ਸਬਨੈੱਟ ਨਹੀਂ।

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

ਇਹਨਾਂ ਦੋਹਾਂ ਨੂੰ ਬਦਲਣਾ ਹੀ ਸਭ ਤੋਂ ਵੱਧ ਦਿੱਸਣ ਵਾਲੀ ਗਲਤੀ ਹੈ। ਸਰਵਰ ਦੇ peer ਭਾਗ ਹੇਠ 10.20.0.0/16 ਰੱਖਣਾ ਕਹਿੰਦਾ ਹੈ ਕਿ ਪੂਰਾ ਸਬਨੈੱਟ ਉਸ ਕਲਾਇੰਟ ਪਿੱਛੇ ਹੈ, ਅਤੇ ਇਹ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਦਾਅਵਾ ਹੈ, ਇਜਾਜ਼ਤ ਨਹੀਂ। ਕਿਸੇ ਵੀ peer ਦੇ AllowedIPs ਨਾਲ ਨਾ ਮਿਲਣ ਵਾਲੇ ਪੈਕਟ ਚੁੱਪਚਾਪ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਗਲਤ ਐਂਟਰੀ ਬਿਲਕੁਲ ਫ਼ਾਇਰਵਾਲ ਸਮੱਸਿਆ ਵਰਗੀ ਦਿੱਸਦੀ ਹੈ।

ਜੇ ਤੁਸੀਂ ਮਾਰਗ ਆਪ ਸੰਭਾਲਦੇ ਹੋ, ਤਾਂ [Interface] ਹੇਠ Table = off ਸੈੱਟ ਕਰੋ ਅਤੇ ਚਾਹੀਦਾ ਮਾਰਗ ਜੋੜੋ। ਫਿਰ ਕੁਝ ਵੀ ਆਪਣੇ ਆਪ ਨਹੀਂ ਜੁੜਦਾ, ਇਸ ਲਈ ਮਾਰਗ ਉਸੇ ਚੀਜ਼ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇੰਟਰਫ਼ੇਸ ਉੱਪਰ ਲਿਆਉਂਦੀ ਹੈ।

OpenVPN: ਮਾਰਗ ਧੱਕੋ, ਫਿਰ ਪੱਕਾ ਕਰੋ ਕਿ ਉਹ ਪਹੁੰਚਦਾ ਹੈ

ਆਮ ਸਰਵਰ ਉੱਤੇ ਬਦਲਾਅ ਸਰਵਰ ਸੰਰਚਨਾ ਵਿੱਚ ਕਲਾਇੰਟ ਪੂਲ ਦੇ ਕੋਲ ਇੱਕ ਨਿਰਦੇਸ਼ ਹੈ।

push "route 10.20.0.0 255.255.0.0"

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

ਪੂਰੀ ਟਨਲ ਵਾਲੇ ਸਰਵਰ ਦੇ ਸਾਹਮਣੇ ਤੰਗ ਵਿਵਹਾਰ ਚਾਹੁਣ ਵਾਲੇ ਕਲਾਇੰਟ ਨੂੰ ਸਿਰਫ਼ ਉਹ ਹਿੱਸੇ ਅਣਡਿੱਠੇ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਉਸਨੂੰ ਨਹੀਂ ਚਾਹੀਦੇ। OpenVPN 2.4 ਅਤੇ ਬਾਅਦ ਵਿੱਚ, pull-filter ਬਿਲਕੁਲ ਇਸੇ ਲਈ ਹੈ।

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

ਪਤਾ ਪਰਿਵਾਰ ਵੱਖਰੇ ਰੱਖੋ: ਧੱਕਿਆ IPv4 ਮਾਰਗ IPv6 ਵਿੱਚ ਹੱਲ ਹੁੰਦੀ ਅੰਦਰੂਨੀ ਸੇਵਾ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਉਹ ਸੇਵਾ ਟਨਲ ਰਾਹੀਂ ਅਸਫਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕਿ ਬਾਕੀ ਸਭ ਠੀਕ ਦਿੱਸਦਾ ਹੈ।

ਜਦੋਂ ਨਿੱਜੀ ਸਬਨੈੱਟ VPN ਸਰਵਰ ਉੱਤੇ ਨਹੀਂ ਬਲਕਿ ਕਿਸੇ ਹੋਰ ਕਲਾਇੰਟ ਪਿੱਛੇ ਹੈ, ਤਾਂ ਸਰਵਰ ਨੂੰ ਦੱਸਣਾ ਪੈਂਦਾ ਹੈ। client-config-dir ਰਾਹੀਂ ਹਰ ਕਲਾਇੰਟ ਲਈ iroute 10.20.0.0 255.255.0.0 ਵਾਲੀ ਫ਼ਾਈਲ ਜੋੜੋ, ਨਾਲੇ ਮਿਲਦਾ route ਵੀ ਤਾਂ ਜੋ ਹੋਰ ਕਲਾਇੰਟ ਮਾਰਗ ਸਿੱਖਣ। iroute ਤੋਂ ਬਿਨਾਂ ਸਰਵਰ ਕੋਲ ਉਹ ਪ੍ਰੀਫ਼ਿਕਸ ਠੀਕ ਉਸੇ ਟਨਲ ਰਾਹੀਂ ਭੇਜਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਹੈ।

IPsec: ਟ੍ਰੈਫ਼ਿਕ ਸਿਲੈਕਟਰਾਂ ਦਾ ਮਿਲਣਾ ਜ਼ਰੂਰੀ ਹੈ

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

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

ਜੇ ਗੇਟਵੇ ਦੋਹਾਂ ਪਾਸਿਆਂ 0.0.0.0/0 ਨਾਲ ਸੰਰਚਿਤ ਹੈ, ਤਾਂ IKEv2 ਦੀ ਤੰਗੀ ਆਮ ਤੌਰ ਉੱਤੇ ਚਾਈਲਡ SA ਨੂੰ ਦੋ ਪ੍ਰਸਤਾਵਾਂ ਦੇ ਕੱਟ ਤੱਕ ਘਟਾ ਦਿੰਦੀ ਹੈ, ਜੋ ਚਾਹੀਦਾ ਨਤੀਜਾ ਹੈ। ਕੁਝ ਗੇਟਵੇ ਇਸਦੀ ਥਾਂ ਉਹ ਪ੍ਰਸਤਾਵ ਰੱਦ ਕਰਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਦੇ ਸੰਰਚਿਤ ਸਿਲੈਕਟਰਾਂ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ, ਅਤੇ ਲੌਗ ਫਿਰ ਮਾਰਗ ਸ਼ਿਕਾਇਤ ਦੀ ਥਾਂ ਅਸਫਲ ਚਾਈਲਡ SA ਦਿਖਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਬਦਲਾਅ ਗੇਟਵੇ ਦਾ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਮਾਰਗ ਉਸ ਸਿਲੈਕਟਰ ਲਈ ਟਨਲ ਨਹੀਂ ਬਣਾ ਸਕਦਾ ਜਿਸਨੂੰ ਦੂਜਾ ਪਾਸਾ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰੇਗਾ।

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

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

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

ਐਂਡਪੌਇੰਟ ਅਤੇ DNS ਨੂੰ ਫ਼ੈਸਲੇ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

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

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

ਜਾਂਚੋ, ਫਿਰ ਰੀਬੂਟ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਜਾਂਚੋ

ਤਿੰਨ ਟੈਸਟ ਮਾਰਗ ਵਾਲਾ ਸਵਾਲ ਢੱਕ ਦਿੰਦੇ ਹਨ। ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਦੂਰ ਦਾ ਪਤਾ ਕਿੱਥੇ ਜਾਵੇਗਾ, ਸਬਨੈੱਟ ਦੇ ਅੰਦਰੋਂ ਕੁਝ ਲਓ, ਫਿਰ ਪੱਕਾ ਕਰੋ ਕਿ ਆਮ ਜਨਤਕ ਬੇਨਤੀ ਅਜੇ ਵੀ ਤੁਹਾਡੇ ਆਮ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ।

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

ਪਹਿਲੀ ਲਾਈਨ ਇੱਕ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਦੱਸਦੀ ਹੈ। ਜੇ ਉਹ ਤੁਹਾਡੇ ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਦੱਸਦੀ ਹੈ, ਤਾਂ ਮਾਰਗ ਕਦੇ ਪਹੁੰਚਿਆ ਹੀ ਨਹੀਂ। Windows ਉੱਤੇ Find-NetRoute -RemoteIPAddress 10.20.5.7 ਉਸੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਆਖਰੀ ਟੈਸਟ ਵਿੱਚ ਅਜੇ ਵੀ ਤੁਹਾਡਾ ਆਮ ਪਤਾ ਦਿੱਸਣਾ ਚਾਹੀਦਾ ਹੈ, VPN ਸਰਵਰ ਦਾ ਨਹੀਂ।

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

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