pfSense ਨੂੰ VPN ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟ ਵਜੋਂ: ਦੋ ਰਾਹ, ਇੱਕ ਰਾਊਟਰ

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

ਕੋਈ ਵੀ ਸੈਟਿੰਗ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਭੂਮਿਕਾਵਾਂ ਦੇ ਨਾਂ ਰੱਖੋ

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

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

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

ਸਰਵਰ ਦੇ ਜਵਾਬ WAN ਰਾਹ ਉੱਤੇ ਰੱਖੋ

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਟਨਲ ਨੂੰ ਆਪਣਾ ਹੀ ਅੰਤ-ਬਿੰਦੂ ਖਾਣ ਨਾ ਦਿਓ

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

ਕਿਹੜੇ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਐਗਜ਼ਿਟ ਮਿਲੇਗਾ ਇਹ ਚੁਣੋ

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

ਐਗਜ਼ਿਟ ਫੇਲ ਹੋਣ ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਇਹ ਤੈਅ ਕਰੋ

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

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

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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