ASA packet-tracer ਨਾਲ VPN ਪ੍ਰਵਾਹ ਨੂੰ ਕਿਵੇਂ ਮਾਡਲ ਕਰੀਏ

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

ਹੇਠਾਂ ਦਿੱਤੀ ਸੈਰ ਮੰਨਦੀ ਹੈ ਕਿ ACL, NAT ਨਿਯਮ ਅਤੇ tunnel-group ਸੰਦਰਭ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਹਨ। ਇਹਨਾਂ ਤੋਂ ਬਿਨਾਂ ਆਉਟਪੁੱਟ ਅਜਿਹੀ ਨੀਤੀ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਜਾਂਚ ਨਹੀਂ ਸਕਦੇ।

ਪੜਾਅ 1: ਅੰਦਰੂਨੀ ਪ੍ਰਵਾਹ ਸਰਲ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲਿਖੋ

ਕੁਝ ਵੀ ਟਾਈਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰੋ। ਅੰਦਰ ਦਾ ਹੋਸਟ ਜੋ ਦੂਰ ਦੇ ਗੇਟਵੇ ਪਿੱਛੇ ਸਰਵਰ ਨਾਲ SSH ਖੋਲ੍ਹਦਾ ਹੈ, ਉਹ ਖਾਸ ਸਰੋਤ ਪੋਰਟ ਵਾਲਾ ਇੱਕ ਅੰਦਰੂਨੀ TCP ਪ੍ਰਵਾਹ ਹੈ। ACL ਅਤੇ VPN ਫਿਲਟਰ ਜਿਸਦਾ ਮੁਲਾਂਕਣ ਕਰਦੇ ਹਨ ਉਹੀ ਪ੍ਰਵਾਹ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਵੀ ਉਹੀ ਟਾਈਪ ਕਰਦੇ ਹੋ।

ਇਸਨੂੰ ਇੱਕ ਵਾਕ ਦੇ ਰੂਪ ਵਿੱਚ ਲਿਖੋ, ਫਿਰ ਖੇਤਰ-ਦਰ-ਖੇਤਰ ਅਨੁਵਾਦ ਕਰੋ:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

ਪੜਾਅ 2: ਇਨਗ੍ਰੈਸ ਅਤੇ ਦਿਸ਼ਾ ਚੁਣੋ

ਇਨਗ੍ਰੈਸ ਉਹ ਇੰਟਰਫੇਸ ਹੈ ਜਿਸ ਉੱਤੇ ਪੈਕੇਟ ਆਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਉਹ ਜਿਸ ਰਾਹੀਂ ਇਹ ਜਾਂਦਾ ਹੈ। ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੇ LAN ਹੋਸਟ ਲਈ ਇਹ inside ਇੰਟਰਫੇਸ ਹੈ। ਉਸੇ ਸੈਸ਼ਨ ਦੇ ਵਾਪਸੀ ਪੈਕੇਟ ਲਈ ਇਹ outside ਇੰਟਰਫੇਸ ਹੈ, ਅਤੇ ਟੂਪਲ ਉਲਟ ਜਾਂਦਾ ਹੈ। ਮੰਜ਼ਿਲ ਨੂੰ ਸਰੋਤ ਵਜੋਂ ਲਿਖਣਾ ਭਰੋਸੇਯੋਗ ਪਰ ਅਪ੍ਰਸਤੁਤ ALLOW ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਦੂਜਾ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ।

ਪੋਰਟਾਂ ਦੀ ਵੀ ਦਿਸ਼ਾ ਹੁੰਦੀ ਹੈ। ਸ਼ੁਰੂ ਕੀਤੀ ਬੇਨਤੀ ਵਿੱਚ ਸੇਵਾ ਪੋਰਟ ਮੰਜ਼ਿਲ ਖੇਤਰ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਅਸਥਾਈ ਪੋਰਟ ਸਰੋਤ ਖੇਤਰ ਵਿੱਚ ਹੁੰਦਾ ਹੈ। TCP ਮੰਜ਼ਿਲ 500 ਵਾਲਾ ਮਾਡਲ 500 ਉੱਤੇ ਸੁਣਨ ਵਾਲੀ TCP ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ; ਕਮਾਂਡ ਵਿੱਚ ਸੰਖਿਆ ਦਿਖਣ ਕਰਕੇ ਇਹ IKE ਟੈਸਟ ਨਹੀਂ ਬਣਦਾ।

ਪੜਾਅ 3: ਪੜਾਅ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ

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

NAT ਲੋਕਾਂ ਨੂੰ ਫਸਾਉਂਦਾ ਹੈ। ਜੇ ਅਨੁਵਾਦਿਤ ਸਰੋਤ ਸੁਰੰਗ ਲਈ ਟ੍ਰੈਫਿਕ ਚੁਣਨ ਵਾਲੇ crypto ACL ਤੋਂ ਬਾਹਰ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਪ੍ਰਵਾਹ ਨੂੰ ਮਨਜ਼ੂਰੀ ਮਿਲ ਸਕਦੀ ਹੈ ਅਤੇ ਕਦੇ ਵੀ ਐਨਕੈਪਸੂਲੇਟ ਨਹੀਂ ਹੋਵੇਗਾ। ਟਰੇਸ ਅਨੁਵਾਦਿਤ ਪਤਾ ਛਾਪਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਦੀ ਤੁਲਨਾ ਮੂਲ ਪਤੇ ਨਾਲ ਨਹੀਂ, ਸੁਰੰਗ ਦੇ ਦਿਲਚਸਪ ਟ੍ਰੈਫਿਕ ਨਾਲ ਕਰੋ।

ਪੜਾਅ 4: ਤੁਸੀਂ ਕਿਹੜੇ ਬਾਈਪਾਸ ਚੁਣੇ ਉਹ ਜਾਂਚੋ

detailed ਰੂਪ ਉਹ ਵਿਕਲਪ ਲੈਂਦਾ ਹੈ ਜੋ ਜਾਂਚਾਂ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ Cisco ACL, VPN ਫਿਲਟਰ, uRPF ਅਤੇ IPsec ਸਪੂਫ਼ ਜਾਂਚਾਂ ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲਾ bypass-checks ਵਿਕਲਪ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਛੱਡ ਕੇ ਪ੍ਰਾਪਤ ALLOW ਕਹਿੰਦਾ ਹੈ ਕਿ ਰੂਟ ਅਤੇ NAT ਕੰਮ ਕਰਨਗੇ, ਇਹ ਨਹੀਂ ਕਿ ਨੀਤੀ ਅਸਲ ਪੈਕੇਟ ਸਵੀਕਾਰ ਕਰੇਗੀ। ਨਤੀਜੇ ਦੇ ਕੋਲ ਵਿਕਲਪ ਲਿਖੋ।

ਜੇ ਤੁਹਾਨੂੰ ਨੀਤੀ ਦਾ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਬਾਈਪਾਸ ਤੋਂ ਬਿਨਾਂ ਚਲਾਓ। ਜੇ ਤੁਸੀਂ ਰੂਟਿੰਗ ਸਵਾਲ ਵੱਖ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਉਹਨਾਂ ਨਾਲ ਚਲਾਓ ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਰੂਟਿੰਗ ਜਵਾਬ ਵਜੋਂ ਲੇਬਲ ਕਰੋ।

ਪੜਾਅ 5: ਅਸਲ ਅਦਲਾ-ਬਦਲੀ ਨਾਲ ਪਾੜਾ ਬੰਦ ਕਰੋ

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

ਕੁਝ trace ਅਤੇ replay ਵਿਕਲਪ ਪੈਕੇਟ ਭੇਜਦੇ ਹਨ ਜਾਂ ਸਥਿਤੀ ਰੱਖਦੇ ਹਨ। ਹਰ ਰੂਪ ਨੂੰ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਖੋਜ ਮੰਨਣ ਦੀ ਬਜਾਏ ਆਪਣੀ ਰਿਲੀਜ਼ ਅਤੇ ਮਨਜ਼ੂਰ ਨਿਦਾਨ ਪ੍ਰਕਿਰਿਆ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਵਿਵਹਾਰ ਦੀ ਪਾਲਣਾ ਕਰੋ।

ਟਰੇਸ ਅਜੇ ਵੀ ਤੁਹਾਨੂੰ ਕੀ ਨਹੀਂ ਦੱਸ ਸਕਦਾ

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

ਅੰਦਰੂਨੀ ਟੂਪਲ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਡਿਜ਼ਾਈਨ ਦੇ ਵਿਰੁੱਧ ਜਾਣ ਵਾਲੇ ਪਹਿਲੇ ਪੜਾਅ ਉੱਤੇ ਰੁਕੋ, ਅਤੇ ਫਿਰ ਹੀ ਐਂਡਪੌਇੰਟ ਸਬੂਤ ਵੱਲ ਜਾਓ। ਟਰੇਸ ਨੀਤੀ ਦਾ ਓਰੈਕਲ ਹੈ, ਡਿਲੀਵਰੀ ਰਸੀਦ ਨਹੀਂ।