ਇੱਕ ਜਨਤਕ ਗੇਟਵੇ ਪਹਿਲਾਂ ਹੀ UDP 51820 ਉੱਤੇ WireGuard, 22 ਉੱਤੇ SSH ਅਤੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਚਲਾ ਰਿਹਾ ਹੈ ਜੋ ਇੰਟਰਨੈੱਟ ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਲੁਭਾਉਣ ਵਾਲਾ ਨਿਯਮ ਹਰ ਪੋਰਟ ਪੀਅਰ ਵੱਲ ਭੇਜ ਕੇ ਕੰਮ ਮੁਕੰਮਲ ਕਹਿ ਦਿੰਦਾ ਹੈ। WireGuard ਗੇਟਵੇ ਉੱਤੇ ਅਜਿਹਾ ਨਿਯਮ ਟਨਲ ਦੀ ਆਪਣੀ ਆਵਾਜਾਈ ਫੜ ਸਕਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਉਸ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਖ਼ਤਮ ਕਰਦੀ ਹੈ। ਪ੍ਰਕਾਸ਼ਨ ਇੱਕ ਰੂਟਿੰਗ ਫੈਸਲਾ ਹੈ ਜਿਸ ਵਿੱਚ ਕੰਟਰੋਲ ਪਲੇਨ ਦਾ ਅਪਵਾਦ ਹੈ, ਇੱਕ DNAT ਲਾਈਨ ਨਹੀਂ।

ਜਨਤਕ ਦਾਖਲਾ ਜਾਂ ਟਨਲ ਦਾਖਲਾ: ਇੱਕ ਚੁਣੋ

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

ਪ੍ਰਬੰਧਕੀ ਇੰਟਰਫ਼ੇਸ ਉੱਥੇ ਘੱਟ ਹੀ ਸਹੀ ਬੈਠਦੇ ਹਨ। ਅਧਿਕਾਰਤ VPN ਕਲਾਇੰਟਾਂ ਦੁਆਰਾ ਪਹੁੰਚਯੋਗ ਐਡਮਿਨ ਪੇਜ ਹਮਲੇ ਦੀ ਸਤ੍ਹਾ ਨੂੰ ਟਨਲ ਦੇ ਅੰਦਰ ਰੱਖਦਾ ਹੈ ਅਤੇ ਲਾਗਇਨ ਫਾਰਮ ਨੂੰ ਬੇਤਰਤੀਬ ਸਕੈਨਿੰਗ ਲਈ ਖੋਲ੍ਹਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਜਨਤਕ ਐਪਲੀਕੇਸ਼ਨ ਐਂਡਪੌਇੰਟਾਂ ਨੂੰ ਅਜੇ ਵੀ ਆਪਣਾ TLS ਸਰਟੀਫਿਕੇਟ, ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਦਰ ਸੀਮਾ ਚਾਹੀਦੀ ਹੈ; ਐਨਕ੍ਰਿਪਟਿਡ WireGuard ਕਦਮ ਦਰਸ਼ਕ ਦੇ ਹਿੱਸੇ ਨੂੰ ਗੇਟਵੇ ਤੱਕ ਨਹੀਂ ਬਚਾਉਂਦਾ।

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

ਇੱਕ ਪੋਰਟ ਅੰਦਰ, ਇੱਕ ਬੈਕਐਂਡ ਬਾਹਰ

ਇੱਕ ਜਨਤਕ ਪੋਰਟ ਅਤੇ ਇੱਕ ਬੈਕਐਂਡ ਸੇਵਾ ਵਰਤੋ। ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ eth0 ਜਨਤਕ ਪਤਾ 198.51.100.20 ਰੱਖਦਾ ਹੈ, ਗੇਟਵੇ ਦਾ ਟਨਲ ਪਤਾ 10.200.0.1 ਹੈ, ਅਤੇ ਪੀਅਰ ਐਪਲੀਕੇਸ਼ਨ 10.200.0.7 ਉੱਤੇ ਚਲਾਉਂਦਾ ਹੈ। ਜਨਤਕ TCP 9443 ਪੀਅਰ ਦੇ TCP 8443 ਉੱਤੇ ਮੈਪ ਹੁੰਦਾ ਹੈ:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

SNAT ਨਿਯਮ ਅਨੁਵਾਦਿਤ ਬੈਕਐਂਡ ਅਤੇ ਅਸਲ ਜਨਤਕ ਮੰਜ਼ਿਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਉਸੇ ਬੈਕਐਂਡ ਸੇਵਾ ਨਾਲ ਦੂਜਾ ਕਨੈਕਸ਼ਨ ਇਸ ਮੈਪਿੰਗ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਦਰਸ਼ਕ ਦਾ ਪਤਾ ਪੀਅਰ ਤੋਂ ਲੁਕਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਹ ਵਟਾਂਦਰਾ ਹੈ ਜੋ ਸਰੋਤ ਨੂੰ ਸੰਭਾਲਣ ਵਾਲੇ ਰੂਟਡ ਵਾਪਸੀ ਨੂੰ ਵੱਖਰਾ ਡਿਜ਼ਾਈਨ ਬਣਾਉਂਦਾ ਹੈ। iptables ਐਕਸਟੈਂਸ਼ਨਾਂ ਦਾ ਹਵਾਲਾ ਦੋਵੇਂ ਟਾਰਗਿਟਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਮੇਲ ਖਾਣ ਵਿਕਲਪਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

ਫਾਰਵਰਡਿੰਗ ਅਜੇ ਵੀ ਚਾਲੂ ਕਰਨੀ ਪਵੇਗੀ, ਅਤੇ ਫਿਲਟਰ ਚੇਨ ਨੂੰ ਅਨੁਵਾਦਿਤ ਮੰਜ਼ਿਲ ਅਤੇ ਪੋਰਟ ਲਈ, ਨਾਲ ਹੀ ਸਥਾਪਿਤ ਜਵਾਬਾਂ ਲਈ ਇਜਾਜ਼ਤ ਚਾਹੀਦੀ ਹੈ। FORWARD ਚੇਨ DNAT ਤੋਂ ਬਾਅਦ ਅਨੁਵਾਦਿਤ ਮੰਜ਼ਿਲ ਦੇਖਦੀ ਹੈ, ਇਸ ਲਈ ਜਨਤਕ ਪਤੇ ਦੇ ਵਿਰੁੱਧ ਲਿਖਿਆ ਨਿਯਮ ਫਾਰਵਰਡ ਕੀਤੇ ਪੈਕਟ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਇਜਾਜ਼ਤ ਬੈਕਐਂਡ ਟਿਊਪਲ ਦੇ ਵਿਰੁੱਧ ਲਿਖੋ, ਜਨਤਕ ਦੇ ਵਿਰੁੱਧ ਨਹੀਂ।

ਪੀਅਰ ਨੂੰ ਸੇਵਾ ਕਨੈਕਸ਼ਨ ਗੇਟਵੇ ਦੇ ਟਨਲ ਪਤੇ ਤੋਂ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਟਨਲ ਰਾਹੀਂ ਵਾਪਸ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਦਾ AllowedIPs ਉਸ ਸਰੋਤ ਨੂੰ ਅਧਿਕਾਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇਹ ਅਸਲ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਰੋਤ ਅਨੁਵਾਦ ਹੇਠ ਇਹ ਗੇਟਵੇ ਦਾ ਟਨਲ ਪਤਾ ਹੈ, ਅਤੇ ਹਰ ਪੀਅਰ ਉੱਤੇ ਚੌੜੀ 0.0.0.0/0 ਐਂਟਰੀ ਇਸ ਡਿਜ਼ਾਈਨ ਲਈ ਲਾਜ਼ਮੀ ਨਹੀਂ। ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਨੂੰ ਡੇਗਣ ਵਾਲਾ ਉਹ ਪੀਅਰ ਹੈ ਜਿਸਦੀ ਸੂਚੀ ਵਿੱਚ ਉਹ ਪਤਾ ਨਹੀਂ, ਜਾਂ ਉਹ ਡਿਜ਼ਾਈਨ ਜੋ ਸਰੋਤ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਦਰਸ਼ਕ ਦਾ ਆਪਣਾ ਪਤਾ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ ਆਪਣੇ ਨਿਯਮ ਵਾਲਾ ਨਹੀਂ, ਪੀਅਰ ਵੱਲੋਂ ਅਸਲ ਵਿੱਚ ਦੇਖਿਆ ਜਾਣ ਵਾਲਾ ਸਰੋਤ ਜਾਂਚੋ।

ਗੇਟਵੇ ਦੇ ਆਪਣੇ ਲਿਸਨਰਾਂ ਨੂੰ ਨਿਯਮ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

ਮੰਜ਼ਿਲ ਦਾ ਅਨੁਵਾਦ ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਮਸ਼ੀਨ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਪੈਕਟ ਸਥਾਨਕ ਹੈ, ਇਸ ਲਈ UDP 51820 ਹਰ ਪੀਅਰ ਕਨੈਕਸ਼ਨ ਰੱਖਣ ਵਾਲੇ ਪ੍ਰੋਸੈਸ ਕੋਲ ਨਹੀਂ, ਪੀਅਰ ਕੋਲ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਨਿਯਮ ਸਫਲਤਾਪੂਰਵਕ ਲੋਡ ਹੁੰਦਾ ਹੈ ਅਤੇ ਟਨਲ ਮਰ ਜਾਂਦਾ ਹੈ, ਜੋ ਪੀਅਰ ਪਾਸਿਓਂ ਪੜ੍ਹਨਾ ਔਖਾ ਫੇਲ੍ਹ ਹੈ।

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

ਜੇ ਚੌੜੀ ਫਾਰਵਰਡਿੰਗ ਸੱਚਮੁੱਚ ਲੋੜੀਂਦੀ ਹੈ, ਤਾਂ ਸਭ ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲੇ ਨਿਯਮ ਤੋਂ ਪਹਿਲਾਂ ਕੰਟਰੋਲ ਪੋਰਟ ਰਾਖਵੇਂ ਰੱਖੋ ਜਾਂ ਪ੍ਰਕਾਸ਼ਨ ਲਈ ਵੱਖਰਾ ਜਨਤਕ ਪਤਾ ਵਰਤੋ। ਦੂਜਾ ਵਿਕਲਪ ਵਧੇਰੇ ਸਾਫ਼ ਹੈ ਕਿਉਂਕਿ ਕੰਟਰੋਲ ਪਤਾ ਆਪਣੀ ਨੀਤੀ ਰੱਖਦਾ ਹੈ, ਪਰ ਪ੍ਰਦਾਤਾ ਨੂੰ ਉਹ ਪਤਾ ਦੇਣਾ ਪਵੇਗਾ; DNS ਰਿਕਾਰਡ ਜੋੜਨਾ ਇੱਕ ਨਹੀਂ ਦਿੰਦਾ।

ਚੌੜੀ TCP ਅਤੇ UDP ਫਾਰਵਰਡਿੰਗ ਵੀ ਸਾਰੇ ਪ੍ਰੋਟੋਕੋਲ ਨਹੀਂ ਹੈ। ICMP, IPv6, ਪਾਥ MTU ਫੀਡਬੈਕ ਅਤੇ VPN ਦੀ ਬਾਹਰੀ ਆਵਾਜਾਈ ਨੂੰ ਆਪਣੀ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ TCP ਤੇ UDP ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲਾ ਨਿਯਮ ਉਹ ਕੇਸ ਡਿਫ਼ਾਲਟ ਚੇਨ ਲਈ ਛੱਡ ਦਿੰਦਾ ਹੈ।

ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਡਲ ਚੁਣੋ

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

ModelWhat it protectsCostUse when
Narrow port forwardEvery other listener, including the VPNOne rule per serviceFew services, stable ports
Catch-all with reserved portsPorts named in the exception listRule order becomes criticalMany services and disciplined review
Separate public addressControl address fully isolatedProvider must supply the addressHigh-value publication
VPN-only accessNo public entry at allVisitors need the tunnelAdmin interfaces and internal tools

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

ਪ੍ਰਕਾਸ਼ਨ ਅਤੇ ਕੰਟਰੋਲ ਮਾਰਗ ਦੋਵੇਂ ਸਾਬਤ ਕਰੋ

ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਹੋਸਟਨਾਮ ਅਤੇ ਇਸ ਲਈ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਅਧਿਕਾਰਤ ਬਾਹਰੀ ਕਲਾਇੰਟ ਤੋਂ ਜਾਂਚੋ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਹੜਾ ਬੈਕਐਂਡ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਸੀ, ਫਿਰ ਜਾਂਚੋ ਕਿ ਬੇਸੰਬੰਧ ਜਨਤਕ ਪੋਰਟ ਅਜੇ ਵੀ ਰੱਦ ਹਨ। ਬੰਦ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਸਫਲ HTTPS ਟੈਸਟ ਨਹੀਂ ਹੈ, ਅਤੇ ਗਲਤ ਬੈਕਐਂਡ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਫੇਲ੍ਹ ਹੋਣ ਨਾਲੋਂ ਮਾੜਾ ਹੈ।

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

ਸੰਬੰਧਿਤ ਲੇਖ