pfSense OpenVPN: ਕਿਸੇ ਹੋਰ ਰਾਊਟਰ ਪਿੱਛੇ ਵਾਲੇ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚਣਾ

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

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

ਇੱਕ ਪੈਕਟ, ਤਿੰਨ ਰੂਟਿੰਗ ਫ਼ੈਸਲੇ

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

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

ਕਲਾਇੰਟ ਨੂੰ ਪ੍ਰੀਫਿਕਸ ਦਿਓ, ਅੰਦਾਜ਼ਾ ਨਹੀਂ

IPv4 ਟਨਲ ਨੈੱਟਵਰਕ /30 ਤੋਂ ਵੱਡਾ ਹੋਣ ਵਾਲੇ pfSense SSL/TLS ਸਰਵਰ 'ਤੇ, IPv4 Local network(s) ਫ਼ੀਲਡ ਜੁੜਨ ਸਮੇਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਰੂਟ ਵੰਡਦੀ ਹੈ। ਕਲਾਇੰਟ ਆਪਣੇ ਆਪ ਇੱਕ ਬਣਾ ਲਵੇਗਾ ਇਸ ਭਰੋਸੇ ਦੀ ਥਾਂ ਹੇਠਲਾ ਪ੍ਰੀਫਿਕਸ ਉੱਥੇ ਜੋੜੋ। ਫਿਰ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ ਦੀ ਅਸਲ ਸਾਰਣੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ route-nopull ਵਾਲੀ ਪ੍ਰੋਫ਼ਾਈਲ ਜਾਂ ਰੂਟ ਫਿਲਟਰ ਸਰਵਰ ਵੱਲੋਂ ਭੇਜਿਆ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦੇ ਹਨ। ਸਰਵਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਕਲਾਇੰਟ ਕੁਝ ਵੀ ਇੰਸਟਾਲ ਨਹੀਂ ਕਰਦਾ।

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

pfSense ਨੂੰ ਅੰਦਰੂਨੀ ਰਾਊਟਰ ਵੱਲ ਮੋੜੋ

pfSense ਵਿੱਚ ਸਥਿਰ ਰੂਟ ਲਈ ਪਰਿਭਾਸ਼ਿਤ ਅਤੇ ਪਹੁੰਚਯੋਗ ਗੇਟਵੇ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਸ ਗੇਟਵੇ ਲਈ ਚੁਣਿਆ ਇੰਟਰਫ਼ੇਸ ਉਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਉੱਥੇ ਪਹੁੰਚਦਾ ਹੈ, ਜਿਵੇਂ Netgate ਦੀ ਸਥਿਰ-ਰੂਟ ਗਾਈਡ ਦੱਸਦੀ ਹੈ। ਇੱਕ ਉਦਾਹਰਨ ਬਣਤਰ ਵਿੱਚ ਟ੍ਰਾਂਜ਼ਿਟ ਲਿੰਕ ਫਾਇਰਵਾਲ 'ਤੇ 192.168.77.1 ਅਤੇ ਅੰਦਰੂਨੀ ਰਾਊਟਰ 'ਤੇ 192.168.77.2 ਹੈ, ਅਤੇ ਸੇਵਾ ਨੈੱਟਵਰਕ ਉਸਦੇ ਪਿੱਛੇ 172.16.30.0/25 'ਤੇ ਹੈ। ਫਿਰ ਰੂਟ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਅਗਲੇ ਹੌਪ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ, ਸੇਵਾ ਦੇ ਪਤੇ ਦਾ ਨਹੀਂ। ਦੂਰ ਦੇ ਨੈੱਟਵਰਕ ਦਾ ਪਤਾ ਗੇਟਵੇ ਵਜੋਂ ਵਰਤਣਾ ਇੱਕ ਆਮ ਢੰਗ ਹੈ ਜੋ ਸਹੀ ਦਿਸਣ ਵਾਲਾ ਪਰ ਕਿਤੇ ਵੀ ਫਾਰਵਰਡ ਨਾ ਕਰਨ ਵਾਲਾ ਰੂਟ ਬਣਾਉਂਦਾ ਹੈ।

ਇੰਟਰਫ਼ੇਸ ਨੂੰ ਨਾਮ ਦੇਣਾ ਉਸਦੇ ਪਿੱਛੇ ਦੇ ਨੈੱਟਵਰਕਾਂ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦਾ। ਸਥਿਰ ਰੂਟ ਹੀ ਉਹ ਵਰਣਨ ਹੈ।

ਦੂਰ ਵਾਲੇ ਪਾਸੇ ਨੂੰ ਪੂਲ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਇਸ ਡਿਜ਼ਾਈਨ ਲਈ ਕੋਈ ਅਨੁਵਾਦ ਲੋੜੀਂਦਾ ਨਹੀਂ, ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਸਰੋਤ ਪਤਾ ਦਿਸਦਾ ਰੱਖਣ ਨਾਲ ਹੇਠਲਾ ਨੈੱਟਵਰਕ ਆਪਣੀ ਨੀਤੀ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ।

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

ਤਿੰਨ ਮਾਲਕਾਂ ਦੀ ਯੋਜਨਾ ਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ ਸੰਭਾਲੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਪ੍ਰਸ਼ਾਸਕ ਰਾਹ ਨੂੰ ਦੁਬਾਰਾ ਲੱਭਣ ਦੀ ਥਾਂ ਮੁੜ ਬਣਾ ਸਕੇ।