OpenVPN ਅਤੇ HTTPS ਪੋਰਟ 443 ’ਤੇ: ਸਰੋਤਾ ਕਿਸਦਾ ਹੈ?
TCP ਅਤੇ UDP 443 ਵੱਖਰੇ ਸਾਕੇਟ ਹਨ। ਇੱਕ TCP ਸਰੋਤਾ ਸਾਂਝਾ ਕਰਨ ਲਈ ਮਾਲਕ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ OpenVPN ਦੀ ਪੋਰਟ ਸਾਂਝ ਬਾਰੀਕ ਪ੍ਰਬੰਧ ਹੈ, ਪ੍ਰੌਕਸੀ ਦੀ ਚਾਲ ਨਹੀਂ।
ਦੋ ਸੇਵਾਵਾਂ ਕਦੇ ਵੀ ਮੁਕਾਬਲਾ ਕੀਤੇ ਬਿਨਾਂ ਦੋਵੇਂ ਪੋਰਟ 443 ’ਤੇ ਜਵਾਬ ਦੇ ਸਕਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਸਰੋਤਾ ਸਿਰਫ਼ ਨੰਬਰ ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਟਰਾਂਸਪੋਰਟ, ਪਤਾ ਅਤੇ ਪੋਰਟ ਨਾਲ ਮਿਲ ਕੇ ਤੈਅ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਹੀ ਮਸ਼ੀਨ ’ਤੇ ਵੈੱਬ ਸਰਵਰ ਅਤੇ OpenVPN ਰੱਖੋ, ਅਤੇ ਪਹਿਲਾਂ ਜਵਾਬ ਦੇਣ ਯੋਗ ਇੱਕੋ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਹਰ ਪ੍ਰਕਿਰਿਆ ਕਰਨਲ ਤੋਂ ਕਿਹੜਾ ਸਾਕੇਟ ਮੰਗਦੀ ਹੈ। ਸੰਰਚਨਾ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸੂਚੀ ਲਿਖ ਲਓ, ਅਤੇ «ਪਤਾ ਪਹਿਲਾਂ ਹੀ ਵਰਤੋਂ ਵਿੱਚ ਹੈ» ਵਾਲੀਆਂ ਬਹੁਤੀਆਂ ਗਲਤੀਆਂ ਆਪਣੇ ਆਪ ਸਮਝ ਆ ਜਾਣਗੀਆਂ। ਸੂਚੀ ਤੋਂ ਬਾਅਦ ਦਾ ਸਭ ਕੁਝ UDP ਸਰੋਤਾ, ਸਾਂਝਾ TCP ਸਾਕੇਟ ਜਾਂ ਪ੍ਰੋਟੋਕੋਲ ਅਨੁਸਾਰ ਰੂਟ ਕਰਨ ਵਾਲੇ ਫਰੰਟ ਐਂਡ ਵਿਚਕਾਰ ਚੋਣ ਹੈ।
ਹਰ ਪ੍ਰਕਿਰਿਆ ਜੋ ਸਾਕੇਟ ਮੰਗਦੀ ਹੈ ਉੱਥੋਂ ਸ਼ੁਰੂ ਕਰੋ
bind ਉਸ ਤਿੱਕੜੀ ’ਤੇ ਸਫਲ ਜਾਂ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਦੋ ਡੀਮਨ ਤਦ ਹੀ ਟਕਰਾਉਂਦੇ ਹਨ ਜਦੋਂ ਤਿੰਨੇ ਭਾਗ ਮਿਲਦੇ ਹਨ। ਇਸੇ ਲਈ TCP 443 ’ਤੇ ਵੈੱਬਸਾਈਟ UDP 443 ’ਤੇ OpenVPN ਸਰੋਤੇ ਨਾਲ ਅਣਮਿੱਥ ਸਮੇਂ ਲਈ ਇਕੱਠੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਉਸੇ ਹੋਸਟ ਦੇ ਦੂਜੇ ਸਥਾਨਕ ਪਤੇ ’ਤੇ ਭੇਜਣ ਨਾਲ ਵੀ ਬਹਿਸ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ। ਜੀਵਤ ਸਰੋਤੇ ਪੜ੍ਹੋ, ਉਹ ਫਾਈਲਾਂ ਨਹੀਂ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਬਣਾਉਣੀਆਂ ਚਾਹੀਦੀਆਂ ਸਨ, ਕਿਉਂਕਿ ਪੁਰਾਣਾ include ਜਾਂ ਭੁੱਲੀ unit ਫਾਈਲ ਤੁਹਾਡੇ ਯਾਦ ਸੋਧ ਨਾਲੋਂ ਵੱਧ ਚਿਰ ਰਹਿੰਦੀ ਹੈ।
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root ਵਜੋਂ ss -lntup ਚਲਾਓ ਅਤੇ 443 ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲੀ ਹਰ ਲਾਈਨ, IPv6 ਐਂਟਰੀਆਂ ਸਮੇਤ ਪੜ੍ਹੋ। ਆਮ ਤੌਰ ’ਤੇ ਵਾਈਲਡਕਾਰਡ v6 ਸਰੋਤਾ v4 ਟ੍ਰੈਫਿਕ ਵੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ ਭੁੱਲਿਆ ਸਰੋਤਾ ਤੁਹਾਡੇ ਜ਼ਿੰਮੇਵਾਰ ਸਮਝੇ ਫਾਈਲ ਨੂੰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਵੀ ਪੋਰਟ ’ਤੇ ਕਬਜ਼ਾ ਰੱਖਦਾ ਹੈ। ਜੇ ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਾਮ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰੇ, ਤਾਂ ਕੁਝ ਵੀ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ss -lntup 'sport = :443' ਨਾਲ ਆਉਟਪੁੱਟ ਘਟਾਓ।
ਜਦੋਂ ਨੈੱਟਵਰਕ ਆਗਿਆ ਦੇਵੇ ਤਾਂ ਟਨਲ UDP ’ਤੇ ਲੈ ਜਾਓ
UDP ਸਰੋਤਾ ਟਕਰਾਅ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ ’ਤੇ ਸਭ ਤੋਂ ਛੋਟਾ ਉਪਾਅ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੋਈ ਸਾਕੇਟ ਸਾਂਝਾ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਰਾਹ ਵਿੱਚ ਕੋਈ ਵਾਧੂ ਉਤਪਾਦ ਨਹੀਂ ਆਉਂਦਾ। ਪਰ ਇਹ ਮੁਫ਼ਤ ਨਹੀਂ। ਕੁਝ ਕਲਾਇੰਟ ਨੈੱਟਵਰਕ reset ਭੇਜੇ ਬਿਨਾਂ UDP 443 ਛੱਡ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਟਨਲ bind ’ਤੇ ਅਸਫਲ ਹੋਣ ਦੀ ਬਜਾਏ ਸਥਾਪਤ ਹੋਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਵਰਤੋਂਕਾਰ ਪੜ੍ਹਨ ਯੋਗ ਕੋਈ ਗਲਤੀ ਬਿਨਾਂ VPN ਬੰਦ ਹੋਣ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। UDP ਸਰੋਤਾ ਵੈੱਬ ਪਰਤ ਦੇ ਮੁੜ-ਸ਼ੁਰੂ ਨੂੰ ਵੀ ਝੱਲਦਾ ਹੈ, ਜੋ ਅਜਿਹੀ ਮਸ਼ੀਨ ’ਤੇ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ ਜਿਸ ਦੀ ਸਾਈਟ ਅਕਸਰ ਮੁੜ-ਤੈਨਾਤ ਹੁੰਦੀ ਹੈ। ਉਸੇ ਨੈੱਟਵਰਕ ਤੋਂ ਜਾਂਚੋ ਜਿੱਥੇ ਵਰਤੋਂਕਾਰ ਬੈਠੇ ਹਨ, ਕਿਉਂਕਿ ਸਰਵਰ ’ਤੇ shell ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਰਵਰ ਆਪਣੇ ਆਪ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ।
ਸਰਵਰ ਸੰਰਚਨਾ ਅਤੇ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਟਰਾਂਸਪੋਰਟ ਇਕੱਠੇ ਬਦਲੋ। ਜੋ ਪ੍ਰੋਫਾਈਲ ਅਜੇ ਵੀ TCP ਮੰਗਦੀ ਹੈ ਉਹ ਸਿਰਫ਼ UDP ਸਰੋਤੇ ਸਾਮ੍ਹਣੇ ਮੁੜ-ਜੁੜਨ ਦੇ ਚੱਕਰ ਵਿੱਚ ਘੁੰਮੇਗੀ, ਅਤੇ ਦੋਵੇਂ ਫਾਈਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੱਕ ਇਹ ਨੈੱਟਵਰਕ ਖ਼ਰਾਬੀ ਵਰਗਾ ਲੱਗਦਾ ਹੈ।
VPN ਪ੍ਰਕਿਰਿਆ ਨੂੰ TCP 443 ਦਾ ਮਾਲਕ ਬਣਨ ਦਿਓ ਅਤੇ ਬਾਕੀ ਅੱਗੇ ਭੇਜੋ
TCP ਸਰਵਰ ਮੋਡ ਵਿੱਚ Community OpenVPN ਆਉਂਦੇ ਕਨੈਕਸ਼ਨ ਦੇ ਪਹਿਲੇ ਬਾਈਟ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਆਪਣਾ ਪ੍ਰੋਟੋਕੋਲ ਨਾ ਹੋਣ ਵਾਲਾ ਸਭ ਕੁਝ HTTPS ਬੈਕਐਂਡ ’ਤੇ ਭੇਜਦਾ ਹੈ, port-share ਨਿਰਦੇਸ਼ ਇਸੇ ਲਈ ਹੈ। ਬੈਕਐਂਡ TLS ਸਮਰੱਥ ਆਮ ਵੈੱਬ ਸਰਵਰ ਹੈ, ਜਿਸ ਨੂੰ ਉਸ ਨਿਰਦੇਸ਼ ਵਿੱਚ URL ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਹੋਸਟ ਅਤੇ ਪੋਰਟ ਨਾਲ ਨਾਮ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
port-share 10.0.0.5 8080
ਜਿਸ ਮਸ਼ੀਨ ਵਿੱਚ ਸਾਈਟ ਦਾ ਦੂਜਾ ਨਿੱਜੀ ਪਤਾ ਹੈ, ਉੱਥੇ ਉਹ ਲਾਈਨ ਗੈਰ-VPN ਟ੍ਰੈਫਿਕ 10.0.0.5:8080 ’ਤੇ ਭੇਜਦੀ ਹੈ, ਇਸ ਲਈ HTTPS ਵਰਚੁਅਲ ਹੋਸਟ ਉੱਥੇ ਬਾਈਂਡ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਫਾਇਰਵਾਲ ਨੂੰ ਸਥਾਨਕ ਛਾਲ ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ। ਵੈੱਬ ਸਰਵਰ ਨੂੰ TLS ਆਪਣੇ ਆਪ ਖ਼ਤਮ ਕਰਨਾ ਪਵੇਗਾ, ਕਿਉਂਕਿ ਆਉਣ ਵਾਲੇ ਬਾਈਟ ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਮੂਲ ਹੈਂਡਸ਼ੇਕ ਹਨ ਅਤੇ ਵਿਚਕਾਰ ਕਿਸੇ ਨੇ ਉਨ੍ਹਾਂ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਨਹੀਂ ਕੀਤਾ। ਨਿਰਦੇਸ਼ ਨੂੰ ਆਮ HTTP ਸਰੋਤੇ ਵੱਲ ਮੋੜੋ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਅਵੈਧ ਢੰਗ ਦੀ ਗਲਤੀ ਮਿਲੇਗੀ, ਜੋ ਟੁੱਟੀ ਸਾਈਟ ਵਰਗੀ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ, ਗਲਤ ਥਾਂ ਰੱਖੇ ਬੈਕਐਂਡ ਵਰਗੀ ਨਹੀਂ। ਨਿਰਦੇਸ਼ ਸਿਰਫ਼ TCP ਸਰਵਰ ਮੋਡ ਵਿੱਚ ਹੈ, ਅਤੇ UDP ਸਰੋਤੇ ਕੋਲ ਜਾਂਚਣ ਲਈ ਕੋਈ ਸਟ੍ਰੀਮ ਨਹੀਂ।
ਕਿਉਂਕਿ VPN ਪ੍ਰਕਿਰਿਆ ਹਰ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ, ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਅੱਗੇ ਭੇਜੀ ਬੇਨਤੀ ਨੂੰ ਸੈਲਾਨੀ ਤੋਂ ਨਹੀਂ, ਸਗੋਂ ਹੋਸਟ ਦੇ ਆਪਣੇ ਪਤਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਤੋਂ ਆਉਂਦੀ ਦੇਖਦੀ ਹੈ। ਜਿਸ ਨੂੰ ਅਸਲ ਕਲਾਇੰਟ ਪਤਾ ਚਾਹੀਦਾ ਹੈ ਉਹ ਬੈਕਐਂਡ ਵਿੱਚ PROXY ਪ੍ਰੋਟੋਕੋਲ ਸਮਰਥਨ ਜਾਂ ਉਹ ਜੋੜਨ ਵਾਲੇ ਫਰੰਟ ਐਂਡ ’ਤੇ ਨਿਰਭਰ ਹੈ। ਬੈਕਐਂਡ ਨੂੰ ਦੂਜੇ ਸਥਾਨਕ ਪਤੇ ’ਤੇ ਲਿਜਾਣ ਨਾਲ ਸੈਲਾਨੀ ਦਾ ਪਤਾ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ; ਇਹ ਸਿਰਫ਼ ਬਦਲਦਾ ਹੈ ਕਿ ਸਾਈਟ ਹੋਸਟ ਦੇ ਕਿਹੜੇ ਪਤੇ ਦਰਜ ਕਰਦੀ ਹੈ। ਵਿਸ਼ਲੇਸ਼ਣ ਰਿਪੋਰਟ ਸਵਾਲ ਚੁੱਕਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸੀਮਾ ਤੈਨਾਤੀ ਨੋਟਾਂ ਵਿੱਚ ਲਿਖੋ।
ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਗਲਤ ਸੰਦ ਹੈ; ਲੇਅਰ-ਚਾਰ ਰਾਊਟਰ ਨਹੀਂ
HTTP ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਬੇਨਤੀਆਂ ਪੜ੍ਹਨ ਲਈ TLS ਖ਼ਤਮ ਕਰਦਾ ਹੈ, ਭਾਵ ਇਹ OpenVPN ਸਟ੍ਰੀਮ ਨੂੰ ਬਿਨਾਂ ਛੋਹਏ ਲੰਘਾ ਨਹੀਂ ਸਕਦਾ। SNI ਜਾਂ ਪਹਿਲੇ ਪੈਕੇਟ ਦੀ ਜਾਂਚ ਅਨੁਸਾਰ ਅੱਗੇ ਭੇਜਣ ਵਾਲਾ ਲੇਅਰ-ਚਾਰ ਰਾਊਟਰ ਦੋਵਾਂ ਦੇ ਸਾਮ੍ਹਣੇ ਖੜ੍ਹ ਸਕਦਾ ਹੈ, ਬਸ਼ਰਤੇ ਇਹ ਉਸ ਸੈਸ਼ਨ ਨੂੰ ਖ਼ਤਮ ਨਾ ਕਰੇ ਜਿਸ ’ਤੇ VPN ਨਿਰਭਰ ਹੈ। ਦੋਵੇਂ ਜੰਤਰ ਚਿੱਤਰ ਵਿੱਚ ਇਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ ਅਤੇ ਸਾਕੇਟ ’ਤੇ ਬਿਲਕੁਲ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ।
ਵਪਾਰਕ Access Server ਆਪਣੀਆਂ ਪੋਰਟ-ਸਾਂਝ ਸੈਟਿੰਗਾਂ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਕਮਿਊਨਿਟੀ ਨਿਰਦੇਸ਼ ਨਾਲ ਇੱਕ-ਇੱਕ ਨਹੀਂ ਮਿਲਦੀਆਂ। ਦੂਜੇ ਲਈ ਲਿਖੀ ਗਾਈਡ ਅਪਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਤਪਾਦ ਅਤੇ ਸੰਸਕਰਣ ਪਛਾਣੋ। ਚੁੱਪਚਾਪ ਅਣਡਿੱਠ ਕੀਤੀ ਨਕਲ ਸੈਟਿੰਗ ਸੈਟਿੰਗ ਨਾ ਹੋਣ ਨਾਲੋਂ ਵੀ ਮਾੜੀ ਹੈ, ਕਿਉਂਕਿ ਉਸ ਤੋਂ ਬਾਅਦ ਵੀ ਸਰੋਤਿਆਂ ਦੀ ਸੂਚੀ ਭਰੋਸੇਯੋਗ ਦਿਸਦੀ ਹੈ।
ਵੈੱਬਸਾਈਟ ਅਤੇ ਟਨਲ ਨੂੰ ਦੋ ਵੱਖਰੇ ਰਾਹਾਂ ਵਜੋਂ ਜਾਂਚੋ
ਸਾਈਟ ਲੋਡ ਕਰੋ ਅਤੇ ਟਨਲ ਜੋੜੋ, ਫਿਰ ਸਰੋਤਿਆਂ ਦੀ ਸੂਚੀ ਦੁਬਾਰਾ ਪੜ੍ਹੋ ਕਿ ਹੁਣ 443 ਦਾ ਮਾਲਕ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਲੋਡ ਹੁੰਦਾ ਪੰਨਾ VPN ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਜੁੜਦਾ ਟਨਲ ਸਾਈਟ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਭਾਵੇਂ ਦੋਵੇਂ ਇੱਕੋ ਨੰਬਰ ਵਰਤਦੇ ਹਨ। ਹੇਠਲੇ ਤਿੰਨ ਕਮਾਂਡ ਕ੍ਰਮਵਾਰ ਸਾਂਝਾ ਸਾਕੇਟ, ਵੈੱਬ ਰਾਹ ਅਤੇ VPN ਸੇਵਾ ਜਾਂਚਦੇ ਹਨ।
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
ਉਸੇ ਪਲ ਲਈ ਬੈਕਐਂਡ ਦੇ ਪਹੁੰਚ ਲੌਗ ਵਿੱਚ ਕਲਾਇੰਟ ਪਤੇ ਦੀ ਤੁਲਨਾ VPN ਲੌਗ ਵਾਲੇ ਨਾਲ ਕਰੋ। ਜੇ ਸਾਈਟ ਹਰ ਸੈਲਾਨੀ ਨੂੰ ਹੋਸਟ ਆਪ ਹੀ ਵਜੋਂ ਦਰਜ ਕਰਦੀ ਹੈ, ਤਾਂ ਅੱਗੇ ਭੇਜਣਾ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਪਤਾ ਸੰਭਾਲ ਨਹੀਂ। ਜੇ ਦੋਵੇਂ ਲੌਗ ਚੁੱਪ ਰਹਿਣ, ਤਾਂ ਫਰੰਟ ਐਂਡ ਨੇ ਕਦੇ ਵੀ ਕਨੈਕਸ਼ਨ ਸੌਂਪਿਆ ਨਹੀਂ। ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ, ਸਾਕੇਟ ਕੌਣ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਇਹ ਸਰੋਤਿਆਂ ਦੀ ਸੂਚੀ ਤੈਅ ਕਰਦੀ ਹੈ, ਅਤੇ ਦੂਜੀ ਫਾਈਲ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹੀ ਤੱਥ ਪੁਸ਼ਟੀ ਕਰਨ ਯੋਗ ਹੈ।
ਉਹ ਸਰੋਤਾ-ਨਕਸ਼ਾ ਸੰਰਚਨਾ ਦੇ ਕੋਲ ਛੱਡੋ ਤਾਂ ਜੋ 443 ਨੂੰ ਛੂਹਣ ਵਾਲਾ ਅਗਲਾ ਵਿਅਕਤੀ ਜਾਣ ਸਕੇ ਕਿ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਦੂਜਾ ਪ੍ਰੋਟੋਕੋਲ ਕਿੱਥੇ ਗਿਆ। ਸੋਧ ਦਾ ਮਕਸਦ ਕੀ ਸੀ ਇਸ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਮਾਲਕੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।