NAT ਪਿੱਛੇ FortiGate: local-gw, localid ਅਤੇ ਜਨਤਕ IP

NAT ਪਿੱਛੇ FortiGate ਆਪਣੇ WAN ਇੰਟਰਫੇਸ 'ਤੇ 10.0.0.2 ਰੱਖ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇੰਟਰਨੈੱਟ ਇਸਨੂੰ 198.51.100.40 ਵਜੋਂ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਸੰਖਿਆਵਾਂ ਅਸਲੀ ਹਨ। ਜਿਸ ਪਤੇ ਨਾਲ ਡਿਵਾਈਸ ਬੱਝਦੀ ਹੈ ਅਤੇ IKE ਪ੍ਰਮਾਣਿਕਤਾ ਦੌਰਾਨ ਜੋ ਪਛਾਣ ਭੇਜਦੀ ਹੈ, ਉਹ ਵੱਖਰੇ ਫੈਸਲੇ ਹਨ, ਵੱਖਰੇ ਖੇਤਰਾਂ ਵਿੱਚ, ਵੱਖਰੇ ਦਰਸ਼ਕਾਂ ਲਈ ਲਏ ਗਏ। NAT ਰਾਹ ਵਿੱਚ ਬਾਹਰੀ ਪਤਾ ਮੁੜ ਲਿਖਦਾ ਹੈ; ਪ੍ਰਮਾਣਿਤ ਪਛਾਣ ਨੂੰ ਦੂਰ ਦੇ ਪੀਅਰ ਦੀ ਉਮੀਦ ਅਨੁਸਾਰ ਮੁੜ ਨਹੀਂ ਲਿਖਦਾ। ਇਸ ਰੂਪ ਵਿੱਚ ਬਹੁਤੀਆਂ ਫੇਜ਼ 1 ਅਸਫਲਤਾਵਾਂ ਸਹੀ ਮੁੱਲ ਗਲਤ ਖੇਤਰ ਵਿੱਚ ਰੱਖਣ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ।

ਤਿੰਨ ਮੁੱਲ, ਤਿੰਨ ਮਾਲਕ

ਤਿੰਨ ਮੁੱਲਾਂ ਅਤੇ ਹਰੇਕ ਦੇ ਮਾਲਕ ਦਾ ਨਾਮ ਦੱਸ ਕੇ ਸ਼ੁਰੂ ਕਰੋ। local-gw ਉਹ ਪਤਾ ਹੈ ਜੋ FortiGate ਆਪਣੇ ਬਾਹਰੀ ਇੰਟਰਫੇਸ 'ਤੇ IKE ਦੇ ਸਰੋਤ ਵਜੋਂ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਹ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਡਿਵਾਈਸ ਕੋਲ ਅਸਲ ਵਿੱਚ ਹੈ। ਜਨਤਕ ਐਂਡਪੁਆਇੰਟ NAT ਡਿਵਾਈਸ ਦਾ ਪਤਾ ਹੈ, ਅਤੇ ਇਹ ਅਨੁਵਾਦ ਕਰਨ ਵਾਲੇ ਦੀ ਮਲਕੀਅਤ ਹੈ। IKE ਪਛਾਣ ਇੱਕ ਸਤਰ ਹੈ ਜੋ ਪੀਅਰ ਆਪਣੀ ਕਨਫਿਗਰੇਸ਼ਨ ਨਾਲ ਮਿਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ IP ਪਤਾ ਹੋਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ।

ਖੇਤਰਾਂ ਦੇ ਨਾਮ ਬਦਲੀ ਲਈ ਸੱਦਾ ਦੇਣ ਜਿੰਨੇ ਨੇੜੇ ਹਨ, ਅਤੇ ਇਹੀ ਜਾਲ ਹੈ। localid ਅਤੇ localid-type ਪਛਾਣ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ; local-gw ਸਥਾਨਕ ਬੰਧਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

ਇੱਕ ਉਦਾਹਰਨ ਫਰਕ ਨੂੰ ਠੋਸ ਬਣਾਉਂਦੀ ਹੈ। FortiGate 'ਤੇ config vpn ipsec phase1-interface ਖੋਲ੍ਹੋ, ਫਿਰ set interface "wan1" ਅਤੇ set local-gw 10.0.0.2 — ਬਾਕਸ ਕੋਲ ਮੌਜੂਦ ਪਤਾ, ਅਤੇ ਇਹੀ IKE ਸਾਕਟ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਬੱਝਣ ਦਿੰਦਾ ਹੈ। local-gw 0.0.0.0 'ਤੇ ਛੱਡੋ ਤਾਂ ਇੰਟਰਫੇਸ ਦਾ ਪਤਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਇਹੀ ਚੀਜ਼ ਹੈ ਪਰ ਘੱਟ ਸਪਸ਼ਟ। local-gw 198.51.100.40 'ਤੇ ਸੈੱਟ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਡਿਵਾਈਸ ਕੋਲ ਉਹ ਪਤਾ ਨਹੀਂ ਹੈ ਅਤੇ ਸਾਕਟ ਉਸ ਨਾਲ ਨਹੀਂ ਬੱਝੇਗਾ। ਦੋ ਮੁੱਲਾਂ ਨੂੰ ਕਾਗਜ਼ 'ਤੇ ਬਰਾਬਰ ਦਿਖਾਉਣਾ ਕਨਫਿਗਰੇਸ਼ਨ ਨਹੀਂ ਹੈ।

ਕਦਮ 1: ਉਹ ਪਛਾਣ ਚੁਣੋ ਜੋ ਪੀਅਰ ਸਵੀਕਾਰ ਕਰੇਗਾ

ਹੁਣ ਪਛਾਣ, ਜੋ ਵੱਖਰਾ ਫੈਸਲਾ ਹੈ। set localid ਉਹ ਮੁੱਲ ਲੈਂਦਾ ਹੈ ਜੋ ਪੀਅਰ ਤੁਲਨਾ ਕਰੇਗਾ, ਅਤੇ set localid-type FortiGate ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਇਸਦੀ ਵਿਆਖਿਆ ਕਿਵੇਂ ਕਰਨੀ ਹੈ: ਪਤਾ, FQDN, ਵਰਤੋਂਕਾਰ FQDN ਜਾਂ ਕੁੰਜੀ ID। auto ਨਾਲ ਡਿਵਾਈਸ ਇਸਨੂੰ ਕੱਢਦੀ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਦੇ ਪਤੇ ਤੋਂ, ਜੋ NAT ਡਿਵਾਈਸ ਬਦਲਣ ਵਾਲਾ ਮੁੱਲ ਹੀ ਹੈ।

ਇਹੀ ਕੱਢਣਾ ਇਸ ਟੋਪੋਲੋਜੀ ਵਿੱਚ ਸਪਸ਼ਟ ਪਛਾਣ ਦੇ ਮਹੱਤਵ ਦਾ ਕਾਰਨ ਹੈ। ਜੇ ਪੀਅਰ ਪਤਾ-ਪਛਾਣ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਤਾਂ localid-type address ਅਤੇ localid ਨੂੰ ਉਸ ਜਨਤਕ ਪਤੇ 'ਤੇ ਸੈੱਟ ਕਰੋ ਜੋ ਪੀਅਰ ਦੇਖੇਗਾ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪੀਅਰ ਉਸ ਮੁੱਲ ਨੂੰ ਰਾਊਟਿੰਗ ਟਾਰਗੇਟ ਵਜੋਂ ਨਹੀਂ ਸਗੋਂ ਪਛਾਣ ਵਜੋਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਜੇ ਪੀਅਰ FQDN ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਤਾਂ localid-type fqdn ਅਤੇ ਜਿਸ ਨਾਮ ਨਾਲ ਇਹ ਕਨਫਿਗਰ ਹੋਇਆ ਸੀ ਉਹ ਵਰਤੋ। ਅਸਲ ਵਿੱਚ ਕੀ ਭੇਜਿਆ ਗਿਆ ਇਹ diagnose vpn ike gateway list ਨਾਲ ਜਾਂਚੋ, ਜੋ ਗੇਟਵੇ ਦੀ ਸਥਿਤੀ ਅਤੇ ਵਰਤੋਂ ਵਿੱਚ ਲਏ ਪਛਾਣਕਰਤਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਤੁਸੀਂ ਜੋ ਟਾਈਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ ਉਹ ਨਹੀਂ। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਪਛਾਣ-ਕਿਸਮ ਦਾ ਵਿਕਲਪ ਕੋਈ ਵੀ ਗੈਰ-ਸਥਾਨਕ ਪਤਾ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ; ਪਹਿਲਾਂ ਰਿਲੀਜ਼ ਦੀ ਦਸਤਾਵੇਜ਼ੀ ਅਰਥ-ਸ਼ਾਸਤਰ ਜਾਂਚੋ।

ਕਦਮ 2: UDP 500 ਅਤੇ 4500 ਡਿਵਾਈਸ ਵੱਲ ਭੇਜੋ

ਤੀਜਾ ਮੁੱਲ NAT ਡਿਵਾਈਸ ਦਾ ਹੈ, ਅਤੇ ਲੋਕ ਜਾਂਚਣਾ ਭੁੱਲ ਜਾਂਦੇ ਹਨ ਉਹੀ। ਜਨਤਕ ਐਂਡਪੁਆਇੰਟ ਨੂੰ UDP 500 ਅਤੇ UDP 4500 FortiGate ਵੱਲ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ NAT-T ਖੋਜ ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲਾ ਐਨਕੈਪਸੁਲੇਟਿਡ ESP ਦੋਵੇਂ ਇਹਨਾਂ ਪੋਰਟਾਂ ਦੇ ਆਉਣ 'ਤੇ ਨਿਰਭਰ ਹਨ। ਇਹ ਡਿਜ਼ਾਈਨ ਇੱਕ-ਤੋਂ-ਇੱਕ ਮੈਪਿੰਗ ਮੰਨਦਾ ਹੈ; ਇੱਕ ਜਨਤਕ ਪਤਾ ਕਈ ਪੀਅਰਾਂ ਵਿਚਕਾਰ ਪੋਰਟ ਅਧਾਰਿਤ ਸਾਂਝਾ ਕਰਨਾ ਵੱਖਰੀ ਸੀਮਾ ਵਾਲੀ ਵੱਖਰੀ ਟੋਪੋਲੋਜੀ ਹੈ।

ਭੇਜਣ ਦੀ ਪੁਸ਼ਟੀ ਕੈਪਚਰ ਨਾਲ ਕਰੋ, ਆਸ ਨਾਲ ਨਹੀਂ: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪੈਕੇਟ ਆ ਰਹੇ ਹਨ ਜਾਂ ਨਹੀਂ ਅਤੇ ਜਵਾਬ ਜਾ ਰਹੇ ਹਨ ਜਾਂ ਨਹੀਂ।

Google Cloud VPN NAT ਪਿੱਛੇ ਪੀਅਰ ਲਈ ਸਮਰਥਿਤ ਪ੍ਰਬੰਧ ਵਜੋਂ NAT-T ਨਾਲ ਇੱਕ-ਤੋਂ-ਇੱਕ NAT ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੇ ਦੂਰ ਦਾ ਸਿਰਾ Cloud VPN ਗੇਟਵੇ ਹੈ ਤਾਂ ਇਹੀ ਸੀਮਾ ਹੈ ਜਿਸਦੇ ਖਿਲਾਫ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਹੈ। ਇੱਕ-ਤੋਂ-ਕਈ ਜਾਂ ਪੋਰਟ ਅਧਾਰਿਤ ਸਾਂਝਾ ਕਰਨਾ ਉਹੀ ਸਮਰਥਿਤ ਟੋਪੋਲੋਜੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਸਥਾਨਕ ਪਛਾਣ ਟਿਊਨਿੰਗ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲਦੀ। ਜੇ ਦੂਰ ਦਾ ਪਾਸਾ ਕੋਈ ਹੋਰ ਉਪਕਰਨ ਹੈ, ਤਾਂ ਇਸਦਾ ਆਪਣਾ ਦਸਤਾਵੇਜ਼ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਪਛਾਣ ਵਜੋਂ ਕੀ ਸਵੀਕਾਰ ਕਰੇਗਾ ਅਤੇ ਅਨੁਵਾਦਿਤ ਪੀਅਰ ਪਤਾ ਸਹਿਣ ਕਰੇਗਾ ਜਾਂ ਨਹੀਂ। ਸਥਾਨਕ ਖੇਤਰ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਦੂਰ ਦਾ ਪਾਸਾ ਜੋ ਨਿਯਮ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ, ਸਥਾਨਕ ਪਾਸਾ ਉਸ 'ਤੇ ਗੱਲਬਾਤ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਕਦਮ 3: ਫੇਜ਼ 1 ਕੀ ਹੱਲ ਨਹੀਂ ਕਰਦਾ ਇਹ ਜਾਂਚੋ

NAT ਟ੍ਰੈਵਰਸਲ ਸੁਰੰਗ ਚੁੱਕਦਾ ਹੈ, ਪਛਾਣ ਦੀ ਸਹਿਮਤੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਪੀਅਰ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰੇਗਾ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਅੰਦਰੂਨੀ ਪ੍ਰੀਫਿਕਸ ਰਾਊਟਿੰਗ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਲੰਘਦਾ ਹੈ। ਸਹੀ ਸਥਾਨਕ ID ਗੁੰਮ ਸਟੈਟਿਕ ਰੂਟ ਜਾਂ ਗੁੰਮ ਟ੍ਰੈਫਿਕ ਚੋਣਕਰਤਾ ਨਹੀਂ ਦੇ ਸਕਦਾ।

ਇਸ ਲਈ ਪਰਤਾਂ ਵਿੱਚ ਜਾਂਚੋ। get vpn ipsec tunnel details ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸੁਰੰਗ ਉੱਪਰ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਕਿਹੜੇ ਚੋਣਕਰਤਾ ਗੱਲਬਾਤ ਹੋਏ, ਅਤੇ ਕਨਫਿਗਰ ਕੀਤੇ ਦੂਰ ਦੇ ਸਬਨੈੱਟ ਅਤੇ ਗੱਲਬਾਤ ਹੋਏ ਚੋਣਕਰਤਾ ਵਿਚਕਾਰ ਅੰਤਰ ਫੇਜ਼ 2 ਦੀ ਪੁਸ਼ਾਕ ਵਿੱਚ ਰਾਊਟਿੰਗ ਸਮੱਸਿਆ ਹੈ। execute vpn ike gateway clear ਮੁੜ ਗੱਲਬਾਤ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਮੌਜੂਦਾ ਕਨਫਿਗਰੇਸ਼ਨ ਜਾਂਚ ਰਹੇ ਹੋ, ਤੁਹਾਡੀ ਆਖਰੀ ਤਬਦੀਲੀ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਨਹੀਂ। ਫਿਰ ਦੂਰ ਦੇ ਪ੍ਰੀਫਿਕਸ ਵਿੱਚ ਹੋਸਟ 'ਤੇ ਟ੍ਰੈਫਿਕ ਭੇਜੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਾਊਂਟਰ ਹਿਲਦੇ ਹਨ, ਕਿਉਂਕਿ ਉੱਪਰ ਹੋਣ ਪਰ ਕੁਝ ਵੀ ਨਾ ਲੰਘਾਉਣ ਵਾਲੀ ਸੁਰੰਗ ਜਾਂਚਣ ਤੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਵਰਗੀ ਹੀ ਦਿਸਦੀ ਹੈ।

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

NAT ਡਿਵਾਈਸ ਦਾ ਮੁੜ-ਨੰਬਰੀਕਰਨ FortiGate ਦੇ local-gw ਨੂੰ ਛੂਹਣ ਦਾ ਕਾਰਨ ਨਹੀਂ ਹੈ, ਅਤੇ ਪਛਾਣ ਬਦਲਣਾ ਕੁਝ ਵੀ ਮੁੜ-ਨੰਬਰ ਕਰਨ ਦਾ ਕਾਰਨ ਨਹੀਂ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਅਸੰਬੰਧਿਤ ਰੱਖ-ਰਖਾਅ ਵਿੰਡੋ ਦੌਰਾਨ ਕੰਮ ਕਰਨ ਵਾਲੀ ਸੁਰੰਗ ਮੁੜ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਹੈ। Cloud VPN NAT ਗਾਈਡ ਉਸ ਪਾਸੇ ਦੀ ਸਮਰਥਿਤ ਟੋਪੋਲੋਜੀ ਲਈ ਸੰਦਰਭ ਹੈ।

ਇਸਨੂੰ ਤੈਅ ਕਰਨ ਵਾਲੀ ਜਾਂਚ ਬੋਰਿੰਗ ਅਤੇ ਤੇਜ਼ ਹੈ: ਬਾਹਰੀ ਇੰਟਰਫੇਸ 'ਤੇ ਕੈਪਚਰ ਕਰੋ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ UDP 500 ਅਤੇ 4500 ਪੀਅਰ ਤੋਂ ਆ ਰਹੇ ਹਨ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ IKE ਅਦਾਨ-ਪ੍ਰਦਾਨ ਵਿੱਚ ਪਛਾਣ ਉਸ ਨਾਲ ਮਿਲਦੀ ਹੈ ਜਿਸਦੀ ਉਮੀਦ ਲਈ ਪੀਅਰ ਕਨਫਿਗਰ ਸੀ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਗੱਲਬਾਤ ਹੋਏ ਚੋਣਕਰਤਾ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸਬਨੈੱਟ ਢਕਦੇ ਹਨ। ਜੇ ਪਹਿਲੀ ਜਾਂਚ ਫੇਲ ਹੋਵੇ, ਸ਼ੱਕੀ NAT ਡਿਵਾਈਸ ਹੈ। ਜੇ ਦੂਜੀ, ਪਛਾਣ ਖੇਤਰ ਹਨ। ਜੇ ਤੀਜੀ, ਤਾਂ NAT ਜਾਂ ਪਛਾਣ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ।