ਇੱਕ Azure VPN VM ਉੱਤੇ ਦੋ ਜਨਤਕ IP: ਕਿਹੜਾ ਕੀ ਕਰਦਾ ਹੈ

ਇੱਕ Azure VPN VM ਉੱਤੇ ਦੋ ਜਨਤਕ IP ਉਹ ਉਮੀਦ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜੋ ਘੱਟ ਹੀ ਪੂਰੀ ਹੁੰਦੀ ਹੈ: ਜਿਸ ਪਤੇ ਨਾਲ ਕਲਾਇੰਟ ਜੁੜਦੇ ਹਨ, ਉਹੀ ਪਤਾ ਵੈੱਬਸਾਈਟਾਂ ਨੂੰ ਵੀ ਦਿਸੇਗਾ। ਇਹ ਨਤੀਜਾ ਤਿੰਨ ਸੁਤੰਤਰ ਫੈਸਲਿਆਂ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਪਹਿਲਾ ਹੀ ਟਨਲ ਸਰੋਤੇ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ। ਦੂਜਾ ਉਹ ਮਹਿਮਾਨ ਸਰੋਤ ਹੈ ਜੋ ਅੱਗੇ ਭੇਜੇ ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਤੀਜਾ ਉਹ Azure ਨਿਕਾਸ ਢੰਗ ਹੈ ਜੋ ਉਸ ਸਰੋਤ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਬਦਲੋ ਤੇ ਬਾਕੀ ਦੋ ਜਿੱਥੇ ਸਨ ਉੱਥੇ ਹੀ ਰਹਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਹਰੇਕ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਤੈਅ ਕਰੋ।

ਫੈਸਲਾ 1: ਟਨਲ ਕਿੱਥੇ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ

Azure ਦਾ ਜਨਤਕ IP NIC ਉੱਤੇ ਨਿੱਜੀ IP ਸੰਰਚਨਾ ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ; ਇਹ ਮਹਿਮਾਨ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਅੰਦਰ ਪਾਉਣ ਵਾਲਾ ਪਤਾ ਨਹੀਂ ਹੈ। ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਬਜਾਏ ਮੈਪਿੰਗ ਪੜ੍ਹੋ: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. ਉਹ ਕਿਊਰੀ ਜੋ ਵੀ ਨਿੱਜੀ ਪਤਾ ਵਾਪਸ ਕਰੇ, ਮਹਿਮਾਨ ਨੂੰ ਅਸਲ ਵਿੱਚ ਉਹੀ ਰੱਖਣਾ ਪਵੇਗਾ।

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

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

ਫੈਸਲਾ 2: ਅੱਗੇ ਭੇਜਿਆ ਕਲਾਇੰਟ ਕਿਹੜਾ ਸਰੋਤ ਵਰਤਦਾ ਹੈ

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

ਸੰਕੁਚਿਤ SNAT ਨਿਯਮ ਮਹਿਮਾਨ-ਨਿੱਜੀ ਸਰੋਤ ਚੁਣ ਸਕਦਾ ਹੈ, ਪਰ ਬਾਅਦ ਵਾਲੇ Azure ਅਨੁਵਾਦ ਨੂੰ ਨਹੀਂ ਹਰਾ ਸਕਦਾ। VM ਦੇ ਅੰਦਰ ਹਰ ਕਲਾਇੰਟ ਲਈ ਜਵਾਬਦੇਹੀ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ SNAT ਚੁਣੋ; ਜੇ ਸਬਨੈੱਟ ਦਾ ਨਿਕਾਸ ਡਿਜ਼ਾਈਨ ਪਹਿਲਾਂ ਹੀ ਸਥਿਰ ਜਨਤਕ ਸਰੋਤ ਦਿੰਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਅਨੁਵਾਦ ਸਿਰਫ਼ ਸਥਿਤੀ ਜੋੜੇਗਾ ਤਾਂ ਇਸਨੂੰ ਛੱਡ ਦਿਓ।

ਫੈਸਲਾ 3: ਕਿਹੜਾ Azure ਨਿਕਾਸ ਢੰਗ ਜਿੱਤਦਾ ਹੈ

Microsoftਨਿਕਾਸ ਤਰਜੀਹ ਕ੍ਰਮਦਾ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ: ਜੰਤਰ ਜਾਂ ਗੇਟਵੇ ਵੱਲ ਲਾਗੂ ਰੂਟ ਨੂੰ ਤਰਜੀਹ ਮਿਲਦੀ ਹੈ, ਅਤੇ ਸੰਬੰਧਿਤ ਮਾਰਗ ਉੱਤੇ ਸਬਨੈੱਟ NAT Gateway ਕਨੈਕਟੀਵਿਟੀ ਨੂੰ ਇੰਸਟੈਂਸ-ਪੱਧਰੀ ਜਨਤਕ IP ਉੱਤੇ ਤਰਜੀਹ ਮਿਲਦੀ ਹੈ। ਇਸੇ ਕ੍ਰਮ ਕਾਰਨ 10.20.0.5 ਉੱਤੇ ਅਨੁਵਾਦ ਕਰਨ ਨਾਲ ਇਹ ਸਾਬਤ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਵੈੱਬਸਾਈਟ 198.51.100.20 ਵੇਖੇਗੀ। ਨਿਕਾਸ ਡਿਜ਼ਾਈਨ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਭਾਵੀ ਰੂਟ ਟੇਬਲ, NAT Gateway ਸੰਬੰਧ ਅਤੇ NIC ਦਾ ਜਨਤਕ IP ਇਕੱਠੇ ਪੜ੍ਹੋ।

ਰੱਖੋAzure NIC ਫਾਰਵਰਡਿੰਗ ਸੈਟਿੰਗਨੂੰ Linux ਫਾਰਵਰਡਿੰਗ ਤੋਂ ਵੱਖਰਾ। ਕਲਾਊਡ ਝੰਡਾ ਉਹਨਾਂ ਪੈਕਟਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਸਰੋਤ ਜਾਂ ਮੰਤਵ NIC ਨੂੰ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ; ਇਹ net.ipv4.ip_forward ਸਮਰੱਥ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਮਹਿਮਾਨ ਸੈਟਿੰਗ ਕਲਾਊਡ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੀ।

ਟਨਲ ਸਾਕਟ ਦਾ ਆਪਣਾ ਸਰੋਤ ਫੈਸਲਾ ਹੈ

wg-quick ਅਧੀਨ WireGuard ਦਾ Address WireGuard ਇੰਟਰਫੇਸ ਨੂੰ ਪਤਾ ਦਿੰਦਾ ਹੈ; ਇਹ ਬਾਹਰੀ UDP ਬਾਈਂਡਿੰਗ ਹਦਾਇਤ ਨਹੀਂ ਹੈ। ਇਨਕ੍ਰਿਪਟਿਡ ਸਾਕਟ ਦਾ ਸਰੋਤ ਰੂਟਿੰਗ ਟੇਬਲ ਦੀ ਪੈਰਵੀ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਨੀਤੀ ਰੂਟ ਜਾਂ ਦੂਜਾ ਡਿਫਾਲਟ ਇੰਟਰਫੇਸ ਪਤੇ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਇਸਨੂੰ ਹਿਲਾ ਸਕਦਾ ਹੈ।OpenVPNਦਾ local ਵਿਕਲਪ ਅਤੇ UDP multihome ਉਸੇ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ: ਇਹ ਸਰੋਤੇ ਅਤੇ ਉਸ ਦੇ ਜਵਾਬਾਂ ਬਾਰੇ ਹਨ, ਹਰ ਅੱਗੇ ਭੇਜੇ ਕਲਾਇੰਟ ਦੇ ਇੰਟਰਨੈੱਟ ਸਰੋਤ ਬਾਰੇ ਨਹੀਂ।

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

ਕੀ ਸਵੀਕਾਰ ਕਰਨਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਕ੍ਰਮ ਵਿੱਚ

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

ਸਫਲ ਟਨਲ ਸਿਰਫ਼ ਪਹਿਲਾ ਹਿੱਸਾ ਸਾਬਤ ਕਰਦੀ ਹੈ। ਨਿਕਾਸ ਨੂੰ ਨਵੇਂ ਪ੍ਰਵਾਹ ਨਾਲ ਪਰਖੋ, ਕਿਉਂਕਿ ਕੈਸ਼ ਕੀਤਾ ਕਨੈਕਸ਼ਨ ਰੂਟ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਵੀ ਬਹੁਤ ਦੇਰ ਤੱਕ ਪੁਰਾਣਾ ਸਰੋਤ ਵਰਤ ਸਕਦਾ ਹੈ।