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

ਜਾਂਚ 1: ਟਨਲ ਸਰੋਤ ਦੇ ਪਤੇ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ

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

ਅਨੁਵਾਦ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਕਾਊਂਟਰਾਂ ਅਤੇ ਰੂਟ ਟੇਬਲ ਨਾਲ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਜੇ ਹਬ ਤੋਂ ਟਨਲ ਰਾਹੀਂ ਸਰੋਤ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ ਜਾ ਸਕਦਾ, ਤਾਂ ਇਸ ਸੂਚੀ ਵਿੱਚ ਅੱਗੇ ਕੁਝ ਵੀ ਇਸ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਜੇ ਸੁਰੱਖਿਅਤ ਰੇਂਜ ਅਤੇ ਸਰੋਤ ਦਾ ਪਤਾ ਮੇਲ ਨਾ ਖਾਣ, ਤਾਂ ਇੱਥੇ ਹੀ ਰੁਕੋ।

ਜਾਂਚ 2: ਤੈਅ ਕਰੋ ਕਿ ਸ਼ਾਖਾ ਕਿਹੜਾ ਸਰੋਤ ਦੇਖੇਗੀ

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

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

ਜਾਂਚ 3: ਅਸਲ ਇੰਟਰਫੇਸਾਂ ਦੇ ਮੁਤਾਬਕ ਅਨੁਵਾਦ ਲਿਖੋ

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

ਤੁਸੀਂ ਜੋ ਮਾਰਗ ਬਣਾ ਰਹੇ ਹੋ ਉਸ ਦੇ ਚਾਰ ਹਿੱਸੇ ਹਨ, ਅਤੇ ਚਾਰੇ ਮੇਲ ਖਾਣੇ ਚਾਹੀਦੇ ਹਨ:

LegSourceDestination
Request from the internet198.51.100.25203.0.113.20:443
After destination translation198.51.100.2510.60.20.10:443
After source translation toward the tunnel10.10.250.1010.60.20.10:443
Branch reply10.60.20.1010.10.250.10
Restored reply to the client203.0.113.20198.51.100.25

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

ਜਾਂਚ 4: ਪਹੁੰਚ ਨਿਯਮ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ ਤੱਕ ਸੀਮਿਤ ਕਰੋ

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

ਉਸੇ ਸਮੇਂ ਨਿਯਮਾਂ ਦਾ ਕ੍ਰਮ ਜਾਂਚੋ। ਤੁਹਾਡੇ ਖਾਸ ਨਿਯਮ ਉੱਤੇ ਬੈਠੀ ਵਿਸ਼ਾਲ ਇਜਾਜ਼ਤ ਖਾਸ ਨਿਯਮ ਨੂੰ ਅਦਿੱਖ ਬਣਾ ਦਿੰਦੀ ਹੈ।

ਜਾਂਚ 5: ਇੱਕ ਬੇਨਤੀ ਅਤੇ ਉਸ ਦਾ ਜਵਾਬ ਟਰੇਸ ਕਰੋ

ਬ੍ਰਾਊਜ਼ਰ ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਲੁਕਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਅਸਫਲ ਹੋਇਆ। ਹਬ ਉੱਤੇ ਪ੍ਰਵਾਹ ਟਰੇਸ ਕਰੋ ਅਤੇ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਨਤੀਜਾ ਪੜ੍ਹੋ।

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

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

ਫਿਰ ਬਾਹਰ ਤੋਂ ਇੱਕ ਅਸਲ ਬੇਨਤੀ ਭੇਜੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਉਸੇ ਟਨਲ ਰਾਹੀਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਪ੍ਰਕਾਸ਼ਿਤ ਐਂਟਰੀ, ਅਨੁਵਾਦ, ਸੁਰੱਖਿਅਤ ਪਤਿਆਂ ਦੀ ਜੋੜੀ ਅਤੇ ਵਾਪਸੀ ਰੂਟ ਨੂੰ ਪ੍ਰਕਾਸ਼ਨ ਰਿਕਾਰਡ ਵਜੋਂ ਦਰਜ ਕਰੋ।

ਸੰਬੰਧਿਤ ਲੇਖ