Access Server ਗੇਟਵੇ ਵਰਤੋਂਕਾਰ: ਕਲਾਇੰਟ ਦੀ ਸ਼ਾਖਾ LAN ਦੀ ਰੂਟਿੰਗ

OpenVPN ਕਲਾਇੰਟ ਦੇ ਟਨਲ ਪਤੇ ਨੂੰ ping ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਪਰ ਉਸ ਦੇ ਪਿੱਛੇ ਦੀ LAN ਉੱਤੇ ਕਿਸੇ ਵੀ ਹੋਸਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ ਜਾ ਸਕਦਾ। Access Server ਕਲਾਇੰਟ ਨੂੰ VPN ਪੂਲ ਤੋਂ ਪਤਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਪੂਲ ਦਾ ਪਤਾ ਹੀ ਉਹ ਇਕੋ ਚੀਜ਼ ਹੈ ਜਿਸ ਨੂੰ ਸਰਵਰ ਆਪਣਾ ਮੰਨਦਾ ਹੈ। ਸ਼ਾਖਾ ਦਾ ਪ੍ਰੀਫਿਕਸ ਵੱਖਰਾ ਤੱਥ ਹੈ ਜੋ ਘੋਸ਼ਿਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਵੀ ਸ਼ਾਖਾ ਨੂੰ ਫਾਰਵਰਡਰ ਅਤੇ ਮੁੱਖ ਦਫ਼ਤਰ ਨੂੰ ਵਾਪਸੀ ਰਾਹ ਚਾਹੀਦਾ ਹੈ। ਗਲਤ ਥਾਂ ਲਿਖਿਆ ਰਾਹ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।

ਦੋ ਪਤੇ, ਦੋ ਵੱਖਰੇ ਮਾਲਕੀ ਦਾਅਵੇ

ਜਦੋਂ ਕਲਾਇੰਟ ਜੁੜਦਾ ਹੈ ਤਾਂ Access Server ਉਸ ਨੂੰ ਸੰਰਚਿਤ VPN ਪੂਲ ਤੋਂ ਪਤਾ ਦਿੰਦਾ ਹੈ, ਉਦਾਹਰਨ 10.90.0.0/24। ਉਹ ਵੰਡ ਇੱਕ ਹੋਸਟ ਲਈ ਕਿਰਾਇਆ ਹੈ। ਉਹੀ ਕਲਾਇੰਟ 10.60.0.0/24 ਦੇ ਸਾਹਮਣੇ ਵੀ ਹੈ, ਇਹ ਜੁੜਾਅ ਨਹੀਂ ਦੱਸਦਾ, ਅਤੇ ਸਰਵਰ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਾਵੇਗਾ: ਪ੍ਰਸ਼ਾਸਕ ਵੱਲੋਂ ਘੋਸ਼ਿਤ ਕਰਨ ’ਤੇ ਹੀ LAN ਪ੍ਰੀਫਿਕਸ ਕਿਸੇ ਖ਼ਾਸ ਕਲਾਇੰਟ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੁੰਦਾ ਹੈ।

ਇਸ ਲਈ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ ਉੱਤੇ ਸਥਿਰ ਰਾਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਰਾਹ ਕਹਿੰਦਾ ਹੈ 10.60.0.0/24 ਇਸ ਪਤੇ ’ਤੇ ਭੇਜੋ, ਪਰ ਜੇ ਪਤਾ ਉਸ ਕਲਾਇੰਟ ਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕਦੇ ਗੇਟਵੇ ਵਜੋਂ ਨਿਸ਼ਾਨਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਉਹ ਪੈਕੇਟ ਉੱਥੇ ਪਹੁੰਚਾਉਣ ਦਾ ਕਾਰਨ ਸਰਵਰ ਕੋਲ ਨਹੀਂ, ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਸਟੈਕ ਉਨ੍ਹਾਂ ਨੂੰ ਸੁੱਟ ਸਕਦਾ ਹੈ। ਘੋਸ਼ਣਾ ਅਤੇ ਰਾਹ ਇੱਕੋ ਵਿਵਸਥਾ ਦੇ ਦੋ ਅੱਧ ਹਨ।

ਗੇਟਵੇ ਸੈਟਿੰਗ ਅਸਲ ਵਿੱਚ ਕੀ ਸਥਾਪਿਤ ਕਰਦੀ ਹੈ

Admin Web UI ਵਿੱਚ ਘੋਸ਼ਣਾ ਵਰਤੋਂਕਾਰ ਗੁਣ ਹੈ: connector ਵਰਤੋਂਕਾਰ ’ਤੇ Configure VPN gateway ਸਮਰੱਥ ਕਰੋ ਅਤੇ ਸ਼ਾਖਾ ਦਾ ਅਸਲ ਪ੍ਰੀਫਿਕਸ Network on the VPN client side ਵਿੱਚ ਭਰੋ। ਉਹ ਵਰਤੋਂਕਾਰ ਹੋਰਾਂ ਵਾਂਗ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਵਾਲੇ ਯੰਤਰ ਲਈ ਢੁਕਵੀਂ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਸਵੈ-ਲਾਗਇਨ ਪ੍ਰੋਫ਼ਾਈਲ ਭੇਤ ਹੈ।

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

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

ਦੋਵੇਂ ਨੈੱਟਵਰਕਾਂ ਦੇ ਵਾਪਸੀ ਰਾਹ ਪੂਰੇ ਕਰੋ

ਠੋਸ ਯੋਜਨਾ: ਮੁੱਖ ਦਫ਼ਤਰ 10.40.0.0/24, ਸ਼ਾਖਾ 10.60.0.0/24, VPN ਪੂਲ 10.90.0.0/24, ਅਤੇ Access Server ਮੁੱਖ ਦਫ਼ਤਰ ਵਾਲੇ ਪਾਸੇ ਨਿੱਜੀ ਪਤੇ ’ਤੇ ਉਪਲਬਧ। ਰਾਊਟਰ ਨੂੰ ਸ਼ਾਖਾ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਪੂਲ ਲਈ ਰਾਹ ਚਾਹੀਦੇ ਹਨ, ਦੋਵੇਂ Access Server ਵੱਲ। ਨਾ ਹੋਣ ’ਤੇ ਜਵਾਬ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਅੱਧ-ਖੁੱਲ੍ਹਾ ਜੁੜਾਅ ਬਣਦਾ ਹੈ।

ਸ਼ਾਖਾ ਵਿੱਚ connector ਨੂੰ ਉਹ ਪੈਕੇਟ ਅੱਗੇ ਭੇਜਣੇ ਪੈਂਦੇ ਹਨ ਜੋ ਉਸ ਨੂੰ ਸੰਬੋਧਿਤ ਨਹੀਂ: OS ਵਿੱਚ IP ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਟਨਲ ਤੇ LAN ਇੰਟਰਫ਼ੇਸਾਂ ਤੱਕ ਸੀਮਿਤ ਆਗਿਆ; Linux ’ਤੇ net.ipv4.ip_forward=1 ਫਾਰਵਰਡ ਚੇਨ ਨਿਯਮਾਂ ਨਾਲ, Windows ’ਤੇ routing and remote access। ਫਿਰ ਹੋਸਟਾਂ ਨੂੰ ਵਾਪਸੀ ਰਾਹ ਚਾਹੀਦਾ ਹੈ: connector ਉਨ੍ਹਾਂ ਦਾ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ, ਜਾਂ ਮੌਜੂਦਾ ਗੇਟਵੇ ਖ਼ਾਸ ਰਾਹ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ।

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

ਅਸਫ਼ਲਤਾ ਨੂੰ ਰਾਹ ਵਜੋਂ ਪੜ੍ਹੋ

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

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

ਦੋ ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ ਵੱਧ ਚਾਹੀਦਾ ਹੈ। ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਓਵਰਲੈਪ ਹੁੰਦੇ ਪ੍ਰੀਫਿਕਸ ਮੰਜ਼ਿਲ ਨੂੰ ਅਸਪਸ਼ਟ ਕਰਦੇ ਹਨ ਅਤੇ ਮੁੜ-ਨੰਬਰੀਕਰਨ ਜਾਂ ਅਨੁਵਾਦ ਚਾਹੀਦਾ ਹੈ; ਕਲਸਟਰ Access Server ਵਿੱਚ ਹਰ ਨੋਡ ਕੋਲ ਸ਼ਾਖਾ connector ਤੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰਾਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤਬਦੀਲੀਆਂ ਆਮ ਸੰਭਾਲ ਤੇ ਅੱਪਡੇਟ ਰਾਹੀਂ ਲਾਗੂ ਕਰੋ, connector ਮੁੜ ਜੋੜੋ ਅਤੇ ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੋਂ ਮੁੜ ਜਾਂਚੋ; ਹਰ ਮਸ਼ੀਨ ਦਾ ਪੂਰਾ ਰੀਬੂਟ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਨਹੀਂ।

Access Server ਦਾ site-to-site ਟਿਊਟੋਰਿਅਲ ਉਹੀ ਸੈਟਿੰਗਾਂ ਉਤਪਾਦ ਕ੍ਰਮ ਵਿੱਚ ਦੱਸਦਾ ਹੈ; ਡਿਜ਼ਾਈਨ ਮਿਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਵਾਰ ਇਸ ਨੂੰ ਲਿਆਉਣਾ ਠੀਕ ਹੈ।