Anypoint VPN ਜਾਂ Transit Gateway NAT: ਅਨੁਵਾਦ ਕਿੱਥੇ ਹੁੰਦਾ ਹੈ
Anypoint VPN ਆਪਣੇ ਆਪ ਪਤਿਆਂ ਦਾ ਅਨੁਵਾਦ ਨਹੀਂ ਕਰਦਾ। NAT ਦਾ ਵਾਅਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫਾਇਰਵਾਲ PAT, AWS ਪ੍ਰੀਫਿਕਸ ਨਕਸ਼ਾ ਜਾਂ ਕੋਈ ਹੋਰ ਅਟੈਚਮੈਂਟ ਚੁਣੋ।
NAT ਦੀ ਲੋੜ ਉਦੋਂ ਤੱਕ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਜਦੋਂ ਤੱਕ ਇਹ ਬਦਲਣ ਵਾਲੇ ਪਤਿਆਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਵਾਲੇ ਹਿੱਸੇ ਦਾ ਨਾਮ ਨਾ ਲਵੇ। MuleSoft ਕਨੈਕਟੀਵਿਟੀ ਵਿੱਚ ਉਸ ਫ਼ੈਸਲੇ ਦੇ ਤਿੰਨ ਇਨਪੁਟ ਹੁੰਦੇ ਹਨ: ਕੀ ਬੈਕਐਂਡ ਨੂੰ ਕਈ-ਤੋਂ-ਇੱਕ ਪੋਰਟ ਅਨੁਵਾਦ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਇੱਕ-ਤੋਂ-ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਉਪਨਾਮ, ਕੀ ਤੁਹਾਡੀ ਅਸਲ ਮਾਲਕੀ ਵਾਲਾ AWS ਅਟੈਚਮੈਂਟ ਉਹ ਮੈਪਿੰਗ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਪੂਰਾ ਰਾਹ ਵਿਕਰੇਤਾ ਵੱਲੋਂ ਸਮਰਥਿਤ ਸੰਜੋਗ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਗਲਤ ਹੋਏ ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਚੱਲਦੀ ਪਰ ਸਮੀਖਿਆ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਲੈਬ ਬਣਾਓਗੇ।
ਇੱਕ ਹੀ ਸਥਿਰ ਨੁਕਤਾ ਇਹ ਹੈ ਕਿ Anypoint VPN ਆਪਣੇ ਆਪ ਅਨੁਵਾਦ ਜੰਤਰ ਨਹੀਂ ਹੈ। CloudHub 2.0 ਦਸਤਾਵੇਜ਼ ਉੱਥੇ NAT ਨੂੰ ਅਸਮਰਥਿਤ ਵਜੋਂ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਟਨਲ ਤੁਹਾਡੇ ਵਰਕਰਾਂ ਦੇ ਪਤੇ ਲੁਕਾਏਗਾ ਮੰਨਣ ਵਾਲਾ ਕੋਈ ਵੀ ਡਿਜ਼ਾਈਨ ਪਹਿਲਾਂ ਹੀ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ।
ਤੈਅ ਕਰੋ ਕਿ ਅਨੁਵਾਦ ਨੂੰ ਕੀ ਕਰਨਾ ਹੈ
ਜੇ ਬਹੁਤ ਸਾਰੇ ਐਪਲੀਕੇਸ਼ਨ ਵਰਕਰਾਂ ਨੂੰ ਬੈਕਐਂਡ ਸਾਹਮਣੇ ਇੱਕ ਪਤੇ ਵਜੋਂ ਦਿਸਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਲੋੜ ਸਾਂਝਾ ਸਰੋਤ ਅਨੁਵਾਦ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਵਾਲੇ ਫਾਇਰਵਾਲ 'ਤੇ ਸਥਿਤੀ ਰੱਖਣ ਵਾਲਾ SNAT ਜਾਂ PAT। ਉਸ ਹਿੱਸੇ ਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਰਾਹ 'ਤੇ ਬੈਠਣਾ ਚਾਹੀਦਾ ਹੈ, ਫਲੋ ਦੀ ਪੂਰੀ ਉਮਰ ਆਪਣੀ ਸਥਿਤੀ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਲਿਖੇ ਹਰ ਕਨੈਕਸ਼ਨ ਦਾ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਸੈਸ਼ਨ ਦੇ ਵਿਚਕਾਰ ਸਥਿਤੀ ਗੁਆਉਣਾ ਕਨੈਕਸ਼ਨ ਨੂੰ ਕਮਜ਼ੋਰ ਨਹੀਂ ਕਰਦਾ; ਇਹ ਇਸਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਸਥਿਤੀ ਸਾਂਝੀ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਵਾਲੀ ਫਾਇਰਵਾਲ ਜੋੜੀ ਫੇਲਓਵਰ ਤੋਂ ਬਾਅਦ ਸਟੈਂਡਬਾਏ ਮੈਂਬਰ 'ਤੇ ਆਉਣ ਵਾਲਾ ਹਰ ਸੈਸ਼ਨ ਛੱਡ ਦੇਵੇਗੀ। ਉਸ ਹਿੱਸੇ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ ਫਲੋ ਲਈ ਮਾਪੋ, ਥ੍ਰੂਪੁਟ ਲਈ ਨਹੀਂ।
ਜੇ ਦੋ ਨੈੱਟਵਰਕ ਓਵਰਲੈਪ ਹੁੰਦੇ ਹਨ ਅਤੇ ਹਰ ਹੋਸਟ ਨੂੰ ਵੱਖਰਾ ਉਪਨਾਮ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਲੋੜ ਸਪਸ਼ਟ ਮੈਪ ਕੀਤੇ ਪ੍ਰੀਫਿਕਸ, ਮੇਲ ਖਾਂਦੇ ਰੂਟ ਅਤੇ ਮੈਪਿੰਗ ਨਾਲ ਸਹਿਮਤ ਨਾਮ ਹੱਲ ਵਾਲੀ ਇੱਕ-ਤੋਂ-ਇੱਕ ਪਤਾ ਯੋਜਨਾ ਹੈ। ਹਰ ਵਰਕਰ ਨੂੰ ਇੱਕ ਪਤੇ ਪਿੱਛੇ ਲੁਕਾਉਣਾ ਇਸਦਾ ਸਸਤਾ ਸੰਸਕਰਣ ਨਹੀਂ ਹੈ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਸਮੀਖਿਆ ਵਿੱਚ ਇੱਕ ਨੂੰ ਦੂਜੇ ਨਾਲ ਬਦਲਣਾ ਹੀ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਤਿਮਾਹੀ ਗੁਆਉਣ ਦਾ ਕਾਰਨ ਹੈ।
ਉਤਪਾਦ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਫ਼ੈਸਲਾ ਠੋਸ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲਿਖੋ: ਮੂਲ ਸਰੋਤ, ਮੂਲ ਮੰਜ਼ਿਲ, ਅਨੁਵਾਦਿਤ ਮੁੱਲ, ਸ਼ੁਰੂਆਤ ਦੀ ਦਿਸ਼ਾ, ਅਨੁਵਾਦਕ ਦਾ ਮਾਲਕ ਅਤੇ ਉਮੀਦ ਕੀਤਾ ਜਵਾਬ ਰਾਹ। ਇਹ ਵੀ ਜੋੜੋ ਕਿ ਬੈਕਐਂਡ ਲੌਗ ਕਿਹੜੀ ਪਛਾਣ ਰੱਖਣਗੇ, ਕਿਉਂਕਿ ਸਾਰੇ ਸਰੋਤ ਲੁਕਾਉਣ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਗਾਹਕ-ਪੱਧਰੀ ਆਡਿਟ ਵੀ ਨਸ਼ਟ ਕਰਦਾ ਹੈ।
ਜਾਂਚੋ ਕਿ AWS ਤੁਹਾਡੇ ਲਈ ਮੈਪਿੰਗ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ
AWS ਹੁਣ Transit Gateway ਅਤੇ Cloud WAN ਅਟੈਚਮੈਂਟਾਂ 'ਤੇ ਪ੍ਰਬੰਧਿਤ ਇੱਕ-ਤੋਂ-ਇੱਕ NAT ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਜਿਸਦੀ ਘੋਸ਼ਣਾ 2026 ਦੇ ਅਕਤੂਬਰ ਦੇ ਅਖੀਰ ਵਿੱਚ ਹੋਈ, ਇਸ ਲਈ ਇਹ ਪੁਰਾਣਾ ਆਮ ਦਾਅਵਾ ਕਿ ਟਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਕਦੇ ਅਨੁਵਾਦ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਹੁਣ ਪੁਰਾਣਾ ਹੋ ਗਿਆ ਹੈ। Transit Gateway NAT ਦਸਤਾਵੇਜ਼ ਸਥਿਤੀ-ਰਹਿਤ IPv4 ਪ੍ਰੀਫਿਕਸ ਮੈਪਿੰਗ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ: ਮੂਲ ਅਤੇ ਅਨੁਵਾਦਿਤ ਪ੍ਰੀਫਿਕਸ ਇੱਕੋ ਲੰਬਾਈ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਹੋਸਟ ਬਿੱਟ ਤੇ ਆਵਾਜਾਈ ਪੋਰਟ ਅਨੁਵਾਦ ਤੋਂ ਬਚਦੇ ਹਨ। ਇਨਗ੍ਰੈਸ ਅਤੇ ਐਗ੍ਰੈਸ ਦਿਸ਼ਾਵਾਂ ਨੂੰ ਵੱਖਰੇ ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਿਆਂ ਵਜੋਂ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਇਹ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸੰਰਚਿਤ ਹੁੰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਤਿਆਰ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਦੂਜਾ ਨਾ ਹੋਵੇ। ਉਸ ਵਰਣਨ ਵਿੱਚ ਕੁਝ ਵੀ ਫਲੋ-ਪੱਧਰੀ ਸਥਿਤੀ ਦਾ ਸੰਕੇਤ ਨਹੀਂ ਦਿੰਦਾ, ਇਸ ਲਈ ਇਹ ਨਾ ਸੋਚੋ ਕਿ ਮੈਪਿੰਗ ਤੁਹਾਡੇ ਲਈ ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕ ਕਰੇਗਾ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ 10.80.0.0/16 ਨੂੰ 172.28.0.0/16 'ਤੇ ਮੈਪ ਕਰਨ ਨਾਲ 10.80.10.23 172.28.10.23 ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ /16 ਨੂੰ ਇੱਕ ਪਤੇ ਵਿੱਚ ਨਹੀਂ ਸਮੇਟਦਾ ਅਤੇ PAT ਦੀ ਲੋੜ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ। ਇਹ ਚੁਣੇ ਹੋਏ ਅਟੈਚਮੈਂਟ ਕਿਸਮਾਂ ਨੂੰ ਵੀ ਕਵਰ ਕਰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ VPC ਅਤੇ Site-to-Site VPN ਸ਼ਾਮਲ ਹਨ, ਪਰ Client VPN ਅਟੈਚਮੈਂਟ ਨਹੀਂ, ਅਤੇ ਸੰਰਚਨਾ Anypoint ਪਾਸੇ ਨਹੀਂ, ਟਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਦੇ ਮਾਲਕ ਕੋਲ ਹੁੰਦੀ ਹੈ।
ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਇੱਕ ਹੋਰ ਸੰਭਾਵੀ ਨਿਯੰਤਰਣ ਬਿੰਦੂ ਮੰਨੋ, ਇਸਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਤੁਹਾਡੀ ਤੈਨਾਤੀ ਇਸਨੂੰ ਵਰਤ ਸਕਦੀ ਹੈ। CloudHub 2.0 ਗਾਹਕ ਦੇ ਆਪਣੇ AWS ਖਾਤੇ ਵਿੱਚ ਟਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਨਾਲ ਪ੍ਰਾਈਵੇਟ-ਸਪੇਸ ਅਟੈਚਮੈਂਟਾਂ ਨੂੰ ਖੇਤਰੀ ਅਤੇ ਹੱਕ ਸ਼ਰਤਾਂ ਸਮੇਤ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਨਵੇਂ ਵਿਕਲਪ ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਅਟੈਚਮੈਂਟ ਕਿਸਮ, ਇਸਦਾ ਮਾਲਕ ਅਤੇ ਵਿਕਰੇਤਾ ਦਾ ਸਮਰਥਨ ਰੁਖ ਪੁਸ਼ਟੀ ਕਰੋ।
ਰਾਹ ਨੂੰ ਸਮਰਥਿਤ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰੱਖੋ
ਫਾਇਰਵਾਲ ਅਨੁਵਾਦਕ ਲਈ, ਚੱਲਦੇ ਟਨਲ ਵਿੱਚ ਆਮ NAT ਨਿਯਮ ਚਿਪਕਾਉਣ ਦੀ ਥਾਂ ਉਸ ਉਤਪਾਦ ਦਾ ਸਮਰਥਿਤ VPN, ਅਨੁਵਾਦ ਅਤੇ ਰਾਊਟਿੰਗ ਮਾਡਲ ਵਰਤੋ। ਬੈਕਐਂਡ ਦਾ ਜਵਾਬ ਉਸੇ ਅਨੁਵਾਦ ਹਿੱਸੇ ਰਾਹੀਂ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਿਹਤਮੰਦ ਆਉਟਬਾਊਂਡ ਟਨਲ ਉਸ ਵਾਪਸੀ ਰਾਹ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।
ਟਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਰਾਹ ਲਈ, ਪ੍ਰਾਈਵੇਟ-ਸਪੇਸ ਅਟੈਚਮੈਂਟ, ਸੰਬੰਧਿਤ ਰਾਊਟ ਟੇਬਲ, ਆਨ-ਪ੍ਰੀਮਾਈਸ ਅਟੈਚਮੈਂਟ ਅਤੇ ਉਹ ਹਿੱਸੇ ਸੂਚੀਬੱਧ ਕਰੋ ਜੋ ਗਾਹਕ ਅਸਲ ਵਿੱਚ ਸੰਰਚਿਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਵੱਖਰੀ ਕਨੈਕਟੀਵਿਟੀ ਆਰਕੀਟੈਕਚਰ ਹੈ, ਮੌਜੂਦਾ Anypoint VPN ਕਨੈਕਸ਼ਨ 'ਤੇ ਲੱਗਿਆ NAT ਚੈੱਕਬਾਕਸ ਨਹੀਂ, ਅਤੇ ਸਮਰਥਨ ਸੀਮਾ ਇਸਦੇ ਨਾਲ ਖਿਸਕਦੀ ਹੈ।
ਤਿੰਨ ਵਿਕਲਪਾਂ ਦੀ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਤੁਲਨਾ ਕਰੋ
ਬਹੁਤੀਆਂ ਟੀਮਾਂ ਨੂੰ ਸਿਰਫ਼ ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਹੁੰਦੇ ਹਨ: ਕਈ-ਤੋਂ-ਇੱਕ ਜਾਂ ਇੱਕ-ਤੋਂ-ਇੱਕ, ਅਤੇ ਅਟੈਚਮੈਂਟ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਉਹਨਾਂ ਜਵਾਬਾਂ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਵਿਕਲਪ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
ਤੀਜੀ ਕਾਲਮ ਨੂੰ ਬਾਅਦ ਦੀ ਸੋਚ ਵਜੋਂ ਨਹੀਂ, ਸਮੀਖਿਆ ਦੇ ਸਵਾਲ ਵਜੋਂ ਪੜ੍ਹੋ। ਕਾਗਜ਼ 'ਤੇ ਮਨਜ਼ੂਰ ਪਰ ਤੁਹਾਡੀ ਮਾਲਕੀ ਤੋਂ ਬਿਨਾਂ ਅਟੈਚਮੈਂਟ 'ਤੇ ਸੰਰਚਿਤ ਪ੍ਰੀਫਿਕਸ ਨਕਸ਼ਾ ਅਜੇ ਵੀ ਰੁਕਿਆ ਪ੍ਰੋਜੈਕਟ ਹੈ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਲੰਘਾਉਣ ਵਾਲਾ ਪਰ ਗਾਹਕ-ਪੱਧਰੀ ਲੌਗਿੰਗ ਤੋੜਨ ਵਾਲਾ PAT ਨਿਯਮ ਅਗਲੀ ਆਡਿਟ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।
ਵਾਅਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੈਪਿੰਗ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
ਰਾਹ ਰਾਹੀਂ ਇੱਕ ਨਵਾਂ ਐਪਲੀਕੇਸ਼ਨ ਓਪਰੇਸ਼ਨ ਭੇਜੋ ਅਤੇ ਸਿਰਫ਼ ਬੇਨਤੀ ਨਹੀਂ, ਜਵਾਬ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਬੈਕਐਂਡ ਮਾਲਕ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਹਨਾਂ ਦੇ ਲੌਗ ਨੇ ਕਿਹੜਾ ਸਰੋਤ ਪਤਾ ਦਰਜ ਕੀਤਾ, ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪਤਾ-ਪਰਿਵਾਰ ਦਾ ਵਿਵਹਾਰ ਯੋਜਨਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਜਾਂਚੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਿਸ ਰਾਹ ਨੂੰ ਰੱਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਉਹ ਅਜੇ ਵੀ ਰੱਦ ਹੁੰਦਾ ਹੈ। ਪੁਰਾਣਾ ਕਨੈਕਸ਼ਨ ਤੁਹਾਡੇ ਵੱਲੋਂ ਹੁਣੇ ਬਦਲੇ ਮੈਪਿੰਗ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।
ਬੈਕਐਂਡ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਇਸਦੀ ਇਜਾਜ਼ਤ-ਸੂਚੀ ਪੂਰੀ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਅਨੁਵਾਦਿਤ ਪਤੇ ਤੋਂ ਸੁਤੰਤਰ ਰੱਖੋ, ਕਿਉਂਕਿ ਮੈਪਿੰਗ ਨੈੱਟਵਰਕ ਪਲੰਬਿੰਗ ਹੈ, ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਦਾ ਫ਼ੈਸਲਾ ਨਹੀਂ। ਜਿਸ ਪਲ ਪਾਸਵਰਡ ਰੀਸੈਟ NAT ਪ੍ਰੀਫਿਕਸ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ, ਉਸ ਪਲ ਤੋਂ ਹਰ ਭਵਿੱਖੀ ਰੇਂਜ ਬਦਲਾਅ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦਾ ਹੈ।
ਮਨਜ਼ੂਰੀ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਜਵਾਬ ਲਿਖੋ: ਅਨੁਵਾਦ ਦੀ ਕਿਸਮ, ਅਨੁਵਾਦਕ ਦਾ ਮਾਲਕ, ਅਤੇ ਇਸਨੂੰ ਢੋਣ ਵਾਲਾ ਸਮਰਥਿਤ ਅਟੈਚਮੈਂਟ ਜਾਂ ਉਤਪਾਦ ਰਾਹ। ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਜੇ ਅੰਦਾਜ਼ਾ ਹੈ, ਤਾਂ ਡਿਜ਼ਾਈਨ ਬਦਲਾਅ ਵਿੰਡੋ ਲਈ ਤਿਆਰ ਨਹੀਂ।