VPN ਹਾਲਤ ਨਾਲ ਬੱਧਾ ਫਾਇਰਵਾਲ ਗੇਟ ਕਿਉਂ ਸਿਰਫ਼ ping ਦਾ ਨਿਯਮ ਨਹੀਂ ਹੈ

ਇੱਕ ਫਾਇਰਵਾਲ ਨਿਯਮ ਦੀ ਕਲਪਨਾ ਕਰੋ ਜੋ ਨਾਮਿਤ VPN ਪ੍ਰੋਫ਼ਾਈਲ ਜੁੜੇ ਹੋਣ ’ਤੇ ਸਰਵਰ ਦੇ ਜਨਤਕ ਪਤੇ ਲਈ ICMP echo ਚਾਲੂ ਕਰਦਾ ਹੈ। ਇਹ «ਸਿਰਫ਼ ਸੁਰੰਗ ਰਾਹੀਂ ping» ਵਾਂਗ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਪੜ੍ਹਤ ਉਸ ਤਰੀਕੇ ਨਾਲ ਗ਼ਲਤ ਹੈ ਜੋ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ। ਨਿਯਮ ਇਹ ਸੀਮਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕੌਣ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ; ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਜਨਤਕ ਇੰਟਰਫ਼ੇਸ ਕਿਸ ਨੂੰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕੋਈ ਹੋਰ ਕਨੈਕਸ਼ਨ ਸੰਜੋਗ ਨਾਲ ਚਾਲੂ ਹੋਵੇ। ਇਹ ਦੋ ਵੱਖਰੀਆਂ ਨੀਤੀਆਂ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਚੁੱਪਚਾਪ ਖ਼ਤਰਾ ਵਧਾਉਂਦੀ ਹੈ।

ਉਹ ਨਿਯਮ ਜੋ ਤੁਸੀਂ ਲਿਖਿਆ ਸਮਝਦੇ ਹੋ

ਇਛਿਤ ਲੋੜ ਆਮ ਤੌਰ ’ਤੇ ਸੰਖੇਪ ਹੁੰਦੀ ਹੈ: ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ, ਜਾਂ VPN ’ਤੇ ਇਕੱਲਾ ਪ੍ਰਬੰਧਕ, ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ ਕਿ ਸਰਵਰ ਜੀਵਤ ਹੈ। ਵਾਕ ਵਜੋਂ ਲਿਖਣ ’ਤੇ ਇਹ ਸੁਰੰਗ ’ਤੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਵਾਂਗ ਸੁਣਾਉਂਦਾ ਹੈ। ਫਾਇਰਵਾਲ ਆਬਜੈਕਟ ਵਜੋਂ ਲਿਖਣ ’ਤੇ ਇਹ ਜਨਤਕ ਪ੍ਰੋਫ਼ਾਈਲ ’ਤੇ ਸ਼ਰਤ ਬਣ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ echo ਬੇਨਤੀ ਉੱਥੇ ਹੀ ਆਉਂਦੀ ਹੈ।

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

ਇਸ ਵਿਚਾਰ ਦਾ ਪ੍ਰਚਾਰ ਕਰਨ ਵਾਲੇ ਆਮ ਤੌਰ ’ਤੇ ਲੋੜੀਂਦੇ ਅਸਰ ਬਾਰੇ ਝੂਠ ਨਹੀਂ ਬੋਲਦੇ। ਉਨ੍ਹਾਂ ਨੂੰ ਅਜਿਹੀ ਜਾਂਚ ਚਾਹੀਦੀ ਸੀ ਜੋ ਸਿਰਫ਼ ਤਦ ਜਵਾਬ ਦੇਵੇ ਜਦੋਂ ਲਿੰਕ ਤੰਦਰੁਸਤ ਹੋਵੇ, ਅਤੇ ਲਿੰਕ ਦੀ ਤੰਦਰੁਸਤੀ VPN ਰਾਹੀਂ ਦੇਖਣਾ ਸਭ ਤੋਂ ਸੌਖਾ ਸੀ। ਗ਼ਲਤੀ ਇਹ ਹੈ ਕਿ ਉਪਲਬਧਤਾ ਦੇ ਸੰਕੇਤ ਨੂੰ ਪਹੁੰਚ ਦਾ ਫ਼ੈਸਲਾ ਮੰਨ ਲਿਆ ਜਾਵੇ, ਫਿਰ ਉਸ ਨੂੰ ਸਵੈਚਾਲਿਤ ਕਰ ਦਿੱਤਾ ਜਾਵੇ।

ਗੇਟ ਅਸਲ ਵਿੱਚ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ

ਇਹ ਰਚਨਾ ਦੋ ਸੁਤੰਤਰ ਚੀਜ਼ਾਂ ਨੂੰ ਮਿਲਾ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਸੁਧਾਰ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹੈ। ਪਹਿਲੀ ਹੈ ਘੇਰਾ: ਕਿਹੜਾ ਸਥਾਨਕ ਪਤਾ, ਕਿਹੜੇ ਦੂਰਲੇ ਪਤੇ, ਕਿਹੜਾ ਪ੍ਰੋਟੋਕਾਲ ਅਤੇ ਕਿਹੜੀ ICMP ਕਿਸਮ। ਦੂਜੀ ਹੈ ਸ਼ਰਤ: ਕੀ ਨਿਯਮ ਦਾ ਆਬਜੈਕਟ ਇਸ ਵੇਲੇ ਸਮਰੱਥ ਹੈ। ਘੇਰਾ ਉਹ ਹੈ ਜਿਸ ਦਾ ਫਾਇਰਵਾਲ ਹਰ ਪੈਕਟ ਲਈ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ; ਸ਼ਰਤ ਉਹ ਹੈ ਜੋ ਸਕ੍ਰਿਪਟ ਨੀਤੀ ਭੰਡਾਰ ਵਿੱਚ ਲਿਖਦੀ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਬਿਲਕੁਲ ਵੱਖਰੀਆਂ ਘੜੀਆਂ ’ਤੇ ਮਿਲਾਏ ਜਾਂਦੇ ਹਨ।

ਜੇ ਲੋੜ ਸੱਚਮੁੱਚ ਸਿਰਫ਼ VPN ਸਾਥੀ ਹੈ, ਤਾਂ ਘੇਰਾ ਹੀ ਕਿਸੇ ਕਨੈਕਸ਼ਨ-ਹਾਲਤ ਤਰਕ ਤੋਂ ਬਿਨਾਂ ਇਸ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਨਿਯਮ ਨੂੰ ਸੁਰੰਗ ਇੰਟਰਫ਼ੇਸ ਜਾਂ ਸੁਰੰਗ ਪਤਾ-ਲੜੀ ਨਾਲ ਬੰਨ੍ਹੋ, ਦੂਰਲੇ ਪਤਿਆਂ ਨੂੰ ਕਲਾਇੰਟ ਪੂਲ ਤੱਕ ਸੀਮਤ ਕਰੋ, ਅਤੇ «ICMP» ਦੀ ਥਾਂ echo ਕਿਸਮ ਦੱਸੋ। ਜਦੋਂ ਕੋਈ VPN ਚਾਲੂ ਨਹੀਂ ਹੁੰਦਾ ਤਦ ਵੀ ਉਹ ਨਿਯਮ ਸਹੀ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਅਣਸੰਬੰਧਿਤ ਪ੍ਰੋਫ਼ਾਈਲ ਇਸ ਨੂੰ ਖੋਲ੍ਹ ਨਹੀਂ ਸਕਦੀ।

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

ਆਬਜੈਕਟ ਇੱਕ ਵਾਰ ਬਣਾਓ, ਫਿਰ ਟੌਗਲ ਕਰੋ

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

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

ਨਾਮ ਟਿਕਾਊ ਪਛਾਣਕਰਤਾ ਹੈ; ਦਿਖਾਇਆ ਨਾਮ ਉਹ ਦਸਤਾਵੇਜ਼ ਹੈ ਜਿਸ ਨੂੰ ਮਨੁੱਖ ਸੋਧ ਸਕਦਾ ਹੈ। -Name ’ਤੇ ਮਿਲਾਓ ਅਤੇ ਸਕ੍ਰਿਪਟ ਨਕਲਾਂ ਬਣਾਉਣਾ ਬੰਦ ਕਰ ਦੇਵੇਗੀ। ਉਹੀ ਹੁਕਮ-ਆਕਾਰ IPv6 ਮਾਮਲੇ ਨੂੰ -Protocol ICMPv6 -IcmpType 128 ਨਾਲ ਢਕਦਾ ਹੈ, ਪਰ ਉਹ ਵੱਖਰਾ ਨਿਯਮ ਹੈ ਕਿਉਂਕਿ echo ਕਿਸਮ ਦੇ ਨੰਬਰ ਦੋਵਾਂ ਟੱਬਰਾਂ ਵਿੱਚ ਵੱਖਰੇ ਹਨ।

ਪਤਾ-ਟੱਬਰ ਅਤੇ ICMP ਕਿਸਮ ਸਪਸ਼ਟ ਰੱਖੋ, ਦੂਜਾ ਕਾਰਨ ਵੀ ਹੈ: -Protocol ICMPv4 ਕਿਸਮ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰੋਫ਼ਾਈਲ ਵੱਲੋਂ ਮਨਜ਼ੂਰ ਹਰ ICMPv4 ਸੁਨੇਹੇ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਉਹ ਵੀ ਜੋ ਤੁਸੀਂ ਕਦੇ ਸਵੀਕਾਰਨ ਦਾ ਸੋਚਿਆ ਨਹੀਂ। ਕਿਸਮ 8 ਦਾ ਨਾਮ ਲੈਣਾ ਨਿਯਮ ਨੂੰ echo ਬੇਨਤੀ ਤੱਕ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਪਹੁੰਚ-ਜਾਂਚ ਸਿਰਫ਼ ਉਹੀ ਭੇਜਦੀ ਹੈ।

ਜਿੱਥੇ ਸਵੈਚਾਲਨ ਇਰਾਦੇ ਦੇ ਉਲਟ ਹੈ

ਹਰ ਕੁਝ ਮਿੰਟਾਂ ਬਾਅਦ ਕਲਾਇੰਟ ਪ੍ਰੋਫ਼ਾਈਲ ਦੀ ਪੁੱਛਗਿੱਛ ਤੁਰੰਤ ਸੀਮਾ ਨਹੀਂ ਬਣਾ ਸਕਦੀ। ਕਨੈਕਸ਼ਨ ਡਿੱਗਣ ਅਤੇ ਅਗਲੀ ਪੁੱਛਗਿੱਛ ਵਿਚਕਾਰ ਨਿਯਮ ਜਨਤਕ ਪਤੇ ’ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਰਹਿੰਦਾ ਹੈ; ਕਨੈਕਸ਼ਨ ਉੱਠਣ ਅਤੇ ਅਗਲੀ ਪੁੱਛਗਿੱਛ ਵਿਚਕਾਰ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ। ਉਸ ਦੇਰੀ ਨੂੰ ਮੰਨਣਾ ਇਮਾਨਦਾਰ ਹੈ, ਅਤੇ ਇਹ ਕਹਿਣਾ ਕਿ ਰਚਨਾ ਸਖ਼ਤ ਅਟੱਲਤਾ ਲਾਗੂ ਕਰਦੀ ਹੈ, ਇਮਾਨਦਾਰ ਨਹੀਂ।

ਹਾਲਤ-ਜਾਂਚ ਵਿੱਚ ਹੀ ਘੇਰੇ ਦਾ ਫੰਦਾ ਹੈ। Get-VpnConnection ਮਸ਼ੀਨ ’ਤੇ ਸੰਰਚਿਤ ਕਲਾਇੰਟ ਪ੍ਰੋਫ਼ਾਈਲ ਦੱਸਦਾ ਹੈ, ਮੂਲ ਰੂਪ ਵਿੱਚ ਮੌਜੂਦਾ ਵਰਤੋਂਕਾਰ ਲਈ ਅਤੇ -AllUserConnection ਨਾਲ ਸਾਰੇ ਵਰਤੋਂਕਾਰਾਂ ਲਈ। ਇਹ ਉਨ੍ਹਾਂ ਦੂਰਲੇ ਵਰਤੋਂਕਾਰਾਂ ਦੀ ਸੂਚਨਾ ਨਹੀਂ ਦਿੰਦਾ ਜੋ ਇਸ ਵੇਲੇ RRAS ਸਰਵਰ ’ਤੇ ਡਾਇਲ-ਇਨ ਹਨ; ਉਹ ਦੂਜੇ ਹੁਕਮ ਵਾਲੀ ਦੂਜੀ ਨਿਗਰਾਨੀ ਹੈ। ਗ਼ਲਤ ਚੀਜ਼ ’ਤੇ ਬਣਿਆ ਗੇਟ ਕਿਸੇ ਨਾਲ ਵੀ ਜੁੜਿਆ ਨਹੀਂ ਹੁੰਦਾ।

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

ਅੰਤ ਵਿੱਚ, ਜਨਤਕ ਬੇਨਤੀ ਨੂੰ ਦੋ ਵਾਰ ਜਾਂਚੋ, ਇੱਕ ਵਾਰ ਚੁਣਿਆ ਕਨੈਕਸ਼ਨ ਚਾਲੂ ਹੋਣ ’ਤੇ ਅਤੇ ਇੱਕ ਵਾਰ ਬੰਦ ਹੋਣ ’ਤੇ, VPN ’ਤੇ ਨਾ ਹੋਣ ਵਾਲੇ ਹੋਸਟ ਤੋਂ। ਸੁਰੰਗ ਦੇ ਅੰਦਰੋਂ ਸਫਲ ping ਇਸ ਨੀਤੀ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਹੀ ਉਹ ਮਾਪ ਹੈ ਜੋ ਬਹੁਤੀਆਂ ਤੈਨਾਤੀਆਂ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ।