ASA: ਇੱਕ ਪਬਲਿਕ IP 'ਤੇ VPN ਪੋਰਟ ਅਤੇ DMZ ਸਟੈਟਿਕ PAT
ਇੱਕ ਪਬਲਿਕ ਪਤਾ, ਦੋ ਸੇਵਾਵਾਂ। VPN ਲਿਸਨਰ ਅਤੇ DMZ PAT ਲਈ ਪਤਾ, ਟਰਾਂਸਪੋਰਟ ਅਤੇ ਪੋਰਟ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਇੱਕ ਦੂਜੇ ਦੀ ਐਂਟਰੀ ਲੈ ਲਵੇ।
ਦੋ ਸੇਵਾਵਾਂ, ਇੱਕ ਪਬਲਿਕ ਪਤਾ, ਅਤੇ ਇੱਕ DNS ਨਾਮ ਜੋ ਪੋਰਟ ਰਾਖਵਾਂ ਰੱਖਦਾ ਜਾਪਦਾ ਹੈ। ਇਹ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦਾ। ASA 'ਤੇ VPN ਐਂਟਰੀ ਦੇ ਕੋਲ DMZ ਸਰਵਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਐਂਟਰੀ ਟਿਊਪਲ ਲਿਖੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ; ਮੌਜੂਦਾ ਸੇਵਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਪਹਿਲਾ ਖੇਤਰ ਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਯੋਜਨਾ ਰੁਕਦੀ ਹੈ. ਹੇਠਾਂ ਸਭ ਕੁਝ ਮੰਨਦਾ ਹੈ ਕਿ VPN ਡਿਵਾਈਸ 'ਤੇ ਹੀ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਅੰਦਰਲੇ ਸਰਵਰ 'ਤੇ ਨਹੀਂ।
ਕਮਾਂਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪੰਜ ਖੇਤਰ ਲਿਖੋ
ਹਰ ਪਬਲਿਕ ਐਂਟਰੀ ਲਈ ਪਤਾ ਪਰਿਵਾਰ, ਪਬਲਿਕ ਪਤਾ, ਟਰਾਂਸਪੋਰਟ, ਪਬਲਿਕ ਪੋਰਟ ਅਤੇ ਮਾਲਕ ਦਰਜ ਕਰੋ। ਮਾਲਕ ASA-ਸਥਾਨਕ ਸੇਵਾ ਜਾਂ ਅਨੁਵਾਦਿਤ ਅੰਦਰਲਾ ਸਰਵਰ ਹੈ। ਦੋ ਐਂਟਰੀਆਂ ਇੱਕ ਪਤਾ ਸਾਂਝਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਵੱਖਰੇ ਟਿਊਪਲ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਦੋ ਐਂਟਰੀਆਂ ਚਿੱਤਰ ਵਿੱਚ ਵੱਖਰੀਆਂ ਦਿਸ ਸਕਦੀਆਂ ਹਨ ਪਰ ਡਿਵਾਈਸ 'ਤੇ ਟਕਰਾ ਸਕਦੀਆਂ ਹਨ।
ਅਸਲੀ ਪੋਰਟ ਲਈ ਦੂਜਾ ਕਾਲਮ ਰੱਖੋ, ਜਿਸ 'ਤੇ ਅੰਦਰਲਾ ਸਰਵਰ ਅਸਲ ਵਿੱਚ ਸੁਣਦਾ ਹੈ। ਪਬਲਿਕ ਪੋਰਟ ਅਤੇ ਅਸਲੀ ਪੋਰਟ ਸੁਤੰਤਰ ਚੋਣਾਂ ਹਨ, ਅਤੇ ਜਿਸ ਪਲ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਕਾਲਮ ਵਿੱਚ ਜੋੜਦੇ ਹੋ, ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਆਪਣਾ ਅਨੁਵਾਦ ਪੜ੍ਹਨ ਦੀ ਸਮਰੱਥਾ ਗੁਆ ਦਿੰਦੇ ਹੋ।
| Public entry | Owner | Real side |
|---|---|---|
| TCP 443 on the outside address | ASA VPN listener | Appliance-local, no translation |
| TCP 8443 on the outside address | Static PAT | DMZ server TCP 443 |
| UDP 443 on the outside address | Check the effective listeners | Possibly the VPN data path |
ਅਸਲੀਆਂ ਅਤੇ ਮੈਪ ਕੀਤੀਆਂ ਸਥਿਤੀਆਂ ਸਹੀ ਪੜ੍ਹੋ
ਤੁਸੀਂ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ ਉਸ ਸਰਵਰ ਤੋਂ ਨਹੀਂ, ਸਗੋਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਟਿਊਪਲ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਉਦਾਹਰਨ ਵੰਡ ਮਨਜ਼ੂਰਸ਼ੁਦਾ VPN ਐਂਟਰੀ ਨੂੰ ਪਬਲਿਕ TCP 443 'ਤੇ ਰੱਖਦੀ ਹੈ ਅਤੇ ਪਬਲਿਕ TCP 8443 'ਤੇ DMZ HTTPS ਸਰਵਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਉਹ ਸਰਵਰ 443 'ਤੇ ਸੁਣਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ:
Public TCP 443 -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443ਤੈਨਾਤ ਕੀਤੀ ਕਮਾਂਡ ਵਿੱਚ ਅਸਲੀ ਸੇਵਾ ਅਤੇ ਮੈਪ ਕੀਤੀ ਸੇਵਾ ਨਿਸ਼ਚਿਤ ਸਥਾਨਾਂ 'ਤੇ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉਲਟਾਉਣਾ ਟੁੱਟਿਆ ਨਹੀਂ ਬਲਕਿ ਵੱਖਰੀ ਮੈਪਿੰਗ ਦੱਸਦਾ ਹੈ। ਚੱਲ ਰਿਹਾ ਅਨੁਵਾਦ ਬੁਝਾਰਤ ਬਣਨ ਦਾ ਇਹ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ: ਸੰਰਚਨਾ ਵੈਧ ਹੈ, ਇਹ ਬੱਸ ਕਿਤੇ ਹੋਰ ਸੰਕੇਤ ਕਰਦੀ ਹੈ।
Cisco ਦੀ ASA 9.16 NAT ਗਾਈਡ ਸਟੈਟਿਕ PAT, ਇੰਟਰਫੇਸ-ਪਤੇ ਦੀ ਵਰਤੋਂ ਅਤੇ ਅਸਲੀ ਬਨਾਮ ਮੈਪ ਕੀਤੀ ਪੋਰਟ ਦੇ ਅਰਥਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦੀ ਹੈ। ਜਿਸ ਰਿਲੀਜ਼ ਨੂੰ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹੋ ਉਸਦਾ ਭਾਗ ਪੜ੍ਹੋ; ਪੁਰਾਣੇ ਪਲੇਟਫਾਰਮ ਤੋਂ ਯਾਦ ਕੀਤੀ ਕਮਾਂਡ ਪੂਰੀ ਮੌਜੂਦਾ ਸੰਰਚਨਾ ਨਹੀਂ ਹੈ।
ਟਰਾਂਸਪੋਰਟ ਨੂੰ ਰਾਖਵੀਂ ਦਾ ਹਿੱਸਾ ਗਿਣੋ
TCP 443 ਅਤੇ UDP 443 ਵੱਖਰੇ ਟਿਊਪਲ ਹਨ, ਅਤੇ ਉਹ ਅੰਤਰ ਤੁਹਾਨੂੰ UDP ਮੁਫ਼ਤ ਨਹੀਂ ਦਿੰਦਾ। VPN ਦੇ ਵੱਖਰੇ TLS ਅਤੇ DTLS ਲਿਸਨਰ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਹੋਰ ਸੰਰਚਿਤ ਸੇਵਾਵਾਂ ਤੁਹਾਡੀ ਲੋੜੀਂਦੀ ਟਰਾਂਸਪੋਰਟ ਪਹਿਲਾਂ ਹੀ ਰੱਖ ਸਕਦੀਆਂ ਹਨ। ਵੈੱਬ ਪੰਨੇ ਨੂੰ ਪੂਰੀ VPN ਐਂਟਰੀ ਮੰਨਣ ਦੀ ਥਾਂ ਪ੍ਰਭਾਵੀ ਲਿਸਨਰ ਅਤੇ ਪਹੁੰਚ ਨੀਤੀ ਦੀ ਸੂਚੀ ਬਣਾਓ।
ਉਸੇ ਪਤੇ 'ਤੇ ਰਿਜ਼ੋਲਵ ਹੋਣ ਵਾਲਾ ਦੂਜਾ ਹੋਸਟਨਾਮ ਵੀ ਟਰਾਂਸਪੋਰਟ-ਪੱਧਰ ਦੀ ਟੱਕਰ ਨਹੀਂ ਸੁਲਝਾਉਂਦਾ। DNS ਨਾਮ-ਤੋਂ-ਪਤਾ ਮੈਪਿੰਗ ਹੈ, ਪੋਰਟ ਦਲਾਲ ਨਹੀਂ, ਅਤੇ PAT ਰਾਹੀਂ ਸਰਵਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ VPN ਲਿਸਨਰ ਨੂੰ ਦੂਜੀ ਪੋਰਟ 'ਤੇ ਲਿਜਾਣ ਵਾਂਗ ਉਹੀ ਕਾਰਵਾਈ ਨਹੀਂ ਹੈ।
ਜੇ VPN ਐਂਟਰੀ ਸੱਚਮੁੱਚ ਹਿਲਾਉਣੀ ਪਵੇ, ਤਾਂ ਚਾਰ ਚੀਜ਼ਾਂ ਇਕੱਠੀਆਂ ਬਦਲਦੀਆਂ ਹਨ: ਕਲਾਇੰਟ ਪਰੋਫਾਈਲ, ਪਬਲਿਕ URL, ਅੱਪਸਟਰੀਮ ਫਿਲਟਰਿੰਗ ਅਤੇ ਤੈਨਾਤੀ ਵਰਤਦੀ ਹਰ ਟਰਾਂਸਪੋਰਟ। ਇੱਕ-ਇੱਕ ਕਰਨ ਦੀ ਥਾਂ ਇੱਕੋ ਵਿੰਡੋ ਵਿੱਚ ਕਰੋ। ਜਿਸ ਸੇਵਾ ਰਾਹੀਂ ਤੁਸੀਂ ਡਿਵਾਈਸ ਤੱਕ ਪਹੁੰਚਦੇ ਹੋ ਉਸ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਡਿਵਾਈਸ ਤੱਕ ਵੱਖਰਾ ਪ੍ਰਬੰਧਨ ਮਾਰਗ ਖੁੱਲ੍ਹਾ ਰੱਖੋ। ਦੂਜੇ ਮਾਰਗ ਤੋਂ ਬਿਨਾਂ, ਹਿਲਾਉਣਾ ਅਜਿਹਾ ਬਦਲਾਅ ਹੈ ਜੋ ਤੁਸੀਂ ਬਾਹਰੋਂ ਵਾਪਸ ਨਹੀਂ ਲੈ ਸਕਦੇ।
ਬਾਹਰੋਂ ਨਵੇਂ ਕਨੈਕਸ਼ਨਾਂ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ
ਪ੍ਰਭਾਵੀ ਪਹੁੰਚ ਨੀਤੀ ਹੇਠ ਸਿਰਫ਼ ਲੋੜੀਂਦੀ DMZ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਗਿਆ ਦਿਓ, ਫਿਰ ਮੇਲ ਖਾਂਦਾ ਅਨੁਵਾਦ ਕ੍ਰਮ, ਸਰਵਰ ਦਾ ਵਾਪਸੀ ਮਾਰਗ ਅਤੇ ਸਰਟੀਫਿਕੇਟ 'ਤੇ ਹੋਸਟਨਾਮ ਜਾਂਚੋ। PAT ਨੈੱਟਵਰਕ ਮੰਜ਼ਿਲ ਬਦਲਦਾ ਹੈ; ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਪਹੁੰਚ ਨਹੀਂ ਦਿੰਦਾ ਅਤੇ ਦੂਜੇ ਹੋਸਟ ਦਾ ਨਾਮ ਵਾਲਾ ਸਰਟੀਫਿਕੇਟ ਠੀਕ ਨਹੀਂ ਕਰਦਾ।
ਅਧਿਕਾਰਤ ਬਾਹਰੀ ਹੋਸਟ ਤੋਂ ਨਵੇਂ ਕਨੈਕਸ਼ਨਾਂ ਨਾਲ ਦੋਵੇਂ ਸੇਵਾਵਾਂ ਦੀ ਪਰਖ ਕਰੋ: VPN ਅਜੇ ਵੀ ਸਥਾਪਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ DMZ ਬੇਨਤੀ ਆਪਣੇ ਲੋੜੀਂਦੇ ਲਿਸਨਰ ਤੱਕ ਪਹੁੰਚਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਪਿਛਲੀ ਸਥਿਤੀ ਰੱਖ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਮਿੰਟ ਪਹਿਲਾਂ ਬਦਲੀ ਮੈਪਿੰਗ ਬਾਰੇ ਇਹ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।
ਤੁਸੀਂ ਤੈਨਾਤ ਕੀਤਾ ਉਸ ਨਾਲ ਐਂਟਰੀ ਸੂਚੀ ਨੂੰ ਅੱਪਡੇਟ ਕਰਕੇ ਚੱਕਰ ਬੰਦ ਕਰੋ, ਜਿਸ ਵਿੱਚ ਬਣਾਏ ਬਿਨਾਂ ਲੱਭਿਆ ਹਰ ਲਿਸਨਰ ਸ਼ਾਮਲ ਹੈ। ਉਸ ਪਤੇ 'ਤੇ ਅਗਲੀ ਵਾਰ ਸੇਵਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਵਾਲਾ ਤੁਹਾਡੀ ਸਾਰਣੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੇਗਾ, ਅਤੇ ਉੱਥੋਂ ਦੀ ਗਲਤ ਕਤਾਰ ਇੱਥੋਂ ਦੀ ਗਲਤ ਕਮਾਂਡ ਨਾਲੋਂ ਵੱਧ ਮਹਿੰਗੀ ਹੈ।