VPN ਵੱਲੋਂ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕਿਹੜਾ ASA ਨਿਯਮ ਟ੍ਰੈਫਿਕ ਦੇਖਦਾ ਹੈ
ਕ੍ਰਿਪਟੋ ACL ਚੁਣਦਾ ਹੈ ਕਿ ਕੀ ਐਨਕ੍ਰਿਪਟ ਹੋਵੇਗਾ; ਪਰ ਇਹ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਸਰਵਰ ਤੱਕ ਕੌਣ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਪਹਿਲਾਂ ਇੰਟਰਫੇਸ ਨੀਤੀ ਅਤੇ ਫਿਲਟਰ ਦੀ ਦਿਸ਼ਾ ਜਾਂਚੋ।
ਪਹਿਲੀ ਧਾਰਨਾ ਜੋ ਛੱਡਣੀ ਚਾਹੀਦੀ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਕ੍ਰਿਪਟੋ ACL ਇੱਕ ਪਹੁੰਚ ਨੀਤੀ ਹੈ। ਅਜਿਹਾ ਨਹੀਂ ਹੈ। Cisco ASA ਉੱਤੇ ਉਹ ਸੂਚੀ ਇੱਕ ਤੰਗ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਕਿਹੜੇ ਪੈਕੇਟ ਸੁਰੱਖਿਆ ਦੇ ਯੋਗ ਹਨ, ਅਤੇ ਉਹ ਜਵਾਬ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਡੀਕ੍ਰਿਪਟ ਕੀਤਾ ਪੈਕੇਟ ਫਾਇਰਵਾਲ ਪਿੱਛੇ ਦੇ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਪਹੁੰਚ ਦਾ ਫੈਸਲਾ ਬਾਅਦ ਵਿੱਚ ਹੁੰਦਾ ਹੈ — ਇੰਟਰਫੇਸ ਨੀਤੀ, ਗਰੁੱਪ-ਨੀਤੀ ਫਿਲਟਰ, ਜਾਂ ਦੋਵਾਂ ਨਾਲ, ਟਨਲ ਕਿਵੇਂ ਬਣੀ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
ਕ੍ਰਿਪਟੋ ACL ਕਿਸੇ ਹੋਰ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ
ਕ੍ਰਿਪਟੋ ACL ਇੱਕ ਮਿਲਾਨ ਸੂਚੀ ਹੈ। ਇਹ ਟਨਲ ਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਦੋ ਧਿਰਾਂ ਵਿਚਕਾਰ ਕੀ ਐਨਕ੍ਰਿਪਟ ਕਰਨਾ ਹੈ; ਜੋ ਪੈਕੇਟ ਇਸ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਉਹ ਸਿਰਫ਼ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਰਹਿੰਦਾ। ਇਸ ਨੂੰ ਚੌੜਾ ਕਰਨ ਨਾਲ ਸੁਰੱਖਿਆ ਦਾ ਘੇਰਾ ਬਦਲਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ।
ਇਸੇ ਲਈ ਉੱਥੇ ਸਬਨੈੱਟ ਜੋੜਨ ਨਾਲ ਟਨਲ ਉੱਪਰ ਆ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਅਜੇ ਵੀ ਫੇਲ ਹੁੰਦੀ ਹੈ। ਟਨਲ ਉੱਪਰ ਹੈ ਕਿਉਂਕਿ ਹੁਣ ਮਿਲਾਨ ਮੌਜੂਦ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਫੇਲ ਹੈ ਕਿਉਂਕਿ ਉਸ ਸੂਚੀ ਵਿੱਚ ਕੁਝ ਵੀ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ। ਦੋ ਵੱਖਰੇ ਸਵਾਲ, ਦੋ ਵੱਖਰੀਆਂ ਸੂਚੀਆਂ।
ਬਾਈਪਾਸ ਸੈਟਿੰਗ ਅਸਲ ਵਿੱਚ ਕੀ ਛੱਡਦੀ ਹੈ
sysopt connection permit-vpn ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੰਟਰਫੇਸ ACL ਜਾਂਚ ਛੱਡਣ ਦਿੰਦਾ ਹੈ ਜੋ ਨਹੀਂ ਤਾਂ ਇਨਬਾਊਂਡ ਪਾਸੇ ਲਾਗੂ ਹੁੰਦੀ। ਇਹ VPN ਤੈਨਾਤੀਆਂ ਲਈ ਸੁਵਿਧਾ ਹੈ, ਅਤੇ ਇਹ ਗਲੋਬਲ ਹੈ। ਇਹ ਗਰੁੱਪ ਨੀਤੀ ਨੂੰ ਨਹੀਂ ਛੂਹਦਾ ਅਤੇ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਅਧਿਕਾਰ ਫਿਲਟਰ ਨੂੰ ਵੀ ਨਹੀਂ ਛੂਹਦਾ।
ਧਾਰਨਾ ਦੀ ਥਾਂ ਅਸਲ ਮੁੱਲ ਪੜ੍ਹੋ: show running-config all sysopt ਸੈਟਿੰਗ ਛਾਪਦਾ ਹੈ ਭਾਵੇਂ ਇਹ ਕਦੇ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਕਨਫਿਗਰ ਨਾ ਕੀਤੀ ਗਈ ਹੋਵੇ, ਅਤੇ ਬਹੁਤ ਉਲਝਣ ਉੱਥੋਂ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।
ਕਿਉਂਕਿ ਸੈਟਿੰਗ ਗਲੋਬਲ ਹੈ, ਇਸ ਨੂੰ ਇੱਕ ਫੇਲ ਹੁੰਦੇ ਸਬਨੈੱਟ ਉੱਤੇ ਤੇਜ਼ ਪ੍ਰਯੋਗ ਵਜੋਂ ਜਾਂਚਣਾ ਮਾੜਾ ਸੌਦਾ ਹੈ। ਉਸ ਫਾਇਰਵਾਲ ਦੀ ਹਰ ਹੋਰ ਟਨਲ ਨਤੀਜਾ ਸਾਂਝਾ ਕਰਦੀ ਹੈ। ਇਸ ਨੂੰ ਰੋਲਬੈਕ ਯੋਜਨਾ ਵਾਲੇ ਜਾਣਬੁੱਝ ਕੇ ਬਦਲਾਅ ਲਈ ਰੱਖੋ।
ਡੀਕ੍ਰਿਪਟ ਦਿਸ਼ਾ ਵਿੱਚ ਫਿਲਟਰ ਪੜ੍ਹੋ
LAN-to-LAN vpn-filter ਇੰਟਰਫੇਸ ਦੀ ਨਹੀਂ, ਟਨਲ ਦੀ ਨਜ਼ਰ ਤੋਂ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ। ਦੂਰ ਦਾ ਨੈੱਟਵਰਕ ਸਰੋਤ ਦੀ ਥਾਂ ਅਤੇ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਮੰਜ਼ਿਲ ਦੀ ਥਾਂ ਉੱਤੇ ਆਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਡੀਕ੍ਰਿਪਟ ਤੋਂ ਬਾਅਦ ਪੈਕੇਟ ਅਜਿਹਾ ਹੀ ਦਿਸਦਾ ਹੈ। ਫਿਰ ਉਹੀ ਫਿਲਟਰ ਐਨਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਦੁਬਾਰਾ ਮੁਲਾਂਕਣ ਹੁੰਦਾ ਹੈ, ਪਤਿਆਂ ਦੀਆਂ ਭੂਮਿਕਾਵਾਂ ਉਲਟ ਕੇ।
ਪੋਰਟ ਸ਼ਰਤਾਂ ਨਕਲ ਕੀਤੇ ਇੰਟਰਫੇਸ ACL ਨਾਲੋਂ ਵੱਧ ਧਿਆਨ ਮੰਗਦੀਆਂ ਹਨ, ਠੀਕ ਇਸੇ ਕਾਰਨ। ਇੱਕ ਮੰਜ਼ਿਲ ਪੋਰਟ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਅਣਚਾਹਿਆ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦਾ ਹੈ, ਜਿੱਥੇ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਉਸ ਪੋਰਟ ਨੂੰ ਆਪਣੇ ਸਰੋਤ ਵਜੋਂ ਵਰਤਦਾ ਹੈ। ਸੂਚੀ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਕਿਹੜਾ ਪਾਸਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ, ਅਸਲ ਸੇਵਾ ਕੀ ਹੈ, ਅਤੇ ਕਿਹੜਾ ਵਿਰੋਧੀ ਪਾਸਾ ਬੰਦ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਹੜਾ ਫਿਲਟਰ ਅਸਲ ਵਿੱਚ ਜੁੜਿਆ ਹੈ: show running-config group-policy ਅਤੇ show vpn-sessiondb detail l2l ਮਿਲ ਕੇ ਦੱਸਦੇ ਹਨ ਕਿ ਸੈਸ਼ਨ ਨੂੰ ਕੀ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਿਆ। ਜਿਸ ACL ਦਾ ਕੋਈ ਨੀਤੀ ਹਵਾਲਾ ਨਹੀਂ ਦਿੰਦੀ, ਉਸ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਇੱਕ ACL ਆਬਜੈਕਟ ਨੂੰ ਦੋ ਕੰਮਾਂ ਲਈ ਦੁਬਾਰਾ ਨਾ ਵਰਤੋ
ਇੰਟਰਫੇਸ ਦਾ access-group ਅਤੇ vpn-filter ਇੱਕੋ ਕਿਸਮ ਦੇ ਆਬਜੈਕਟ ਵਰਗੇ ਲੱਗਦੇ ਹਨ ਅਤੇ ਵੱਖਰੇ ਬਿੰਦੂਆਂ ਉੱਤੇ ਵੱਖਰੀ ਪਤਾ-ਦਿਸ਼ਾ ਨਾਲ ਮੁਲਾਂਕਣ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਸੂਚੀ ਦੋਵਾਂ ਨੂੰ ਦੇਣ ਨਾਲ ਅਜਿਹੇ ਬਦਲਾਅ ਨੂੰ ਸੱਦਾ ਮਿਲਦਾ ਹੈ ਜੋ ਟਨਲ ਠੀਕ ਕਰਦਾ ਹੈ ਅਤੇ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਨੂੰ ਚੁੱਪਚਾਪ ਢਿੱਲਾ ਕਰਦਾ ਹੈ।
ਇਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ, ਇਹਨਾਂ ਦੇ ਕੰਮ ਅਨੁਸਾਰ ਨਾਮ ਦਿਓ, ਅਤੇ ਦਿਸ਼ਾ ਦਾ ਫ਼ਰਕ ਨਾਵਾਂ ਵਿੱਚ ਦਿਸਣ ਦਿਓ।
ਨਵੇਂ ਕਨੈਕਸ਼ਨਾਂ ਨਾਲ, ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰੋ
ਯੋਜਿਤ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹੋ ਜਿਸ ਨੂੰ ਇਜਾਜ਼ਤ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਇੱਕ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਜਿਸ ਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਫਿਰ ਪਤੇ, ਦਿਸ਼ਾ ਅਤੇ ਨੀਤੀ-ਮਿਲਾਨ ਨਤੀਜੇ ਨਾਲ ਲਿਖੋ। ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਨਵੇਂ-ਕਨੈਕਸ਼ਨ ਫਿਲਟਰਿੰਗ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਇਹ ਪੁਰਾਣੇ ਨਿਯਮਾਂ ਹੇਠ ਪਹਿਲਾਂ ਹੀ ਦਾਖਲ ਹੋ ਚੁੱਕਾ ਹੈ।
ਜਾਂਚ ਨੂੰ ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ। ਵਿਕਰੇਤਾ ਦਸਤਾਵੇਜ਼ ਦੱਸਦਾ ਹੈ ਕਿ VPN ਫਿਲਟਰ ਸ਼ੁਰੂਆਤੀ ਕਨੈਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਜਾਂਚ ਇੰਜਣ ਵੱਲੋਂ ਖੋਲ੍ਹੇ ਹਰ ਦੂਜੇ ਦਰਜੇ ਦੇ ਕਨੈਕਸ਼ਨ ਦੀ ਨਹੀਂ, ਇਸ ਲਈ ਕੰਟਰੋਲ ਚੈਨਲ ਅਤੇ ਇਸ ਨਾਲ ਸੰਬੰਧਿਤ ਮੀਡੀਆ ਪ੍ਰਵਾਹ ਵੱਖਰਾ ਵਿਵਹਾਰ ਪਾ ਸਕਦੇ ਹਨ। ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ-ਜਾਗਰੂਕ ਹੈ, ਤਾਂ ਇੱਕ ਪੋਰਟ ਪ੍ਰੋਬ ਦੀ ਥਾਂ ਅਸਲ ਪ੍ਰਵਾਹ ਜਾਂਚੋ।
ਵਿਆਪਕ ਬਾਈਪਾਸ ਤੋਂ ਬਾਅਦ ਵਰਤੋਂਯੋਗ ਬਣਨ ਵਾਲੀ ਟਨਲ ਕਹਿੰਦੀ ਹੈ ਕਿ ਪਾਬੰਦੀ ਹਟਾਈ ਗਈ, ਇਹ ਨਹੀਂ ਕਿ ਉਹ ਪੂਰੀ ਹੋਈ। ਰੱਖਣਯੋਗ ਨਤੀਜਾ ਇੱਕ ਨਾਮਿਤ ਲਾਗੂਕਰਨ ਬਿੰਦੂ ਹੈ ਜਿਸ ਵੱਲ ਤੁਸੀਂ ਅਗਲੀ ਸਮੀਖਿਆ ਵਿੱਚ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦੇ ਹੋ।