ਸਾਈਟ VPN ਰਾਹੀਂ ਦੂਰ ਦੇ ASA ਤੱਕ SSH: ਕਦਮ ਦਰ ਕਦਮ

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

ਉਹ ਪਤਾ ਚੁਣੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਪ੍ਰਬੰਧਿਤ ਕਰ ਰਹੇ ਹੋ

ਤਿੰਨ ਡਿਜ਼ਾਈਨ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ ਅਤੇ ਵੱਖਰੇ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ: ASA ਦੇ ਜਨਤਕ VPN ਵੱਲ ਵਾਲੇ ਪਤੇ ਤੱਕ ਪਹੁੰਚਣਾ, IPsec ਰਾਹੀਂ ਅੰਦਰੂਨੀ ਇੰਟਰਫ਼ੇਸ ਤੱਕ ਪਹੁੰਚਣਾ, ਅਤੇ ਸਮਰਪਿਤ ਪ੍ਰਬੰਧਨ ਇੰਟਰਫ਼ੇਸ ਤੱਕ ਪਹੁੰਚਣਾ। ਕਿਸੇ ਵੀ ਇਜਾਜ਼ਤ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਸ਼ਾਸਕ ਦਾ ਸਰੋਤ ਪਤਾ, ਸਹੀ ਮੰਜ਼ਿਲ ਪਤਾ ਅਤੇ TCP 22 ਲਿਖ ਲਓ। ਅੱਗੇ ਦਾ ਸਭ ਕੁਝ ਉਸੇ ਜੋੜੇ 'ਤੇ ਨਿਰਭਰ ਹੈ।

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

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

management-access ਇੰਟਰਫ਼ੇਸ-ਖਾਸ ਹੈ

management-access ਕਮਾਂਡ ASA ਨੂੰ ਕਹਿੰਦੀ ਹੈ ਕਿ VPN ਰਾਹੀਂ ਆਉਣ ਵਾਲੇ ਪ੍ਰਬੰਧਨ ਕਨੈਕਸ਼ਨ ਨਾਮਿਤ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਸਵੀਕਾਰ ਕਰੇ। ਇਹ ਮਾਰਗ ਨਹੀਂ ਬਣਾਉਂਦੀ, SSH ਇਜਾਜ਼ਤ ਨਹੀਂ ਜੋੜਦੀ, ਅਤੇ ਇੱਕੋ ਸਮੇਂ ਹਰ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ। ਜੇ ਮੰਜ਼ਿਲ ਇੰਟਰਫ਼ੇਸ ਨਾਮਿਤ ਨਹੀਂ ਹੈ, ਤਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਕਨੈਕਸ਼ਨ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਇੱਥੇ ਦੋ ਅਪਵਾਦ ਡੰਗਦੇ ਹਨ। ਸਿਰਫ਼ ਪ੍ਰਬੰਧਨ ਲਈ ਇੰਟਰਫ਼ੇਸ ਇਸ ਵਿਧੀ ਤੋਂ ਬਾਹਰ ਹਨ, ਅਤੇ ASA 9.20 ਪ੍ਰਬੰਧਨ ਗਾਈਡ ਨੋਟ ਕਰਦੀ ਹੈ ਕਿ ਡਿਫ਼ਾਲਟ CiscoSSH ਸਟੈਕ VPN ਰਾਹੀਂ ਇੰਟਰਫ਼ੇਸ-ਪਾਰ SSH ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ, ਜਦੋਂ ਕਿ ASA SSH ਸਟੈਕ ਕਰਦਾ ਹੈ। ਮਾਰਗਾਂ 'ਤੇ ਸਮਾਂ ਖ਼ਰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਨਾਤ ਰਿਲੀਜ਼ 'ਤੇ ਸਰਗਰਮ ਸਟੈਕ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਲੌਗਇਨ ਪ੍ਰਾਂਪਟ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਗੇਟ

ਕਲਾਇੰਟ ਅਤੇ ਵਰਤੋਂਕਾਰ ਨਾਮ ਪ੍ਰਾਂਪਟ ਦੇ ਵਿਚਕਾਰ ਚਾਰ ਸੁਤੰਤਰ ਗੇਟ ਹਨ: ਪ੍ਰਬੰਧਨ ਜੋੜੀ ਲਈ ਮਾਰਗ ਅਤੇ ਸੁਰੰਗ ਦਾ ਮੇਲ, ASA ਪਤੇ 'ਤੇ TCP 22 ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਇੰਟਰਫ਼ੇਸ ACL, ਪ੍ਰਸ਼ਾਸਕ ਦੇ ਸਰੋਤ ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲੀ ssh ਇਜਾਜ਼ਤ, ਅਤੇ ਉਸ ਵਰਤੋਂਕਾਰ ਲਈ AAA ਪ੍ਰਮਾਣਿਕਤਾ। ਹਰ ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਦੱਸੇ ਬਿਨਾਂ ਪੈਕੇਟ ਸੁੱਟ ਸਕਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਗੇਟ ਬੰਦ ਹੋਇਆ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਵੇਖਣ ਲਈ packet-tracer ਵਰਤੋ ਕਿ ਕਿਹੜਾ ਗੇਟ ਫੇਲ ਹੁੰਦਾ ਹੈ: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed। ਟ੍ਰੇਸ ACL, NAT ਪੜਾਅ ਅਤੇ to-the-box ਫ਼ੈਸਲੇ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਰੂਟਿੰਗ ਸਮੱਸਿਆ ਨੂੰ ਦਾਖਲਾ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ।

ਸੰਧਰਾ ਇਜਾਜ਼ਤ ਲਿਖੋ, ਚੌੜੀ ਨਹੀਂ

ਇਜਾਜ਼ਤ ਨੂੰ ਮਨਜ਼ੂਰ ਪ੍ਰਸ਼ਾਸਕੀ ਸਬਨੈੱਟ ਅਤੇ ਸੁਰੰਗ ਦਾ ਟ੍ਰੈਫਿਕ ਲੈਣ ਵਾਲੇ ਇੰਟਰਫ਼ੇਸ ਤੱਕ ਸੀਮਿਤ ਕਰੋ: ssh 10.10.5.0 255.255.255.0 inside। ਬਾਹਰੀ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਹਰ ਸਰੋਤ ਖੋਲ੍ਹਣ ਦੀ ਥਾਂ ਇਸ ਨੂੰ aaa authentication ssh console LOCAL ਵਰਗੀ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿਧੀ ਅਤੇ ਨਾਮਿਤ ਸਥਾਨਕ ਖਾਤੇ ਨਾਲ ਜੋੜੋ।

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

ਨਾਮਿਤ ਹੋਸਟ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਦੁਬਾਰਾ ਸੰਧਰਾ ਕਰੋ

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

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