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

ਫੈਸਲਾ ਕਰੋ ਕਿ ਰੂਟ ਸੇਵਾ ਦਾ ਹੈ ਜਾਂ ਸੈਸ਼ਨ ਦਾ

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

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

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

ਮੌਜੂਦਾ ਰੂਟ ਅਤੇ ਸੇਵਾ ਸਥਿਤੀ ਪੜ੍ਹੋ

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

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

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

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

networksetup ਨਾਲ ਪ੍ਰੀਫਿਕਸ ਸੰਭਾਲੋ

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

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

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

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

route add ਸਿਰਫ਼ ਪਰਖ ਲਈ ਵਰਤੋ

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

sudo route -n add -net 10.20.0.0/16 -interface utun4

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

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

ਹੁੱਕ ਸਿਰਫ਼ ਤਦ ਚੁਣੋ ਜਦੋਂ ਪਤੇ ਦੀ ਗੱਲਬਾਤ ਹੁੰਦੀ ਹੈ

PPP-ਅਧਾਰਿਤ ਲਿੰਕਾਂ ਲਈ, ਜਿਵੇਂ L2TP, macOS ਲਿੰਕ ਸਥਾਪਿਤ ਹੋਣ ਤੋਂ ਬਾਅਦ /etc/ppp/ip-up ਚਲਾਉਂਦਾ ਹੈ। ਸਕ੍ਰਿਪਟ ਨੂੰ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਅਤੇ ਗੱਲਬਾਤ ਕੀਤੇ ਸਥਾਨਕ ਤੇ ਦੂਰ ਦੇ ਪਤੇ ਮਿਲਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਸਰਵਰ ਵੱਲੋਂ ਦਿੱਤੇ ਪੀਅਰ ਉੱਤੇ ਨਿਰਭਰ ਰੂਟ ਜੋੜ ਸਕਦੀ ਹੈ। ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਸਥਿਤੀ ਹੈ ਜੋ ਸਥਿਰ ਸੇਵਾ ਰੂਟ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰ ਸਕਦਾ।

IKEv2 ਅਤੇ ਵਿਕਰੇਤਾ ਕਲਾਇੰਟ ਹੋ ਸਕਦਾ ਹੈ ਉਸ PPP ਮਾਰਗ ਦੀ ਬਿਲਕੁਲ ਵਰਤੋਂ ਨਾ ਕਰਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਸਕ੍ਰਿਪਟ ਪੂਰੇ ਸੈਸ਼ਨ ਦੌਰਾਨ ਚੁੱਪ ਰਹਿ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, scutil --nc status ਨੂੰ ਪੁੱਛਣ ਵਾਲਾ ਅਤੇ ਸਥਿਤੀ ਬਦਲਾਅ ਉੱਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ launchd ਕੰਮ ਬਰਾਬਰ ਦਾ ਵਿਧੀ ਹੈ, ਥੋੜ੍ਹੀ ਦੇਰੀ ਨਾਲ।

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

ਨਿੱਜੀ ਮੰਜ਼ਿਲ, ਆਮ ਬ੍ਰਾਊਜ਼ਿੰਗ ਅਤੇ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਜਾਂ ਨੀਂਦ ਚੱਕਰ ਜਾਂਚ ਕੇ ਮੁਕਾਓ। ਫਿਰ scutil --dns ਜਾਂਚੋ, ਕਿਉਂਕਿ ਨਾਮ ਹੱਲ ਵੱਖਰੀ ਨੀਤੀ ਹੈ ਅਤੇ ਚੱਲਦਾ ਰੂਟ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਨਿੱਜੀ ਨਾਮ ਹੱਲ ਹੁੰਦੇ ਹਨ।

ਸੰਬੰਧਿਤ ਲੇਖ