Azure ਵਿੱਚ VPN ਉਪਕਰਣ ਵਾਲਾ VM ਵਾਪਸੀ ਦਾ ਰਾਹ ਕਿਉਂ ਛੱਡ ਦਿੰਦਾ ਹੈ
Azure VM ਵਿੱਚਲੇ VPN ਉਪਕਰਣ ਲਈ UDR, NIC ਦਾ ਫਾਰਵਰਡਿੰਗ ਫਲੈਗ ਅਤੇ ਮਹਿਮਾਨ ਨੀਤੀ ਦਾ ਮੇਲ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਇੱਕ ਸ਼ਾਖਾ ਬੇਨਤੀ ਨੂੰ ਤਿੰਨੇ ਰਾਹੀਂ ਟਰੇਸ ਕਰੋ।
VPN ਉਪਕਰਣ ਚਲਾਉਂਦਾ Azure VM ਦੋ ਸੁਤੰਤਰ ਫੈਸਲਾ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ। ਪੈਕਟ ਕਿਸ ਸਬਨੈੱਟ ਤੋਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ, ਇਹ Azure ਰੂਟ ਟੇਬਲ ਅਤੇ NIC ਦੀ ਫਾਰਵਰਡਿੰਗ ਸੈਟਿੰਗ ਵਰਤ ਕੇ ਤੈਅ ਕਰਦਾ ਹੈ। ਡੀਕ੍ਰਿਪਟ ਹੋਇਆ ਪੈਕਟ ਅੱਗੇ ਭੇਜਣਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਉਪਕਰਣ ਦਾ ਆਪਣਾ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਤੈਅ ਕਰਦਾ ਹੈ। ਪੂਰੀ ਤਰ੍ਹਾਂ ਉੱਠਿਆ ਟਨਲ ਵੀ ਦੂਜੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹੋ ਜਿਹੀਆਂ ਬਹੁਤੀਆਂ ਤੈਨਾਤੀਆਂ ਉੱਥੇ ਹੀ ਰੁਕ ਜਾਂਦੀਆਂ ਹਨ।
ਇੱਕ ਰਾਹ ਦੇ ਤਿੰਨ ਮਾਲਕ
ਇੱਕ ਸ਼ਾਖਾ ਨੈੱਟਵਰਕ ਲਓ 192.168.50.0/24 ਅਤੇ ਇੱਕ ਵਰਕਲੋਡ ਸਬਨੈੱਟ ਲਓ 10.0.10.0/24, ਉਪਕਰਣ ਇਸ ਪਤੇ ਉੱਤੇ ਹੈ 10.0.0.4 ਇਸਦੇ ਆਪਣੇ ਸਬਨੈੱਟ ਵਿੱਚ। ਇੱਕ ਬੇਨਤੀ ਤਿੰਨ ਵੱਖਰੀਆਂ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਛੂੰਹਦੀ ਹੈ।
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
ਬਹੁਤੀਆਂ ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਹਰ ਕਤਾਰ ਦਾ ਮਾਲਕ ਵੱਖਰੀ ਟੀਮ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਇਹ ਖਰਾਬੀ ਆਮ ਤੌਰ ਉੱਤੇ ਇੱਕ ਦੀ ਥਾਂ ਤਿੰਨ ਟਿਕਟਾਂ ਵਜੋਂ ਆਉਂਦੀ ਹੈ।
ਉਹ ਰੂਟ ਜੋ ਉਪਕਰਣ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ
ਵਰਕਲੋਡ ਸਬਨੈੱਟ ਨਾਲ ਰੂਟ ਟੇਬਲ ਜੋੜੋ ਅਤੇ ਸ਼ਾਖਾ ਪ੍ਰੀਫਿਕਸ ਨੂੰ Virtual appliance ਕਿਸਮ ਦਾ ਅਗਲਾ ਹੌਪ ਦਿਓ 10.0.0.4 ਪਤੇ ਵਜੋਂ। ਉਪਕਰਣ ਦਾ ਪਹੁੰਚਯੋਗ ਨਿੱਜੀ ਪਤਾ ਵਰਤੋ, ਕਦੇ ਵੀ ਨਹੀਂ ਇਸਦਾ ਜਨਤਕ VPN ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ। ਅਗਲਾ ਹੌਪ ਅਜਿਹਾ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਵਰਕਲੋਡ ਸਬਨੈੱਟ ਪਹਿਲਾਂ ਹੀ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਵਰਕਲੋਡ ਦੀ ਬਾਕੀ ਰਾਊਟਿੰਗ ਨੂੰ ਉਵੇਂ ਹੀ ਰਹਿਣ ਦਿਓ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਜਾਣਬੁੱਝ ਕੇ ਡਿਫਾਲਟ ਰੂਟ ਬਦਲਣ ਦਾ ਫੈਸਲਾ ਨਹੀਂ ਕੀਤਾ।
ਉਪਕਰਣ ਨੂੰ ਇਸਦੇ ਆਪਣੇ ਸਬਨੈੱਟ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸ਼ਾਖਾ ਟ੍ਰੈਫਿਕ ਉਪਕਰਣ ਵੱਲ ਭੇਜਣ ਵਾਲਾ ਰੂਟ ਉਪਕਰਣ ਦਾ ਆਪਣਾ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਰਾਹ ਵੀ ਨਹੀਂ ਫੜਦਾ। ਅਜਿਹਾ ਲੂਪ ਸਿਫ਼ਰ ਜਵਾਬਾਂ ਵਾਲੇ ਸਿਹਤਮੰਦ ਟਨਲ ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਰਾਤ 2 ਵਜੇ ਇਸਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਬਹੁਤ ਤਕਲੀਫ਼ੀ ਹੈ।
ਉਹ NIC ਫਲੈਗ ਜੋ ਸਾਰੇ ਭੁੱਲ ਜਾਂਦੇ ਹਨ
Azure ਵਿੱਚ ਹਰ NIC ਲਈ IP ਫਾਰਵਰਡਿੰਗ ਸੈਟਿੰਗ ਹੈ, ਅਤੇ ਇਹ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਬੰਦ ਹੈ। ਇਹ ਇਸ ਲਈ ਹੈ ਕਿ ਫਾਰਵਰਡ ਕਰਨ ਵਾਲਾ NIC ਆਪਣੇ ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਹੋਰ ਨੂੰ ਭੇਜੇ ਪੈਕਟ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਚੁੱਪਚਾਪ ਸੁੱਟਣਾ ਬਾਕੀ ਸਾਰਿਆਂ ਲਈ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਹੈ।
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true ਇਸਨੂੰ ਇੱਕ ਇੰਟਰਫੇਸ ਲਈ ਚਾਲੂ ਕਰਦਾ ਹੈ। Microsoft ਦੀਆਂ NIC ਫਾਰਵਰਡਿੰਗ ਹਦਾਇਤਾਂ ਟ੍ਰੈਫਿਕ ਫਾਰਵਰਡ ਕਰਨ ਵਾਲੇ ਹਰ ਜੁੜੇ NIC ਉੱਤੇ ਇਹ ਸੈਟਿੰਗ ਮੰਗਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਇੱਕ-NIC ਵਾਲੇ ਉਪਕਰਣ ਨੂੰ ਵੀ ਇਹ ਉਸ NIC ਉੱਤੇ ਸੈਟ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।
ਫਲੈਗ ਕੋਈ ਰੂਟ ਨਹੀਂ ਹੈ ਅਤੇ ਕੋਈ ਫਾਇਰਵਾਲ ਨਿਯਮ ਵੀ ਨਹੀਂ। ਇਸਨੂੰ ਚਾਲੂ ਕਰਨ ਨਾਲ ਇਜਾਜ਼ਤ ਮਿਲਦੀ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ।
ਮਹਿਮਾਨ ਡੀਕ੍ਰਿਪਟ ਹੋਏ ਪੈਕਟ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ
ਟਨਲ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਉਪਕਰਣ ਦਾ ਆਪਣਾ ਸਟੈਕ ਅਗਲਾ ਫੈਸਲਾ ਲੈਂਦਾ ਹੈ। Linux ਮਹਿਮਾਨ ਉੱਤੇ IPv4 ਫਾਰਵਰਡਿੰਗ ਰਨਟਾਈਮ ਸੈਟਿੰਗ ਹੈ, ਅਤੇ sysctl -w net.ipv4.ip_forward=1 ਅਗਲੇ ਬੂਟ ਤੱਕ ਰਹਿੰਦੀ ਹੈ। ਇਸਨੂੰ ਬਦਲੇ ਵਿੱਚ ਇੱਕ ਫਾਈਲ ਵਿੱਚ /etc/sysctl.d/ ਸੰਭਾਲੋ। ਵਿਕਰੇਤਾ ਦੇ ਉਪਕਰਣ ਦਾ ਆਪਣਾ ਬਰਾਬਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਵਿਕਰੇਤਾ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਚਿਪਕਾਈਆਂ Linux ਹਦਾਇਤਾਂ ਆਮ ਤੌਰ ਉੱਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਕਰਦੀਆਂ।
ਮਹਿਮਾਨ ਦੀ ਫਾਇਰਵਾਲ ਨੀਤੀ ਦੁਬਾਰਾ ਵੱਖਰੀ ਹੈ, ਅਤੇ ਵਰਕਲੋਡ ਦਾ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਸਮੂਹ ਵੀ। VM ਦੇ ਜਨਤਕ ਪਤੇ ਉੱਤੇ UDP 500 ਅਤੇ 4500 ਦੀ ਇਜਾਜ਼ਤ ਟਨਲ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ; ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਡੀਕ੍ਰਿਪਟ ਹੋਈ ਸ਼ਾਖਾ ਬੇਨਤੀ ਵਰਕਲੋਡ ਪੋਰਟ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇੱਕ ਬੇਨਤੀ ਅਤੇ ਉਸਦਾ ਜਵਾਬ ਟਰੇਸ ਕਰੋ
ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਫਲੋ ਚੁਣੋ ਅਤੇ ਇਸਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਟਰੇਸ ਕਰੋ। ਸ਼ਾਖਾ ਨੂੰ ਇੱਕ ਰੂਟ ਦੀ ਲੋੜ ਹੈ 10.0.10.0/24 ਸਾਈਟ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ, ਉਪਕਰਣ ਨੂੰ ਵਰਕਲੋਡ ਸਬਨੈੱਟ ਤੱਕ ਪਹੁੰਚਾਉਣ ਦੇ ਰਾਹ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਵਰਕਲੋਡ ਸਬਨੈੱਟ ਨੂੰ ਸ਼ਾਖਾ ਵੱਲ ਵਾਪਸੀ ਦੇ ਰੂਟ ਦੀ ਲੋੜ ਹੈ।
ਡਿਜ਼ਾਈਨ ਸ਼ਾਖਾ ਦੇ ਸਰੋਤ ਪਤੇ ਨੂੰ ਰੱਖਦਾ ਹੈ ਜਾਂ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ, ਇਹ ਜਲਦੀ ਤੈਅ ਕਰੋ। NAT ਬਦਲ ਦਿੰਦਾ ਹੈ ਕਿ ਵਰਕਲੋਡ ਕੀ ਦੇਖਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਦੇ ਪਹੁੰਚ ਨਿਯਮਾਂ ਨੂੰ ਉਹੀ ਮਾਡਲ ਬਿਆਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਚੁਣਿਆ ਹੈ, ਅੰਦਾਜ਼ੇ ਵਾਲਾ ਗੇਟਵੇ ਪਤਾ ਨਹੀਂ।
ਸਫਲ ਹੈਂਡਸ਼ੇਕ ਉਸ ਜ਼ੰਜੀਰ ਦੀ ਇੱਕ ਕੜੀ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਜਵਾਬ ਉਸੇ ਉਪਕਰਣ ਰਾਹੀਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਅਤੇ ਵਰਕਲੋਡ ਦੀ ਆਪਣੀ ਨੀਤੀ ਇਸਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਤਦ ਰਾਹ ਪੂਰਾ ਹੁੰਦਾ ਹੈ।