ਸਾਈਟ VPN ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ASA ਲੌਗ ਨਹੀਂ ਆਉਂਦੇ: ਸਰੋਤ ਪਤਾ ਜਾਂਚੋ
ਫਾਰਵਰਡ ਕੀਤਾ LAN ਟ੍ਰੈਫਿਕ ਅਤੇ ਫਾਇਰਵਾਲ ਜੋ ਲੌਗ ਬਣਾਉਂਦਾ ਹੈ, ਉਹ ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ ਤੋਂ ਨਿਕਲ ਸਕਦੇ ਹਨ। ਟਨਲ ਦੁਬਾਰਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਬਣਾਵਟ, ਸਰੋਤ ਅਤੇ ਸਿਲੈਕਟਰ ਜਾਂਚੋ।
ਅੰਦਰੂਨੀ ਹੋਸਟ ਦੂਰ ਦੇ ਇਕੱਠੇ ਕਰਨ ਵਾਲੇ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀਆਂ syslog ਲਾਈਨਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਹੀ ਸੈਸ਼ਨਾਂ ਬਾਰੇ ASA ਦੇ ਆਪਣੇ ਸੁਨੇਹੇ ਕਦੇ ਨਹੀਂ ਆਉਂਦੇ। ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਜਾਂ ਟਨਲ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹੀ ਉਲਝਣ ਵਾਲਾ ਹਿੱਸਾ ਹੈ। ਫਾਇਰਵਾਲ ਆਪਣੇ ਲੌਗ ਅਜਿਹੇ ਸਰੋਤ ਤੋਂ ਭੇਜ ਰਿਹਾ ਹੈ ਜਿਸ ਦੀ ਰੱਖਿਆ ਲਈ ਟਨਲ ਕਦੇ ਨਹੀਂ ਬਣਾਈ ਗਈ ਸੀ।
ਕੀ ਆਉਂਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ
ਡੈਸ਼ਬੋਰਡ ਉੱਤੇ ਇੱਕੋ ਜਿਹੇ ਦਿਖਣ ਵਾਲੇ ਦੋ ਪ੍ਰਵਾਹ ਵੱਖ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਫਾਰਵਰਡ ਕੀਤਾ ਟ੍ਰੈਫਿਕ ASA ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ: ਇੱਕ LAN ਹੋਸਟ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਨੂੰ ਭੇਜਦਾ ਹੈ, ASA ਉਸਨੂੰ ਟਨਲ ਨੀਤੀ ਨਾਲ ਮਿਲਾਉਂਦਾ ਹੈ, ਉਸਨੂੰ ਇਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਕੱਠਾ ਕਰਨ ਵਾਲਾ ਹੋਸਟ ਦਾ ਪਤਾ ਦੇਖਦਾ ਹੈ। ਬਣਾਇਆ ਗਿਆ ਟ੍ਰੈਫਿਕ ASA ਉੱਤੇ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਜੰਤਰ syslog ਪੈਕੇਟ ਬਣਾਉਂਦਾ ਹੈ, ਆਉਟਗੋਇੰਗ ਇੰਟਰਫੇਸ ਅਤੇ ਸਰੋਤ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਹੀ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕੋਈ ਟਨਲ ਨੀਤੀ ਮਿਲਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਪਹਿਲਾ ਪ੍ਰਵਾਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਟਨਲ ਕੰਮ ਕਰਦੀ ਹੈ, ਅਤੇ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।
ਜੰਤਰ ਉੱਤੇ ਬਫਰ ਕੀਤੀ ਘਟਨਾ ਵੀ ਦੂਰ ਦੀ ਡਿਲਿਵਰੀ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਲੌਗ ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਕਦੇ ਭੇਜਿਆ ਨਾ ਗਿਆ ਹੋਵੇ। ਟਨਲ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਦੇ ਪ੍ਰਾਪਤੀ ਕਾਊਂਟਰ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਖਾਲੀ ਕਾਊਂਟਰ ਵਧਦੇ ਕਾਊਂਟਰ ਤੋਂ ਵੱਖਰਾ ਨਤੀਜਾ ਹੈ।
ਬਣਾਇਆ ਸੁਨੇਹਾ ਫਾਰਵਰਡ ਕੀਤਾ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਹੈ
ਜਦੋਂ ASA ਆਪ ਪੈਕੇਟ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਉਹ LAN ਹੋਸਟ ਦੀ ਪ੍ਰੌਕਸੀ ਨਹੀਂ ਕਰ ਰਿਹਾ। ਸਰੋਤ ਆਉਟਗੋਇੰਗ ਇੰਟਰਫੇਸ ਤੋਂ ਜਾਂ ਸਪਸ਼ਟ ਸਰੋਤ ਸੈਟਿੰਗ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਪੈਕੇਟ ਉਸੇ ਰੂਟ ਖੋਜ ਅਤੇ ਉਨ੍ਹਾਂ ਹੀ ਨੀਤੀ ਜਾਂਚਾਂ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ ਜੋ ਜੰਤਰ ਭੇਜਦਾ ਹੈ। ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ VPN ਸਿਲੈਕਟਰ ਵਿੱਚ ਉਹ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ASA ਅਸਲ ਵਿੱਚ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਉਹ ਅਕਸਰ ਉਸਦਾ ਬਾਹਰੀ ਇੰਟਰਫੇਸ ਹੁੰਦਾ ਹੈ, ਅੰਦਰੂਨੀ ਸਬਨੈੱਟ ਨਹੀਂ।
ਜੇ ਨੀਤੀ 10.20.0.0/24 ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ ਅਤੇ ASA ਆਪਣੇ ਬਾਹਰੀ ਪਤੇ ਨੂੰ ਸਰੋਤ ਵਜੋਂ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਲੌਗ ਪੈਕੇਟ ਜਾਂ ਤਾਂ ਉਸ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਵੱਲ ਖੁੱਲ੍ਹੇ ਟੈਕਸਟ ਵਿੱਚ ਨਿਕਲਦਾ ਹੈ ਜਿੱਥੇ ਪਹੁੰਚ ਨਹੀਂ ਸਕਦਾ, ਜਾਂ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਪਾਸੋਂ ਦੋਵੇਂ ਨਤੀਜੇ ਇੱਕੋ ਜਿਹੇ ਦਿਖਦੇ ਹਨ। ਇਹੀ ਤਰਕ ਪ੍ਰਬੰਧਨ ਟ੍ਰੈਫਿਕ ਉੱਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ management-access ਇੱਕ ਵੱਖਰਾ ਡਿਜ਼ਾਈਨ ਫੈਸਲਾ ਹੈ।
ASA ਨੈੱਟਵਰਕ ਉੱਤੇ ਕਿਹੜਾ ਸਰੋਤ ਰੱਖਦਾ ਹੈ
ਸਰੋਤ ਅਨੁਮਾਨ ਨਾਲ ਨਹੀਂ, ਪ੍ਰਯੋਗ ਨਾਲ ਲੱਭੋ। ਟੈਸਟ ਸੁਨੇਹੇ ਦੌਰਾਨ ਆਉਟਗੋਇੰਗ ਇੰਟਰਫੇਸ ਉੱਤੇ ਕੈਪਚਰ ਅਸਲ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਨਫਿਗਰੇਸ਼ਨ ਦੇ ਤਿੰਨ ਭਾਗ ਪੜ੍ਹਨ ਨਾਲੋਂ ਘੱਟ ਸਮਾਂ ਲੈਂਦਾ ਹੈ। ਉਸ ਪਤੇ ਦੀ ਟਨਲ ਦੇ ਸਥਾਨਕ ਸਿਲੈਕਟਰ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
ਕੁਝ ਰਿਲੀਜ਼ਾਂ ਲੌਗਿੰਗ ਸਰੋਤ ਨੂੰ ਇੰਟਰਫੇਸ ਨਾਲ ਪਿੰਨ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਤੁਹਾਡੇ ਸੰਸਕਰਣ ਦਾ ਕਮਾਂਡ ਹਵਾਲਾ ਇਸ ਬਾਰੇ ਅਧਿਕਾਰ ਹੈ ਕਿ ਉਹ ਵਿਕਲਪ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਉਹ ਕੀ ਬਦਲਦਾ ਹੈ। ਕਿਸੇ ਹੋਰ Cisco ਪਲੇਟਫਾਰਮ ਦਾ source-interface ਕਮਾਂਡ ASA ਉੱਤੇ ਆਪਣੇ ਆਪ ਵੈਧ ਨਹੀਂ ਹੁੰਦਾ।
ਜੇ ਤੁਸੀਂ ਸਰੋਤ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਬਦਲੋ ਅਤੇ ਨੋਟ ਕਰੋ, ਕਿਉਂਕਿ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਦੇ ACL ਅਤੇ syslog ਉੱਤੇ ਬਣਿਆ ਕੋਈ ਵੀ ਸੰਬੰਧ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
ਸਿਲੈਕਟਰ ਨੂੰ ਲੌਗ ਪ੍ਰਵਾਹ ਨਾਲ ਮਿਲਾਓ
ਸਰੋਤ ਪਤਾ ਲੱਗਣ ਤੋਂ ਬਾਅਦ ਤਿੰਨ ਚੀਜ਼ਾਂ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ: ਕਿਹੜਾ ਟ੍ਰੈਫਿਕ ਦਿਲਚਸਪ ਹੈ ਇਹ ਤੈਅ ਕਰਨ ਵਾਲਾ ਕ੍ਰਿਪਟੋ ACL ਜਾਂ ਨੀਤੀ-ਆਧਾਰਿਤ ਸਿਲੈਕਟਰ, ਪੈਕੇਟ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ ਇਹ ਤੈਅ ਕਰਨ ਵਾਲਾ ਰੂਟ, ਅਤੇ ਇਨਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤ ਮੁੜ ਲਿਖ ਸਕਣ ਵਾਲਾ ਕੋਈ ਵੀ NAT ਨਿਯਮ। ਜੋ ਪੈਕੇਟ ਰੂਟ ਨਾਲ ਮਿਲਦਾ ਹੈ ਪਰ ਸਿਲੈਕਟਰ ਨਾਲ ਨਹੀਂ, ਉਹ ਟਨਲ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ NAT ਵੱਲੋਂ ਮੁੜ ਲਿਖਿਆ ਪੈਕੇਟ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨਾਲ ਨਹੀਂ ਮਿਲ ਸਕਦਾ।
ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਦੇ ਪਾਸੇ ਦੀਆਂ ਆਪਣੀਆਂ ਲੋੜਾਂ ਹਨ: ASA ਦੇ ਸਰੋਤ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਵਾਲਾ ACL, ਵਾਪਸੀ ਰੂਟ, ਅਤੇ ਤੁਹਾਡੇ ਵੱਲੋਂ ਕਨਫਿਗਰ ਕੀਤੇ ਪੋਰਟ ਉੱਤੇ ਸੁਣਨ ਵਾਲੀ ਸੇਵਾ। ਆਵਾਜਾਈ ਇੱਥੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਅੰਸ਼ਕ ਤੌਰ ਉੱਤੇ ਬਲਾਕ ਕੀਤੇ ਰਸਤੇ ਉੱਤੇ TCP ਅਤੇ TLS ਲੌਗਿੰਗ UDP ਨਾਲੋਂ ਵੱਖਰੀ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਤੱਤ ਬਦਲੋ, ਨਹੀਂ ਤਾਂ ਅਗਲਾ ਕੈਪਚਰ ਨਹੀਂ ਦੱਸੇਗਾ ਕਿ ਕਿਹੜਾ ਬਦਲਾਅ ਮਹੱਤਵਪੂਰਨ ਸੀ।
ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਉੱਤੇ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਸਰੋਤ ਦਰਜ ਕਰੋ
ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੁਨੇਹਾ ਆਉਂਦਾ ਹੈ, ਫਿਰ ASA ਵੱਲੋਂ ਵਰਤਿਆ ਸਰੋਤ ਪਤਾ, ਉਸਨੂੰ ਲੈ ਜਾਣ ਵਾਲਾ ਸਿਲੈਕਟਰ ਅਤੇ ਤੁਹਾਡੇ ਵੱਲੋਂ ਜਾਂਚੀ ਗਈ ਗੰਭੀਰਤਾ ਲਿਖੋ।
ਉਹ ਰਿਕਾਰਡ ਅਗਲੇ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ACL ਬਦਲਾਅ ਜਾਂ ਸਿਲੈਕਟਰ ਸੋਧ ਨੂੰ ਮੁੜ ਖੋਜਣ ਦੀ ਬਜਾਏ ਦੋ ਮਿੰਟ ਦੀ ਜਾਂਚ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਇਹ ਵੀ ਦਰਜ ਕਰਦਾ ਹੈ ਕਿ ਦੋ ਪ੍ਰਵਾਹਾਂ ਵਿੱਚੋਂ ਕਿਸ ਨੂੰ ਕਦੇ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਇਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਰਨਬੁੱਕ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਜੇ ਸੁਨੇਹਾ ਫਿਰ ਵੀ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਗੰਭੀਰਤਾ ਦੀ ਹੱਦ ਅਸਥਾਈ ਤੌਰ ਉੱਤੇ ਘਟਾਓ ਅਤੇ ਇੱਕ ਹੀ ਮੰਜ਼ਿਲ ਵਿਰੁੱਧ ਜਾਂਚ ਕਰੋ।
Cisco ਦੇ ASA ਲੌਗਿੰਗ ਬਾਰੇ ਆਮ ਸਵਾਲ ਬਾਹਰੀ ਸਰੋਤ ਵਾਲੇ ਕੇਸ ਦਾ ਦਸਤਾਵੇਜ਼ ਕਰਦੇ ਹਨ ਜਿਸ ਲਈ ਸੰਬੰਧਿਤ ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫਿਕ ਪਰਿਭਾਸ਼ਾ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਦੀ ਅੰਦਰੂਨੀ ਸਰੋਤ ਵਾਲੀ ਉਦਾਹਰਨ ਵਿੱਚ ਅੰਦਰ ਇੱਕ ਲੌਗਿੰਗ ਹੋਸਟ ਅਤੇ ਅੰਦਰ management-access ਦੋਵੇਂ ਸ਼ਾਮਲ ਹਨ। ਦਸਤਾਵੇਜ਼ੀ ਸੰਜੋਗ ਅਤੇ ਸੌਫਟਵੇਅਰ ਸੰਦਰਭ ਨੂੰ ਇਕੱਠੇ ਲਓ, ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਇੱਕ ਕਾਪੀ ਕੀਤੀ ਲਾਈਨ ਹਰ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੀ ਹੈ।
LAN ਟ੍ਰੈਫਿਕ ਢੋਣ ਵਾਲੀ ਟਨਲ ਫਾਇਰਵਾਲ ਦੀ ਆਪਣੀ ਆਵਾਜ਼ ਢੋਣ ਵਾਲੀ ਟਨਲ ਨਹੀਂ ਹੈ।