VPN ਟ੍ਰੈਫਿਕ ਲਈ ASA identity NAT ਅਤੇ IOS NAT ਛੋਟ

ਇੱਕ ਸ਼ਾਖਾ ਇੱਕੋ Cisco ਗੇਟਵੇ 'ਤੇ ਇੰਟਰਨੈੱਟ PAT ਅਤੇ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਚਲਾਉਂਦੀ ਹੈ, ਅਤੇ NAT ਸ਼ਾਮਲ ਕਰਨ ਦੇ ਨਾਲ ਹੀ VPN ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਸੁਰੰਗ ਦੇ ਅੰਦਰਲੇ ਪਤੇ ਹੁਣ crypto ACL ਜਿਸ ਦੀ ਸੁਰੱਖਿਆ ਕਰਦਾ ਹੈ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਜਾਂ ਸਾਹਮਣੇ ਵਾਲੇ ਪਾਸੇ ਨੂੰ ਅਜਿਹੇ ਅਨੁਵਾਦਿਤ ਪਤੇ ਦਿਸਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਕੋਈ ਰਸਤਾ ਨਹੀਂ। Cisco ਇਸ ਨੂੰ ਦੋ ਥਾਵਾਂ 'ਤੇ ਹੱਲ ਕਰਦਾ ਹੈ: ASA ਪਤੇ ਨੂੰ ਆਪਣੇ ਆਪ ਨਾਲ ਮੈਪ ਕਰਨ ਵਾਲਾ NAT ਨਿਯਮ ਚੁਣਦਾ ਹੈ, ਜਦਕਿ IOS ACL ਵਿੱਚ deny ਰਾਹੀਂ ਪ੍ਰਵਾਹ ਨੂੰ ਅਨੁਵਾਦ ਨਿਯਮ ਤੋਂ ਬਾਹਰ ਰੱਖਦਾ ਹੈ। ਦੋਵੇਂ ਮੂਲ ਪਤੇ ਬਚਾਉਂਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ NAT ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਬਾਈਪਾਸ ਨਹੀਂ ਕਰਦਾ।

ਨਿਯਮ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਵਾਹ ਦਰਜ ਕਰੋ

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

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

ASA identity NAT ਇੱਕ ਨਿਯਮ ਹੈ, ਬਾਈਪਾਸ ਨਹੀਂ

ASA 'ਤੇ identity NAT ਉਹ NAT ਨਿਯਮ ਹੈ ਜਿਸ ਦਾ ਅਨੁਵਾਦਿਤ ਪਤਾ ਮੂਲ ਪਤੇ ਦੇ ਬਰਾਬਰ ਹੁੰਦਾ ਹੈ। ਇਹ ਕਿਸੇ ਹੋਰ ਨਿਯਮ ਵਾਂਗ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਅਨੁਵਾਦ ਐਂਟਰੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪੈਕੇਟ NAT ਪ੍ਰੋਸੈਸਿੰਗ ਨਹੀਂ ਛੱਡਦਾ। ਬਦਲਦਾ ਇਹ ਹੈ ਕਿ ਨੈੱਟਵਰਕ 'ਤੇ ਪਤੇ ਉਹੀ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ IPsec ਨੀਤੀ ਨੂੰ ਇਹੀ ਚਾਹੀਦਾ ਹੈ।

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

ਨਿਯਮ ਦੇ ਇੰਟਰਫੇਸ ਅਤੇ ਇਸ ਦੀ route-lookup ਸੈਟਿੰਗ ਫਾਰਵਰਡਿੰਗ ਡਿਜ਼ਾਈਨ ਨਾਲ ਮੇਲ ਖਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੋ ਨਿਯਮ ਪਤੇ ਨੂੰ ਸਹੀ ਮੈਪ ਕਰਦਾ ਹੈ ਪਰ ਗਲਤ ਇੰਟਰਫੇਸ ਜੋੜੀ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਉਹ ਤੁਹਾਡੇ ਪ੍ਰਵਾਹ ਲਈ ਨਹੀਂ ਚੁਣਿਆ ਜਾਵੇਗਾ। Route-lookup ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਅਨੁਵਾਦਿਤ ਪੈਕੇਟ ਰੂਟ ਹੋਵੇਗਾ ਜਾਂ ਮੂਲ ਟਿਕਾਣਾ ਵਰਤਿਆ ਜਾਵੇਗਾ, ਅਤੇ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਸੁਰੰਗ ਰਾਹੀਂ ਮੁੜੇਗਾ ਜਾਂ ਨਹੀਂ।

ASA ਆਪਣੇ ਆਪ ਤੱਕ ਪ੍ਰਬੰਧਕੀ ਪਹੁੰਚ ਵੱਖਰਾ ਮਾਮਲਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪ੍ਰਬੰਧਕੀ ਟ੍ਰੈਫਿਕ ਲਈ identity NAT ਵਰਤਦੇ ਹੋ ਤਾਂ ਰੀਲੀਜ਼-ਵਿਸ਼ੇਸ਼ route-lookup ਸ਼ਰਤ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ VPN ਉਦਾਹਰਨ ਤੋਂ ਕਾਪੀ ਕੀਤੀ ਚੌੜੀ ਛੋਟ SSH ਨਹੀਂ ਸੁਧਾਰੇਗੀ।

IOS NAT ACL ਵਿੱਚ deny ਦਾ ਮਤਲਬ ਇੱਥੇ ਨਹੀਂ ਚੁਣਿਆ ਗਿਆ

IOS 'ਤੇ ਇੰਟਰਨੈੱਟ NAT ਸਰੋਤ ਸੂਚੀ ਰਾਹੀਂ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਉਹ ACL ਫਿਲਟਰ ਨਹੀਂ, ਵਰਗੀਕਰਨ ਹੈ। Permit ਲਾਈਨ ਅਨੁਵਾਦ ਲਈ ਟ੍ਰੈਫਿਕ ਚੁਣਦੀ ਹੈ; deny ਲਾਈਨ ਦਾ ਮਤਲਬ ਹੈ ਪੈਕੇਟ ਇੱਥੇ ਨਹੀਂ ਚੁਣਿਆ ਗਿਆ। ਉਹ deny ਇੰਟਰਫੇਸ ACL ਦੀ deny ਵਾਂਗ ਪੈਕੇਟ ਸੁੱਟਣ ਦਾ ਹੁਕਮ ਨਹੀਂ ਹੈ।

ਇੱਥੇ ਨਹੀਂ ਚੁਣਿਆ ਗਿਆ, ਕਿਤੇ ਵੀ ਅਨੁਵਾਦ ਨਾ ਹੋਣ ਨਾਲੋਂ ਵੀ ਤੰਗ ਹੈ। ਦੂਜਾ NAT ਨਿਯਮ, ਦੂਜਾ ਇੰਟਰਫੇਸ ਜਾਂ route-map ਅਜੇ ਵੀ ਪ੍ਰਵਾਹ ਦਾ ਅਨੁਵਾਦ ਕਰ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਪੂਰੀ NAT ਸਾਰਣੀ ਪੜ੍ਹਨੀ ਪਵੇਗੀ। ਪੈਕੇਟ ਨੂੰ ਅਜੇ ਵੀ ਰਸਤਾ, ਮੇਲ ਖਾਂਦਾ crypto ACL ਅਤੇ ਅਸਲ ਪਹੁੰਚ-ਨਿਯੰਤਰਣ ਸੀਮਾਵਾਂ 'ਤੇ ਇਜਾਜ਼ਤ ਚਾਹੀਦੀ ਹੈ।

ਘੱਟੋ-ਘੱਟ IOS ਬੰਦੋਬਸਤ deny ਨੂੰ ਉਸੇ ਸੂਚੀ ਵਿੱਚ permit ਤੋਂ ਉੱਪਰ ਰੱਖਦੀ ਹੈ ਅਤੇ overload ਨਿਯਮ ਨੂੰ ਉਸ ਸੂਚੀ ਵੱਲ ਮੋੜਦੀ ਹੈ। ਫਿਰ crypto ACL ਉਹੀ ਜੋੜੀ ਬਚਾਉਂਦਾ ਹੈ ਜਿਸ ਨੂੰ deny ਅਨੁਵਾਦ ਤੋਂ ਬਾਹਰ ਕਰਦਾ ਹੈ।

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

ਦੋਵੇਂ ਮਾਡਲਾਂ ਲਈ ਇੱਕ ਪਰਖਣਯੋਗ ਸਵਾਲ

ਦੋਵੇਂ ਮਾਡਲ ਇੱਕੋ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਕਿਹੜੇ ਨਿਯਮ ਨੇ ਇਸ ਪ੍ਰਵਾਹ ਨਾਲ ਮੇਲ ਖਾਧਾ, ਅਤੇ ਕਿਹੜੇ ਪਤੇ ਇੰਟਰਫੇਸ ਤੋਂ ਬਾਹਰ ਗਏ? ਬਾਹਰੀ ਇੰਟਰਫੇਸ 'ਤੇ ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਗੇਟਵੇ ਤੋਂ ਪਹਿਲਾਂ ਤੇ ਬਾਅਦ ਦੇ ਸਰੋਤ ਪਤੇ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਫਿਰ ਸੁਰੰਗ ਬਾਰੇ ਸਾਹਮਣੇ ਵਾਲੇ ਪਾਸੇ ਦੀ ਦ੍ਰਿਸ਼ਟੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ SA ਉੱਪਰ ਹੋ ਸਕਦਾ ਹੈ ਜਦਕਿ ਸੁਰੱਖਿਅਤ ਪ੍ਰਵਾਹ ਕਿਤੇ ਹੋਰ ਅਨੁਵਾਦ ਹੋ ਰਿਹਾ ਹੋਵੇ।

ASA 'ਤੇ nat detail ਅਤੇ ਅਨੁਵਾਦ ਸਾਰਣੀ ਦਿਖਾਓ; IOS 'ਤੇ ip nat translations ਅਤੇ ਸੰਬੰਧਿਤ ACL ਗਿਣਤੀ ਦਿਖਾਓ। ਜੋ ਨਿਯਮ ਕਦੇ ਨਹੀਂ ਵਧਦਾ ਉਹ ਕਦੇ ਨਹੀਂ ਚੁਣਿਆ ਗਿਆ, ਅਤੇ ਇਹ crypto ਸੰਰਚਨਾ ਨਹੀਂ ਸਗੋਂ ਕ੍ਰਮ, ਇੰਟਰਫੇਸ ਜਾਂ ਦਿਸ਼ਾ ਵੱਲ ਸੰਕੇਤ ਕਰਦਾ ਹੈ।

ਸੰਰਚਨਾ ਆਮ ਤੌਰ 'ਤੇ ਕਿੱਥੇ ਗਲਤ ਹੁੰਦੀ ਹੈ

ਆਮ ਅਸਫਲਤਾਵਾਂ ਯਾਂਤ੍ਰਿਕ ਹਨ। deny permit ਦੇ ਹੇਠਾਂ ਬੈਠਦਾ ਹੈ ਅਤੇ ਕਦੇ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਵਰਗੀਕਰਨ ਗਲਤ ਦਿਸ਼ਾ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਵਾਪਸੀ ਪ੍ਰਵਾਹ ਅਨੁਵਾਦ ਹੁੰਦਾ ਹੈ। Identity ਨਿਯਮ ਸਹੀ ਪਤੇ ਪਰ ਗਲਤ ਇੰਟਰਫੇਸ ਜੋੜੀ ਕਵਰ ਕਰਦਾ ਹੈ। Crypto ACL ਅਜਿਹੀ ਸਬਨੈੱਟ ਬਚਾਉਂਦਾ ਹੈ ਜੋ ਹੁਣ NAT ਨਿਯਮ ਦੇ ਪੇਸ਼ ਕੀਤੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ।

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