Windows ਦਾ VPN 255.255.255.255 ਦਿਖਾ ਰਿਹਾ ਹੈ: ਕੀ ਮਾਸਕ ਗਲਤ ਹੈ?
ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ ਟਨਲ ਵਿੱਚ ਹੋਸਟ ਮਾਸਕ ਆਮ ਹੈ। ਇੰਟਰਫੇਸ ਦਾ ਮਾਡਲ ਪੁਸ਼ਟੀ ਕਰੋ, ਫੇਲ ਹੋ ਰਹੇ ਹੋਸਟ ਦਾ ਰੂਟ ਪੜ੍ਹੋ ਅਤੇ DNS ਨੂੰ ਸੇਵਾ ਪਹੁੰਚ ਤੋਂ ਵੱਖ ਕਰੋ।
ਟਨਲ ਜੁੜਦੀ ਹੈ, ਤੁਸੀਂ ਅਡੈਪਟਰ ਦੇ ਵੇਰਵੇ ਖੋਲ੍ਹਦੇ ਹੋ ਅਤੇ ਮਾਸਕ 255.255.255.255 ਦਿਖਾਉਂਦਾ ਹੈ। ਦਫ਼ਤਰ ਦੇ LAN ਦੇ 255.255.255.0 ਨਾਲ ਤੁਲਨਾ ਕਰਨ ’ਤੇ ਇਹ ਟੁੱਟਿਆ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਗਲਤੀ ਆਮ ਤੌਰ ’ਤੇ ਇੱਥੋਂ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ ਲਿੰਕ ’ਤੇ ਹੋਸਟ ਮਾਸਕ ਸਥਾਨਕ ਸਿਰੇ ਦਾ ਸਹੀ ਵਰਣਨ ਹੈ, ਅਤੇ ਦੂਰ ਦੇ ਨੈੱਟਵਰਕ ਜੁੜੇ ਸਬਨੈੱਟ ਦੀ ਥਾਂ ਰੂਟ ਵਜੋਂ ਆਉਂਦੇ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੀ ਪ੍ਰਕਿਰਿਆ ਦੋਨੋਂ ਸਵਾਲ ਵੱਖ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਸਿਰਫ਼ ਦਿਖਾਇਆ ਮੁੱਲ ਠੀਕ ਕਰਨ ਲਈ ਚੱਲ ਰਿਹਾ DHCP ਸਕੋਪ ਦੁਬਾਰਾ ਨਾ ਬਣਾਓ।
ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ ਲਿੰਕ Ethernet ਭਾਗ ਨਹੀਂ
Ethernet ਇੰਟਰਫੇਸ ਨੂੰ ਸਬਨੈੱਟ ਮਾਸਕ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਉਸ ਰੇਂਜ ਦਾ ਹਰ ਪਤਾ ਉਸੇ ਕੇਬਲ ’ਤੇ ਸੰਭਾਵੀ ਤੌਰ ’ਤੇ ਪਹੁੰਚਯੋਗ ਹੈ। PPP ਸ਼ੈਲੀ ਦੀ ਟਨਲ ਦੇ ਦੂਜੇ ਸਿਰੇ ’ਤੇ ਠੀਕ ਇੱਕ ਸਾਥੀ ਹੁੰਦਾ ਹੈ। ਇੱਥੇ ਕੋਈ ਬ੍ਰਾਡਕਾਸਟ ਡੋਮੇਨ ਨਹੀਂ, ARP ਨਹੀਂ ਅਤੇ ਸਥਾਨਕ ਪਤੇ ਦੇ ਰੇਂਜ ਦਾ ਵਰਣਨ ਕਰਨ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ।
ਉਸ ਮਾਡਲ ਲਈ ਪਤਾ ਗੱਲਬਾਤ RFC 1332 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਹੈ, ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਦੋਵੇਂ ਸਿਰੇ ਆਪਣੇ ਪਤਿਆਂ ’ਤੇ ਕਿਵੇਂ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ। ਜੋ ਇਹ ਨਹੀਂ ਕਰਦੀ ਉਹ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੂੰ ਦਫ਼ਤਰ ਦਾ LAN ਸਿੱਧਾ ਜੁੜਿਆ ਨੈੱਟਵਰਕ ਵਜੋਂ ਦੇਵੇ। ਕਲਾਇੰਟ ਦਫ਼ਤਰ ਕਿੱਥੇ ਹੈ ਇਹ ਲਿੰਕ ਰਾਹੀਂ ਰੂਟ ਇੰਸਟਾਲ ਕਰਕੇ ਸਿੱਖਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਰੂਟ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚ ਤੈਅ ਕਰਦੇ ਹਨ।
ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਤੁਹਾਨੂੰ ਦਿਸਣ ਵਾਲਾ ਹਰ ਮਾਸਕ ਸਹੀ ਹੈ। ਗਲਤ ਕਨਫਿਗਰ ਕੀਤਾ ਕਲਾਇੰਟ ਵੀ ਅਜੀਬ ਐਡਰੈਸਿੰਗ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਗੱਲ ਸੰਕਰੀ ਹੈ: ਇਸ ਕਿਸਮ ਦੇ ਅਡੈਪਟਰ ’ਤੇ ਹੋਸਟ ਮਾਸਕ ਆਮ ਹੈ, ਇਸ ਲਈ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇਹ ਖਰਾਬੀ ਦਾ ਸਬੂਤ ਨਹੀਂ।
ਪੜਾਅ 1: ਇੰਟਰਫੇਸ ਮਾਡਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
ਇਹ ਕੀ ਕਹਿੰਦਾ ਹੈ ਇਸਦਾ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੇਖੋ ਕਿ ਅਡੈਪਟਰ ਕੀ ਹੈ। ਵਰਣਨ ਦੀ ਲੜੀ ਡਰਾਈਵਰ ਦੀ ਪਛਾਣ ਕਰਦੀ ਹੈ, ਅਤੇ ਦਿੱਤੇ ਪਤੇ ’ਤੇ ਪ੍ਰੀਫਿਕਸ ਦੀ ਲੰਬਾਈ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕਿਸ ਗੱਲ ’ਤੇ ਸਹਿਮਤ ਹੋਇਆ:
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtuਤੀਜਾ ਕਮਾਂਡ ਹੀ ਉਹ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਬਹਿਸਾਂ ਖਤਮ ਕਰਦਾ ਹੈ। ਘੱਟ ਵੱਧ ਤੋਂ ਵੱਧ ਟ੍ਰਾਂਸਮਿਸ਼ਨ ਇਕਾਈ ਐਨਕੈਪਸੁਲੇਟਿਡ ਲਿੰਕ ਦੀ ਖਾਸੀਅਤ ਹੈ, ਜਦਕਿ Ethernet ਵਰਗਾ ਮੁੱਲ ਵੱਖਰੇ ਵਰਚੁਅਲ ਅਡੈਪਟਰ ਮਾਡਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਜੇ ਵਰਣਨ ਵਿੱਚ PPP ਜਾਂ RAS ਡਰਾਈਵਰ ਦਾ ਨਾਮ ਹੈ ਅਤੇ ਪ੍ਰੀਫਿਕਸ 32 ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉੱਪਰ ਦੱਸਿਆ ਡਿਜ਼ਾਈਨ ਠੀਕ ਦੇਖ ਰਹੇ ਹੋ ਅਤੇ ਮਾਸਕ ਦੀ ਚਿੰਤਾ ਛੱਡ ਸਕਦੇ ਹੋ।
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
ਪੜਾਅ 2: ਫੇਲ ਮੰਜ਼ਿਲ ਦਾ ਰੂਟ ਪੜ੍ਹੋ
ਪਹੁੰਚ ਹਰ ਮੰਜ਼ਿਲ ਲਈ ਤੈਅ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਜੁੜਿਆ ਇੰਟਰਫੇਸ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਰੂਟਿੰਗ ਟੇਬਲ ਨੂੰ ਸਿੱਧਾ ਉਹ ਪਤਾ ਪੁੱਛੋ ਜਿੱਥੇ ਵਰਤੋਂਕਾਰ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute ਸਿੱਧਾ ਜਵਾਬ ਹੈ: ਇਹ ਉਹ ਇੰਟਰਫੇਸ ਅਤੇ ਸਰੋਤ ਪਤਾ ਦੱਸਦਾ ਹੈ ਜੋ ਸਿਸਟਮ ਉਸ ਮੰਜ਼ਿਲ ਲਈ ਵਰਤੇਗਾ। ਜੇ ਇਹ ਟਨਲ ਵਾਪਸ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਸ ਹੋਸਟ ਵੱਲ ਟ੍ਰੈਫਿਕ ਟਨਲ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮਾਸਕ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ।
ਜੇ ਇਹ ਭੌਤਿਕ ਅਡੈਪਟਰ ਵਾਪਸ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਦੋ ਸੰਭਾਵੀ ਰੂਟ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਮੈਟ੍ਰਿਕ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਵਧੇਰੇ ਖਾਸ ਸਥਾਨਕ ਰੂਟ, ਦੂਜੇ ਕਲਾਇੰਟ ਤੋਂ ਬਚੀ ਐਂਟਰੀ ਜਾਂ ਭੌਤਿਕ ਰਾਹ ’ਤੇ ਘੱਟ ਮੈਟ੍ਰਿਕ ਸਾਰੇ ਚੌੜੇ ਟਨਲ ਰੂਟ ਨੂੰ ਹਰਾਉਂਦੇ ਹਨ। ਦਿਸਣ ਵਾਲਾ ਨਤੀਜਾ ਅਜਿਹਾ ਸਰੋਤ ਹੈ ਜਿਸ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ, ਜਦਕਿ ਬਾਕੀ ਸਭ ਚੱਲ ਰਿਹਾ ਹੋਵੇ। ਲੰਬੇ ਪ੍ਰੀਫਿਕਸ ਹਮੇਸ਼ਾ ਜਿੱਤਦੇ ਹਨ, ਇਸ ਲਈ ਜਿੱਤਣ ਵਾਲਾ ਅਕਸਰ ਉਹ ਹੋਸਟ ਰੂਟ ਹੁੰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਨੇ ਮਹੀਨੇ ਪਹਿਲਾਂ ਜੋੜਿਆ ਅਤੇ ਭੁੱਲ ਗਿਆ।
ਇੱਥੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵੀ ਜਾਂਚੋ। ਸਰਵਰ ਵੱਲ ਰੂਟ ਲਾਜ਼ਮੀ ਹੈ ਪਰ ਕਾਫੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਜਵਾਬ ਵੀ ਟਨਲ ਰਾਹੀਂ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਅੰਦਰੂਨੀ ਹੋਸਟ ਚੱਲੇ ਅਤੇ ਦੂਜਾ ਨਾ ਚੱਲੇ, ਫਰਕ ਆਮ ਤੌਰ ’ਤੇ ਇਸੇ ਟੇਬਲ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਅਡੈਪਟਰ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ।
ਪੜਾਅ 3: ਨਾਮ ਹੱਲ ਨੂੰ ਸੇਵਾ ਪਹੁੰਚ ਤੋਂ ਵੱਖ ਕਰੋ
ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਸ਼ੇਅਰ ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਦੀ, ਉਹ ਦੋ ਬਹੁਤ ਵੱਖਰੇ ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ’ਤੇ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ। ਨਾਮ ਹੱਲ ਕਰੋ, ਫਿਰ ਪਤੇ ਤੱਕ ਪਹੁੰਚੋ। ਜੇ ਪਹਿਲਾ ਫੇਲ ਹੋਵੇ ਅਤੇ ਦੂਜਾ ਚੱਲੇ, ਤਾਂ ਟਨਲ ਠੀਕ ਹੈ ਅਤੇ ਹੱਲ ਕਰਨ ਵਾਲਾ ਨਹੀਂ:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445ਸਫਲ ਪਤਾ ਟੈਸਟ ਦੇ ਨਾਲ ਫੇਲ ਨਾਮ ਟੈਸਟ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਵਿੱਚ ਸਥਾਨਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਕਮਾਂਡ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਟਨਲ ਇੰਟਰਫੇਸ ਨੂੰ ਸਰਵਰ ਮਿਲਿਆ ਵੀ ਜਾਂ ਨਹੀਂ। ਕਈ ਕਲਾਇੰਟ DNS ਨੂੰ ਟਨਲ ਕਨਫਿਗਰੇਸ਼ਨ ਦਾ ਹਿੱਸਾ ਬਣਾ ਕੇ ਧੱਕਦੇ ਹਨ, ਅਤੇ ਉਹ ਪ੍ਰੋਫਾਈਲ ਜੋ ਉਨ੍ਹਾਂ ਧੱਕੇ ਗਏ ਵਿਕਲਪਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੇ, ਮਸ਼ੀਨ ਨੂੰ ਅਜਿਹੇ ਹੱਲਕਰਤਾ ਨਾਲ ਛੱਡ ਦੇਵੇਗੀ ਜੋ ਨਿੱਜੀ ਜ਼ੋਨ ਨਹੀਂ ਦੇਖਦਾ।
ਚੱਲ ਰਹੇ ਪਤੇ ਨੂੰ ਪੱਕਾ ਸੁਧਾਰ ਨਾ ਮੰਨੋ। ਪਤੇ ਰਾਹੀਂ ਜੁੜਨਾ ਨਾਮ ਹੱਲ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹ ਸਰਵਰ ਪਛਾਣ ਜਾਂਚ ਕਮਜ਼ੋਰ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਨਹੀਂ ਤਾਂ ਕਰਦੀ। ਇਹ ਆਰਜ਼ੀ ਹੱਲ ਦੇ ਭੇਸ ਵਿੱਚ ਸੁਰੱਖਿਆ ਪਤਨ ਹੈ। ਇਸ ਨੂੰ ਖਰਾਬੀ ਲੱਭਣ ਲਈ ਵਰਤੋ, ਫਿਰ ਹੱਲ ਠੀਕ ਕਰੋ।
ਵਾਪਸੀ: ਦਿਖਾਏ ਮੁੱਲ ਕਾਰਨ DHCP ਦੁਬਾਰਾ ਨਾ ਬਣਾਓ
ਜੇ ਤੁਸੀਂ ਪਤਾ ਸੇਵਾ ਬਦਲਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਦੇਖੋ ਕਿ ਤੁਸੀਂ ਬਦਲਿਆ ਕੁਝ ਭਾਰ ਚੁੱਕਣ ਵਾਲਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਕੋਪ ਦੁਬਾਰਾ ਬਣਾਉਣਾ, ਲੀਜ਼ ਦੁਬਾਰਾ ਜਾਰੀ ਕਰਨਾ ਜਾਂ ਪੂਲ ਹਿਲਾਉਣਾ ਅਜਿਹੀ ਹਾਲਤ ਬਦਲਦਾ ਹੈ ਜਿਸ ’ਤੇ ਹੋਰ ਕਲਾਇੰਟ ਨਿਰਭਰ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ ਅਡੈਪਟਰ ’ਤੇ ਹੋਸਟ ਮਾਸਕ ਨਾਲ ਜਾਇਜ਼ ਨਹੀਂ ਠਹਿਰਦਾ।
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445ਇਹ ਤਿੰਨੇ ਕਿਸੇ ਵੀ ਨਿਸ਼ਾਨਾਬੱਧ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਚਲਾਓ ਅਤੇ ਪਿਛਲੇ ਰਨ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਲਾਹੇਵੰਦ ਨਤੀਜਾ ਸਰੋਤ ਤੱਕ ਦਸਤਾਵੇਜ਼ੀ ਰਾਹ ਹੈ, ਨਾ ਕਿ ਅਜਿਹਾ ਅਡੈਪਟਰ ਜਿਸ ਦਾ ਮਾਸਕ ਦਫ਼ਤਰ ਦੇ LAN ਵਰਗਾ ਦਿਸੇ।
ਫਿਰ ਲਿਖੋ ਕਿ ਮਾਸਕ ਦਾ ਅਸਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਸੀ, ਕਿਉਂਕਿ ਅਗਲਾ ਵਿਅਕਤੀ ਉਹੀ ਸੰਵਾਦ ਖੋਲ੍ਹੇਗਾ ਅਤੇ ਉਹੀ ਗਲਤ ਸਿੱਟਾ ਕੱਢੇਗਾ। ਪ੍ਰੋਫਾਈਲ ਨੋਟਾਂ ਵਿੱਚ ਇੱਕ ਵਾਕ, ਕਿ ਟਨਲ ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ ਹੈ ਅਤੇ ਦੂਰ ਦੇ ਸਬਨੈੱਟ ਰੂਟ ਵਜੋਂ ਆਉਂਦੇ ਹਨ, ਅਗਲੀ ਵਾਰ ਪੂਰੀ ਜਾਂਚ ਬਚਾ ਦਿੰਦਾ ਹੈ।