ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਉੱਤੇ ASA DHCP ਰੀਲੇ: ਕਦਮ-ਦਰ-ਕਦਮ ਗਾਈਡ

ਰੀਲੇ ਤਿੰਨ ਪੜਾਵਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਵਿਚਕਾਰਲਾ ਪੜਾਅ ਹੀ VPN ਪਾਰ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ ਸ਼ਾਖਾ ਸੈਗਮੈਂਟ ਉੱਤੇ ਬ੍ਰੌਡਕਾਸਟ ਭੇਜਦਾ ਹੈ, ASA ਉਸ ਬ੍ਰੌਡਕਾਸਟ ਨੂੰ DHCP ਸਰਵਰ ਵੱਲ ਯੂਨੀਕਾਸਟ ਬੇਨਤੀ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਕਲਾਇੰਟ ਦੀ ਥਾਂ ਰੀਲੇ ਪਤੇ ਨੂੰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੜਾਅ ਪਾਰ ਕਰੋ, ਅਤੇ «ਰੀਲੇ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ» ਵਾਲੇ ਬਹੁਤੇ ਕੇਸ ਗੁੰਮ ਨੀਤੀ ਜਾਂ ਗਲਤ ਪੜ੍ਹੀ setroute ਲਾਈਨ ’ਤੇ ਆ ਕੇ ਖ਼ਤਮ ਹੁੰਦੇ ਹਨ।

ਪਹਿਲਾ ਪੜਾਅ: ਕਲਾਇੰਟ ਵੱਲ ਵਾਲੇ ਇੰਟਰਫ਼ੇਸ ’ਤੇ ਰੀਲੇ ਸਮਰੱਥ ਕਰੋ

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

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

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

ਦੂਜਾ ਪੜਾਅ: ASA ਵੱਲੋਂ ਪੈਦਾ ਕੀਤਾ ਟ੍ਰੈਫ਼ਿਕ ਟਨਲ ਰਾਹੀਂ ਲੈ ਜਾਓ

ਇਹ ਉਹ ਪੜਾਅ ਹੈ ਜੋ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਨੀਤੀ-ਆਧਾਰਿਤ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਆਮ ਤੌਰ ’ਤੇ ਸਬਨੈੱਟਾਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫ਼ਿਕ ਲਈ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਰੀਲੇ ਬੇਨਤੀ ASA ਆਪ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਜੇ ਟਨਲ ਦੀ ਐਕਸੈਸ ਸੂਚੀ ਅਤੇ ਕ੍ਰਿਪਟੋ ਨਕਸ਼ਾ ਸਿਰਫ਼ ਸ਼ਾਖਾ-ਹੋਸਟ ਤੋਂ ਸਰਵਰ-ਸਬਨੈੱਟ ਵੱਲ ਜਾਣ ਵਾਲੇ ਪ੍ਰਵਾਹਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਤਾਂ ਰੀਲੇ ਪੈਕਟ ਕਦੇ ਵੀ ਟਨਲ ਵਿੱਚ ਦਾਖਲ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਐਕਸੈਸ ਸੂਚੀ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਜਾਂਚੋ, ਸਿਰਫ਼ ਸ਼ਾਖਾ-ਤੋਂ-ਸਰਵਰ ਲਾਈਨ ਵਿੱਚ ਨਹੀਂ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਦਿਲਚਸਪ ਟ੍ਰੈਫ਼ਿਕ ASA ਦੇ ਰੀਲੇ ਸਰੋਤ ਅਤੇ ਸਰਵਰ ਦੇ ਪਤੇ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਾਪਸੀ ਦਿਸ਼ਾ ਵੀ ਮਨਜ਼ੂਰ ਹੈ। VTI-ਆਧਾਰਿਤ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਰਾਊਟਿੰਗ ਫ਼ੈਸਲਾ ਸੌਖਾ ਹੈ, ਪਰ VTI ਉੱਤੇ ਰੀਲੇ ਸਮਰਥਨ ਇੱਕ ਖ਼ਾਸ ਰੀਲੀਜ਼ ਵਿੱਚ ਆਇਆ; ASA ਦੀ DHCP ਗਾਈਡ 9.14(1) ਦੱਸਦੀ ਹੈ, ਇਸ ਲਈ ਪੁਰਾਣੇ ਯੰਤਰ ’ਤੇ VTI ਉਦਾਹਰਨ ਕਾਪੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਮੇਜ ਜਾਂਚੋ।

ASA ਤੋਂ ਸਰਵਰ ਤੱਕ ping ਆਪਣੇ ਆਪ ਵਿੱਚ ਬਹੁਤਾ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਕਿਸੇ ਹੋਰ ਰਾਹ ਰਾਹੀਂ, ਹੋਰ ਸਰੋਤ ਪਤੇ ਨਾਲ, ਜਾਂ ਅਜਿਹੀ ਨੀਤੀ ਹੇਠ ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸ ਨਾਲ ਰੀਲੇ ਦੇ ਪੈਕਟ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ।

ਤੀਜਾ ਪੜਾਅ: ਜਵਾਬ ਅਤੇ setroute ਚੋਣ ਪੜ੍ਹੋ

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

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

ਪੇਸ਼ਕਸ਼ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਪੜ੍ਹੋ: ਪੇਸ਼ ਕੀਤਾ ਪਤਾ, ਮਾਸਕ, ਡਿਫ਼ਾਲਟ ਰਾਊਟਰ, DNS ਅਤੇ ਲੀਜ਼ ਸਮਾਂ। ਫਿਰ ਲੀਜ਼ ਨਵੀਨੀਕਰਨ ਹੋਣ ਦਿਓ। ਇੱਕ ਵਾਰ ਕੰਮ ਕਰਕੇ ਨਵੀਨੀਕਰਨ ’ਤੇ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੇ ਰੀਲੇ ਵਿੱਚ ਆਮ ਤੌਰ ’ਤੇ ਸਕੋਪ, ਲੀਜ਼ ਜਾਂ ਵਾਪਸੀ ਰਾਹ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ, ਜੋ ਪਹਿਲੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਨੇ ਲੁਕਾਈ ਸੀ।

«ਠੀਕ ਹੋ ਗਿਆ» ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਮੈਂ ਕੀ ਜਾਂਚਦਾ ਹਾਂ

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

ਜੇ ਕੋਈ ਪੜਾਅ ਚੁੱਪ ਹੈ, ਤਾਂ ਹੋਰ ਰੀਲੇ ਬਿਆਨ ਜੋੜਨ ਦੀ ਥਾਂ ਸੰਬੰਧਿਤ ਨੀਤੀ ਜਾਂ ਰਾਊਟ ਜਾਂਚੋ। ਕਿਸੇ ਦੇ ਐਸਕਲੇਟ ਕਰਨ ਤੱਕ ਰੀਲੇ ਕਾਨਫ਼ਿਗ ਆਮ ਤੌਰ ’ਤੇ ਠੀਕ ਹੀ ਹੁੰਦੀ ਹੈ; ਬਦਲੀ ਚੀਜ਼ ਟਨਲ ਨੀਤੀ ਜਾਂ ਵਾਪਸੀ ਰਾਊਟ ਹੈ।

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