ਜਦੋਂ resolver ਪੀਅਰ ਕੀਤੇ VNet ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਤਾਂ Azure P2S DNS ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ
ਇੱਕ ਕਲਾਇੰਟ ਆਪਣੇ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਪੀਅਰ ਕੀਤੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਨਾਵਾਂ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਦੋਵੇਂ ਧਿਰਾਂ ਮੰਨਣ ਤੱਕ ਪੀਅਰਿੰਗ ਗੇਟਵੇ ਟਰਾਂਜ਼ਿਟ ਨਹੀਂ ਹੈ।
VM ਨੂੰ ਪਿੰਗ ਕਰੋ ਅਤੇ ਉਹ ਜਵਾਬ ਦਿੰਦਾ ਹੈ; ਉਸਦਾ ਨਾਮ ਪੁੱਛੋ ਅਤੇ ਕਲਾਇੰਟ ਕਹਿੰਦਾ ਹੈ ਕਿ ਹੋਸਟ ਅਣਜਾਣ ਹੈ। ਜਦੋਂ resolver VPN ਗੇਟਵੇ ਵਾਲੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਨਹੀਂ ਸਗੋਂ ਪੀਅਰ ਕੀਤੇ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਵਿੱਚ ਬੈਠਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਨਤੀਜਿਆਂ ਦੀ ਇਹ ਜੋੜੀ ਉਮੀਦ ਯੋਗ ਹੈ, ਅਤੇ resolver ਦੀ ਕੋਈ ਵੀ ਜਾਂਚ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲਦੀ। ਜੋ ਗੁੰਮ ਹੈ ਉਹ ਰਾਊਟਿੰਗ ਸਮਝੌਤਾ ਹੈ ਜਿਸਨੂੰ ਪੀਅਰਿੰਗ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਰੋਕੀ ਰੱਖਦੀ ਹੈ। ਦੋ ਟੋਪੋਲੋਜੀਆਂ ਕਾਗਜ਼ ਉੱਤੇ ਲਗਭਗ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ, ਅਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਤੇ ਟੁੱਟੇ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਸਹੀ ਦਿਸ਼ਾ ਵਿੱਚ ਰੱਖੇ ਪੀਅਰਿੰਗ ਸਵਿੱਚਾਂ ਦੀ ਜੋੜੀ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਲੈਪਟਾਪ VNet2 ਵਿੱਚ ਗੇਟਵੇ ਵੱਲ ਟਨਲ ਕਰ ਰਿਹਾ ਹੈ, ਜਦੋਂ ਕਿ DNS ਸੇਵਾ ਦੇਣ ਵਾਲਾ ਡੋਮੇਨ ਕੰਟਰੋਲਰ VNet1 ਵਿੱਚ ਬੈਠਾ ਹੈ।
ਦੋ ਟੋਪੋਲੋਜੀਆਂ, ਇੱਕ ਫ਼ਰਕ
resolver ਨੂੰ ਗੇਟਵੇ ਦੇ ਆਪਣੇ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ ਰੱਖੋ ਅਤੇ ਟਨਲ ਉੱਪਰ ਆਉਣ ਦੇ ਪਲ ਹੀ ਨਾਮ ਹੱਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਸ ਖੋਜ ਵਿੱਚ ਕੋਈ ਪੀਅਰਿੰਗ ਸੈਟਿੰਗ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੀ।
ਉਸੇ resolver ਨੂੰ ਪੀਅਰਿੰਗ ਦੇ ਪਾਰ ਲੈ ਜਾਓ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਅਜੇ ਵੀ VM ਤੋਂ ਜਵਾਬ ਮਿਲਦਾ ਹੈ ਜਦੋਂ ਕਿ ਨਾਮ ਅਣਜਾਣ ਰਹਿੰਦਾ ਹੈ। ਸਰਟੀਫਿਕੇਟ, ਟਨਲ ਅਤੇ ਕਲਾਇੰਟ ਬਦਲੇ ਨਹੀਂ। ਸਿਰਫ਼ ਇੱਕ ਚੀਜ਼ ਹਿੱਲੀ ਹੈ ਕਿ resolver ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ। ਪੀਅਰਿੰਗ ਨੇ ਉਸਨੂੰ ਉਸ ਪਤੇ ਤੱਕ ਰਾਹ ਦਿੱਤਾ, ਗੇਟਵੇ ਨੂੰ ਉੱਥੇ ਟਰੈਫ਼ਿਕ ਲਿਜਾਣ ਦਾ ਅਧਿਕਾਰ ਨਹੀਂ।
ਧਿਰ A: ਗੇਟਵੇ ਮਾਲਕ ਉੱਤੇ ਗੇਟਵੇ ਟਰਾਂਜ਼ਿਟ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ
ਪੀਅਰਿੰਗ ਦੋ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਜੋੜਦੀ ਹੈ, ਪਰ ਇਹ ਜੋੜ ਗੇਟਵੇ ਰਾਹੀਂ ਆਉਣ ਵਾਲੇ ਟਰੈਫ਼ਿਕ ਲਈ ਟਰਾਂਜ਼ਿਟਿਵ ਨਹੀਂ ਹੈ, ਅਤੇ ਪੁਆਇੰਟ-ਟੂ-ਸਾਈਟ ਬੇਨਤੀ ਬਿਲਕੁਲ ਇਸੇ ਤਰ੍ਹਾਂ ਆਉਂਦੀ ਹੈ। ਇਸ ਲਈ VNet2 ਵਿੱਚਲੇ ਗੇਟਵੇ ਕੋਲ ਡਿਜ਼ਾਈਨ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੱਕ ਖੋਜ ਨੂੰ VNet1 ਨੂੰ ਸੌਂਪਣ ਦਾ ਅਧਿਕਾਰ ਨਹੀਂ। ਇਜਾਜ਼ਤ ਗੇਟਵੇ ਵਾਲੇ ਨੈੱਟਵਰਕ ਦੀ ਮਾਲਕੀ ਵਾਲੀ ਪੀਅਰਿੰਗ ਉੱਤੇ ਇੱਕ ਸਵਿੱਚ ਹੈ।
VNet2 ਤੋਂ VNet1 ਵੱਲ ਪੀਅਰਿੰਗ ਉੱਤੇ Allow gateway transit ਸੈੱਟ ਕਰੋ। ਇਹ ਗੁਣ ਗੇਟਵੇ ਸਰੋਤ ਦਾ ਨਹੀਂ, ਪੀਅਰਿੰਗ ਆਬਜੈਕਟ ਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਪੀਅਰਿੰਗ ਬਲੇਡ ਵਿੱਚ ਪੜ੍ਹੋ ਅਤੇ ਬਦਲੋ। ਪੂਰੀ ਧਿਰ A ਇਹੀ ਹੈ।
ਧਿਰ B: ਸਾਥੀ ਉੱਤੇ ਦੂਰਲੇ ਗੇਟਵੇ ਵਰਤੋ
ਦੂਜਾ ਅੱਧਾ ਸ਼ੀਸ਼ੇ ਦਾ ਪ੍ਰਤੀਬਿੰਬ ਹੈ: VNet1 ਤੋਂ VNet2 ਵੱਲ ਵਾਪਸ ਪੀਅਰਿੰਗ ਉੱਤੇ Use remote gateways ਸਮਰੱਥ ਕਰੋ। ਉਹੀ ਝੰਡਾ ਦੋਵਾਂ ਸਿਰਿਆਂ ਉੱਤੇ, ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਉੱਤੇ ਚਾਲੂ ਕਰਨ ਨਾਲ ਅੱਧਾ ਬਣਿਆ ਰਾਹ ਅਤੇ ਮੂਲ ਲੱਛਣ ਅਛੂਤੇ ਰਹਿੰਦੇ ਹਨ। ਸਿਰਫ਼ VPN ਗੇਟਵੇ ਵਾਲਾ ਨੈੱਟਵਰਕ ਟਰਾਂਜ਼ਿਟ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਾਥੀ ਉਹ ਧਿਰ ਹੈ ਜੋ ਇਸਨੂੰ ਵਰਤਦੀ ਹੈ।
ਆਖ਼ਰੀ ਵਾਰ ਖੋਲ੍ਹੀ ਪੋਰਟਲ ਬਲੇਡ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਦੋਵਾਂ ਨੈੱਟਵਰਕਾਂ ਉੱਤੇ ਦੋਵੇਂ ਗੁਣ ਪੜ੍ਹੋ।
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
| Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
| Format-List Name,AllowGatewayTransit,UseRemoteGatewaysਜੋੜੀ ਨੂੰ ਨਾਲ-ਨਾਲ ਵੇਖਣਾ ਉਲਟੀ ਸੈਟਿੰਗ ਫੜਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ। ਗੇਟਵੇ ਧਿਰ ਉੱਤੇ AllowGatewayTransit false ਦੱਸਣ ਵਾਲੀ ਪੀਅਰਿੰਗ ਪੈਕਟ ਕੈਪਚਰ ਤੋਂ ਬਿਨਾਂ ਪੂਰੀ ਅਸਫਲਤਾ ਦੱਸ ਦਿੰਦੀ ਹੈ।
ਕਲਾਇੰਟ ਨੂੰ ਅਜੇ ਵੀ ਕੀ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ
ਰਾਊਟਿੰਗ ਜ਼ਰੂਰੀ ਹੈ ਅਤੇ ਕਾਫ਼ੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਪੁਆਇੰਟ-ਟੂ-ਸਾਈਟ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਕਲਾਇੰਟ ਨੂੰ ਅਜਿਹਾ DNS ਪਤਾ ਵੀ ਦੇਣਾ ਪੈਂਦਾ ਹੈ ਜੋ ਟਰਾਂਜ਼ਿਟ ਕੰਮ ਕਰਨ ਤੋਂ ਬਾਅਦ ਜਵਾਬ ਦੇਵੇ। ਪਲੇਟਫ਼ਾਰਮ resolver ਉਹ ਪਤਾ ਨਹੀਂ ਹੈ: ਇਹ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਨਾਲ ਜੁੜੇ Azure Private DNS ਜ਼ੋਨਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਪਰ ਤੁਹਾਡੇ ਆਪਣੇ ਡਾਇਰੈਕਟਰੀ ਸਰਵਰਾਂ ਉੱਤੇ ਹੋਸਟ ਕੀਤੇ ਜ਼ੋਨ ਲਈ ਕੁਝ ਨਹੀਂ, ਅਤੇ ਇਹ ਤੈਨਾਤੀ ਉਹੀ ਵਰਤਦੀ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ ਉੱਥੇ ਇਸ਼ਾਰਾ ਕਰੋ ਅਤੇ ਜਨਤਕ ਨਾਮ ਖੁਸ਼ੀ ਨਾਲ ਹੱਲ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਕਿ ਅੰਦਰੂਨੀ ਹੋਸਟ ਅਣਜਾਣ ਰਹਿੰਦਾ ਹੈ।
ਹੋਰ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਜੁੜੇ ਲੈਪਟਾਪ ਤੋਂ resolver ਨੂੰ ਪੁੱਛੋ।
nslookup dc01.corp.example 10.1.0.4ਸਮਾਂ ਸਮਾਪਤ ਹੋਣਾ ਕਹਿੰਦਾ ਹੈ ਕਿ ਰਾਹ ਅਜੇ ਵੀ ਗੁੰਮ ਹੈ। ਅਧਿਕਾਰਤ ਜਵਾਬ ਸਮੱਸਿਆ ਨੂੰ ਕਲਾਇੰਟ ਵੱਲ ਵਾਪਸ ਧੱਕਦਾ ਹੈ, ਆਮ ਤੌਰ ਉੱਤੇ ਅਜਿਹਾ ਪਿਛੇਤਰ ਜੋ ਕਦੇ ਨਹੀਂ ਜੋੜਿਆ ਜਾਂਦਾ, ਇਸ ਲਈ ਛੋਟੇ ਨਾਮ ਇੱਕ ਜਨਤਕ resolver ਵੱਲ ਜਾਂਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਨੂੰ ਖੁਸ਼ੀ ਨਾਲ ਫੇਲ੍ਹ ਕਰ ਦਿੰਦਾ ਹੈ।
ਸਾਈਟ-ਟੂ-ਸਾਈਟ ਧਿਰ ਉੱਤੇ ਉਹੀ ਸਮਝੌਤਾ ਤੁਲਨਾ ਕਰੋ
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਖ਼ਾਸ ਤੌਰ ਉੱਤੇ ਲੈਪਟਾਪਾਂ ਦਾ ਨਹੀਂ। ਕਲਾਇੰਟ ਦੀ ਥਾਂ ਸਾਈਟ-ਟੂ-ਸਾਈਟ ਦੀ ਸ਼ਾਖਾ ਰੱਖੋ ਅਤੇ ਦੋ-ਧਿਰੀ ਸ਼ਰਤ ਵਾਪਸ ਆ ਜਾਂਦੀ ਹੈ: ਸ਼ਾਖਾ ਸਿੱਧੀ ਗੇਟਵੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਦੋ ਨੈੱਟਵਰਕ ਦੂਰ ਦੀ ਸੇਵਾ ਅਜੇ ਵੀ ਪੀਅਰਿੰਗ ਪਿੱਛੇ ਹੈ।
ਟਰਾਂਜ਼ਿਟ ਦੋਵਾਂ ਪੀਅਰਿੰਗਾਂ ਉੱਤੇ ਦੇਣਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਜੋ ਸਵਿੱਚ ਇਹ ਦਿੰਦਾ ਹੈ ਉਹ ਕਲਾਇੰਟ ਕਿਸਮ ਉੱਤੇ ਨਹੀਂ, ਪੀਅਰਿੰਗ ਉੱਤੇ ਰਹਿੰਦਾ ਹੈ।
ਗੇਟਵੇ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ
Windows ਹਰ ਅਡੈਪਟਰ ਲਈ resolver ਸੂਚੀ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਗੇਟਵੇ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਮਿਲਿਆ।
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdnsਨਕਾਰਾਤਮਕ ਜਵਾਬ ਕੈਸ਼ ਵਿੱਚ ਰਾਊਟਿੰਗ ਸੁਧਾਰ ਨਾਲੋਂ ਵੱਧ ਸਮਾਂ ਟਿਕਦਾ ਹੈ, ਅਤੇ ਪੁਰਾਣੀ ਪਿਛੇਤਰ ਸੂਚੀ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਅਜਿਹੀ ਥਾਂ ਭੇਜਦੀ ਰਹਿੰਦੀ ਹੈ ਜਿੱਥੇ ਜ਼ੋਨ ਕਦੇ ਹੋਸਟ ਨਹੀਂ ਹੋਇਆ। ਫਲੈਸ਼ ਕਰੋ, ਦੁਬਾਰਾ ਪੁੱਛੋ, ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਕਿਹੜਾ ਸਰਵਰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਰਾਹ ਟਿਕੇਗਾ ਜਾਂ ਨਹੀਂ ਇਹ ਦੋ ਛੋਟੀਆਂ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ: ਪਤਾ ਥਾਵਾਂ ਇੱਕ ਦੂਜੇ ਉੱਤੇ ਨਹੀਂ ਚੜ੍ਹ ਸਕਦੀਆਂ, ਅਤੇ resolver ਦੇ ਸਬਨੈੱਟ ਉੱਤੇ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਸਮੂਹ ਨੂੰ ਕਲਾਇੰਟ ਪੂਲ ਸਵੀਕਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਜੋ ਸਿਰਫ਼ ਇੱਕ ਹੋਰ ਸਰੋਤ ਰੇਂਜ ਹੈ। VM ਧਿਰ ਤੋਂ ਪ੍ਰਭਾਵੀ-ਰਾਊਟ ਜਾਂਚ ਅਤੇ ਕਲਾਇੰਟ ਤੋਂ ਇੱਕ ਸਿੱਧੀ ਪੁੱਛਗਿੱਛ ਨਾਲ ਇਹ ਸਾਬਤ ਕਰੋ, ਤਾਂ ਜੋ ਜ਼ੋਨ ਸਮੱਸਿਆ, ਪਿਛੇਤਰ ਸਮੱਸਿਆ ਜਾਂ ਫਿਲਟਰ ਕਦੇ ਵੀ ਗੁੰਮ ਟਰਾਂਜ਼ਿਟ ਨਾ ਸਮਝਿਆ ਜਾਵੇ।