ਸਮੈਟ੍ਰਿਕ NAT ਅਤੇ VPN: ਲੇਬਲ ਨਹੀਂ, ਮੈਪਿੰਗ ਮਾਪੋ
ਐਂਡਪੁਆਇੰਟ-ਨਿਰਭਰ ਮੈਪਿੰਗ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਖੋਜ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ, ਆਮ ਕਲਾਇੰਟ-ਤੋਂ-ਸਰਵਰ ਟਨਲ ਨੂੰ ਨਹੀਂ। ਪੋਰਟ ਮਾਪੋ, ਅਤੇ ਸਿੱਧਾ ਰਾਹ ਫੇਲ ਹੋਵੇ ਤਾਂ ਰਿਲੇ ਵਰਤੋ।
ਇੱਕ ਸਹਾਇਤਾ ਥ੍ਰੈਡ “ਸਮੈਟ੍ਰਿਕ NAT, ਇੱਥੇ VPN ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ” ਵਾਲੇ ਫੈਸਲੇ ਨਾਲ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਕਲਾਇੰਟ ਬਿਨਾਂ ਕਿਸੇ ਕਾਰਨ ਤਿੰਨ ਵਾਰ ਦੁਬਾਰਾ ਇੰਸਟਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਲੇਬਲ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਨੇ ਨਹੀਂ ਪੁੱਛਿਆ। ਬਾਹਰ ਵੱਲ ਸਥਿਰ ਸਰਵਰ ਨਾਲ ਜੁੜਨ ਵਾਲਾ ਕਲਾਇੰਟ ਪਹਿਲਾ ਪੈਕੇਟ ਭੇਜਦੇ ਹੀ ਇੱਕ ਮੈਪਿੰਗ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਨੂੰ ਵਾਪਸ ਆਉਣ ਦੀ ਇਜਾਜ਼ਤ ਉਨ੍ਹਾਂ ਨਿਯਮਾਂ ਤਹਿਤ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਜੋ ਲਗਭਗ ਹਰ ਨੈੱਟਵਰਕ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਐਂਡਪੁਆਇੰਟ-ਨਿਰਭਰ ਮੈਪਿੰਗ ਅਸਲ ਵਿੱਚ ਜਿਸ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਂਦੀ ਹੈ ਉਹ ਹੈ ਦੋ ਪੀਅਰਾਂ ਦਾ ਇੱਕੋ ਸਮੇਂ ਇੱਕ-ਦੂਜੇ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ, ਅਤੇ ਉਹ ਵੱਖਰੀ ਪਰਖ ਹੈ।
ਇੱਕ ਲੇਬਲ ਪਿੱਛੇ ਦੋ ਸਵਾਲ ਲੁਕੇ ਹੋਏ ਹਨ
ਪਹਿਲਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਇਸ ਨੈੱਟਵਰਕ ਪਿੱਛੇ ਦਾ ਕੋਈ ਹੋਸਟ ਕਿਸੇ ਜਾਣੇ-ਪਛਾਣੇ ਜਨਤਕ ਪਤੇ ਅਤੇ ਪੋਰਟ ਉੱਤੇ ਸੈਸ਼ਨ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਟਨਲ ਕਲਾਇੰਟ ਲਈ ਇਹ ਆਮ ਸਥਿਤੀ ਹੈ, ਅਤੇ ਜਵਾਬ ਲਗਭਗ ਹਮੇਸ਼ਾ ਹਾਂ ਹੁੰਦਾ ਹੈ। ਰਾਊਟਰ ਅੰਦਰੂਨੀ ਸਰੋਤ ਦਰਜ ਕਰਦਾ ਹੈ, ਬਾਹਰੀ ਪੋਰਟ ਅਲਾਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਨੂੰ ਲੰਘਣ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅੰਦਰੋਂ ਸ਼ੁਰੂ ਹੋਏ ਸੈਸ਼ਨ ਦਾ ਹਿੱਸਾ ਹੈ।
ਦੂਜਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕਾਂ ਪਿੱਛੇ ਦੇ ਦੋ ਹੋਸਟ ਵਿਚਕਾਰ ਸਰਵਰ ਤੋਂ ਬਿਨਾਂ ਸਾਂਝਾ ਰਾਹ ਲੱਭ ਕੇ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਭੇਜ ਸਕਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਇਹ ਇਸ ਗੱਲ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਹਰ ਨੈੱਟਵਰਕ ਉਹ ਬਾਹਰੀ ਪੋਰਟ ਕਿਵੇਂ ਅਲਾਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਮੈਪਿੰਗ ਦੇ ਵਿਵਹਾਰ ਦੀ ਮਹੱਤਤਾ ਸਿਰਫ਼ ਉੱਥੇ ਹੀ ਹੈ।
ਦੋਵਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣ ਨਾਲ ਉਹੀ ਪੁਰਾਣੀ ਗਲਤ ਨਿਦਾਨ ਪੈਦਾ ਹੁੰਦੀ ਹੈ: ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਸੁਵਿਧਾ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਕੋਈ NAT-ਕਿਸਮ ਦੀ ਪਰਖ ਚਲਾਉਂਦਾ ਹੈ, ਸਭ ਤੋਂ ਖ਼ਰਾਬ ਸ਼੍ਰੇਣੀ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਸਿੱਟਾ ਕੱਢਦਾ ਹੈ ਕਿ ਆਮ ਟਨਲ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਫੇਲ ਹੋਈ ਚੀਜ਼ ਕਦੇ ਟਨਲ ਨਹੀਂ ਸੀ।
ਮੈਪਿੰਗ ਅਤੇ ਫਿਲਟਰਿੰਗ ਵੱਖਰੇ ਗੁਣ ਹਨ
RFC ਦੀ ਸ਼ਬਦਾਵਲੀ ਵਿਕਰੇਤਾਵਾਂ ਵੱਲੋਂ ਵਰਤੇ ਜਾਂਦੇ ਨਾਵਾਂ ਨਾਲੋਂ ਵਧੇਰੇ ਸਹੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਟਿਕਟ ਵਿੱਚ ਲਿਜਾਣਾ ਯੋਗ ਹੈ ਕਿਉਂਕਿ ਇਹ ਬਹਿਸਾਂ ਦਾ ਫ਼ੈਸਲਾ ਕਰਦੀ ਹੈ। ਮੈਪਿੰਗ ਇਹ ਹੈ ਕਿ ਬਾਹਰੀ ਪੋਰਟ ਕਿਵੇਂ ਅਲਾਟ ਹੁੰਦੀ ਹੈ। ਫਿਲਟਰਿੰਗ ਇਹ ਹੈ ਕਿ ਕਿਹੜੇ ਆਉਂਦੇ ਪੈਕੇਟ ਨੂੰ ਲੰਘਣ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਨੈੱਟਵਰਕ ਇੱਕ ਵਿੱਚ ਸਖ਼ਤ ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਉਦਾਰ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਮੇਲ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸਨੂੰ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਪ੍ਰੋਟੋਕਾਲ ਨੂੰ ਝੱਲਣਾ ਪੈਂਦਾ ਹੈ।
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
ਤੀਜੀ ਕਤਾਰ ਉਹ ਹੈ ਜਿਸਨੂੰ ਜ਼ਿਆਦਾਤਰ ਖਪਤਕਾਰ ਰਾਊਟਰ ਅਤੇ ਮੋਬਾਈਲ ਆਪਰੇਟਰ ਸਮੈਟ੍ਰਿਕ ਕਹਿੰਦੇ ਹਨ। ਧਿਆਨ ਦਿਓ ਕਿ ਲੇਬਲ ਸਿਰਫ਼ ਅਲਾਟਮੈਂਟ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਅਜਿਹੀ ਮੈਪਿੰਗ ਅਤੇ ਉਦਾਰ ਫਿਲਟਰਿੰਗ ਵਾਲਾ ਨੈੱਟਵਰਕ ਅਜੇ ਵੀ ਉਸ ਪੋਰਟ ਉੱਤੇ ਆਉਂਦੇ ਪੈਕੇਟ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਉਸਨੇ ਹੁਣੇ ਅਲਾਟ ਕੀਤੀ ਹੈ, ਇਸ ਲਈ ਹੋਲ-ਪੰਚਿੰਗ ਕੁਝ ਉੱਤੇ ਸਫਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕੁਝ ਉੱਤੇ ਫੇਲ।
ਫਿਲਟਰਿੰਗ ਦੇ ਆਪਣੇ ਤਿੰਨ ਮਾਮਲੇ ਹਨ ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਆਪਣਾ ਨਾਮ ਹੈ। ਟਿਕਟ ਵਿੱਚ “ਸਮੈਟ੍ਰਿਕ NAT” ਲਿਖਣਾ ਜਦੋਂ ਤੁਹਾਡਾ ਮਤਲਬ “ਪਤੇ ਅਤੇ ਪੋਰਟ-ਨਿਰਭਰ ਫਿਲਟਰਿੰਗ” ਹੈ, ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਮੈਨੂਅਲ ਦੇ ਗਲਤ ਅਧਿਆਇ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਪਰਖ ਵਿੱਚ ਦੋਵੇਂ ਵੱਖਰੇ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਗਲਤੀ ਸਿਰਫ਼ ਅਕਾਦਮਿਕ ਨਹੀਂ।
ਨਾਮ ਦੇਣ ਦੀ ਬਜਾਏ ਮੈਪਿੰਗ ਮਾਪੋ
ਤੁਸੀਂ ਜਿਸ ਵੀ UDP ਸੇਵਾ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ, ਉਸਦੇ ਸਰਵਰ ਪਾਸੇ ਤੋਂ ਅਲਾਟ ਕੀਤੀ ਪੋਰਟ ਸਿੱਧੀ ਦੇਖ ਸਕਦੇ ਹੋ। ਜਨਤਕ ਹੋਸਟ ਉੱਤੇ ਕੈਪਚਰ ਸ਼ੁਰੂ ਕਰੋ, ਕਲਾਇੰਟ ਤੋਂ ਭੇਜੋ, ਅਤੇ ਉਹ ਸਰੋਤ ਪੋਰਟ ਪੜ੍ਹੋ ਜਿਸ ਨਾਲ ਪੈਕੇਟ ਆਇਆ:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820ਐਂਡਪੁਆਇੰਟ ਕਤਾਰ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਲਾਹੇਵੰਦ ਹੈ, ਕਿਉਂਕਿ WireGuard ਹਰ ਪੀਅਰ ਤੋਂ ਮਿਲਿਆ ਆਖ਼ਰੀ ਪਤਾ ਅਤੇ ਪੋਰਟ ਦਰਜ ਕਰਦਾ ਹੈ। ਉਸ ਪੋਰਟ ਦੀ ਤੁਲਨਾ ਉਸ ਪੋਰਟ ਨਾਲ ਕਰੋ ਜਿਸਨੂੰ ਕਲਾਇੰਟ ਆਪਣੇ ਵਰਤੋਂ ਵਿੱਚ ਮੰਨਦਾ ਹੈ। ਜਦੋਂ ਵੀ ਕੋਈ ਅਨੁਵਾਦ ਹੁੰਦਾ ਹੈ ਤਾਂ ਉਹ ਵੱਖਰੇ ਹੋਣਗੇ, ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਮੁੱਲ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ।
ਦੂਜੀ ਮੰਜ਼ਿਲ ਪੋਰਟ ਜਾਂ ਦੂਜੇ ਸਰਵਰ ਸਾਮ੍ਹਣੇ ਨਿਰੀਖਣ ਦੁਹਰਾਓ ਅਤੇ ਫਿਰ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਬਾਹਰੀ ਪੋਰਟ ਹਰ ਮੰਜ਼ਿਲ ਲਈ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਮੈਪਿੰਗ ਪਤੇ ਅਤੇ ਪੋਰਟ-ਨਿਰਭਰ ਹੈ। ਜੇ ਉਹ ਉਹੀ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਨੈੱਟਵਰਕ ਤੁਹਾਨੂੰ ਇੱਕੋ ਮੈਪਿੰਗ ਦਿੰਦਾ ਹੈ ਅਤੇ ਖੋਜ ਕੋਲ ਮੌਕਾ ਹੈ।
STUN-ਅਧਾਰਿਤ ਸੰਦ ਇੱਕੋ ਕਦਮ ਵਿੱਚ ਉਹੀ ਸ਼੍ਰੇਣੀ ਦੱਸਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਨੈੱਟਵਰਕ ਕਿਸੇ ਜਨਤਕ STUN ਸਰਵਰ ਤੱਕ ਬਾਹਰ ਜਾਂਦੇ UDP ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਤਾਂ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਠੀਕ ਹੈ। ਜਦੋਂ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ ਉੱਪਰਲੀ ਕੈਪਚਰ ਵਿਧੀ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਨਿਯੰਤਰਣ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੋਸਟ ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਨਹੀਂ ਚਾਹੀਦਾ।
ਫੇਲ ਹੋਣ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੱਲ ਚੁਣੋ
ਜੇ ਫੇਲ ਹੋਣ ਵਾਲੀ ਸੁਵਿਧਾ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਹੈ, ਤਾਂ ਸਮਰਥਿਤ ਜਵਾਬ ਰਿਲੇ, ਅਜਿਹੀ ਮਿਲਣ ਸੇਵਾ ਜਿੱਥੇ ਦੋਵੇਂ ਪੀਅਰ ਪਹੁੰਚ ਸਕਣ, ਜਾਂ ਵੱਖਰੀ ਟੋਪੋਲੋਜੀ ਹਨ। TURN ਠੀਕ ਇਸੇ ਲਈ ਹੈ, ਅਤੇ ਜੋ ਉਤਪਾਦ ਆਪਣਾ ਰਿਲੇ ਲਿਆਉਂਦਾ ਹੈ ਉਹ ਤੁਹਾਨੂੰ ਦੱਸ ਰਿਹਾ ਹੈ ਕਿ ਉਹ ਕੁਝ ਨੈੱਟਵਰਕਾਂ ਦੇ ਦੁਸ਼ਮਣਾਨਾ ਹੋਣ ਦੀ ਉਮੀਦ ਰੱਖਦਾ ਹੈ।
ਜੇ ਫੇਲ ਹੋਣ ਵਾਲੀ ਸੁਵਿਧਾ ਆਮ ਟਨਲ ਹੈ, ਤਾਂ ਮੈਪਿੰਗ ਦਾ ਵਿਵਹਾਰ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ ਅਤੇ ਉੱਪਰਲਾ ਕੁਝ ਵੀ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ। ਜਾਂਚੋ ਕਿ ਕਲਾਇੰਟ ਸੱਚਮੁੱਚ ਭੇਜ ਰਿਹਾ ਹੈ, ਸਰਵਰ ਪੈਕੇਟ ਦੇਖ ਰਿਹਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਵਾਪਸ ਆ ਰਿਹਾ ਹੈ। ਉਹ ਕ੍ਰਮ ਤਿੰਨ ਨਿਰੀਖਣ ਹਨ ਅਤੇ ਇਸਨੂੰ ਰਾਊਟਰ ਦੀ NAT ਸ਼੍ਰੇਣੀ ਬਾਰੇ ਕੁਝ ਵੀ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ।
ਜੋ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਉਹ ਹੈ ਕੁਝ ਜੁੜਨ ਤੱਕ ਸਥਾਨਕ ਪੋਰਟ ਬਦਲਾਅ ਖਿੰਡਾਉਣਾ। ਕਲਾਇੰਟ ਦੀ ਸਰੋਤ ਪੋਰਟ ਬਦਲਣ ਨਾਲ ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਨੈੱਟਵਰਕ ਮੈਪਿੰਗ ਕਿਵੇਂ ਅਲਾਟ ਕਰਦਾ ਹੈ। ਪੰਜਵੀਂ ਕੋਸ਼ਿਸ਼ ਉੱਤੇ ਸੰਜੋਗ ਨਾਲ ਮਿਲੀ ਸਫਲਤਾ ਝੂਠਾ ਸਕਾਰਾਤਮਕ ਹੈ, ਅਤੇ ਮਹੀਨਿਆਂ ਤੱਕ ਇਸਨੂੰ ਹੱਲ ਦੱਸ ਕੇ ਹਵਾਲਾ ਦਿੱਤਾ ਜਾਵੇਗਾ।
ਫ਼ੈਸਲਾ ਨਹੀਂ, ਬਣਤਰ ਦਰਜ ਕਰੋ
ਇੱਕ ਲਾਹੇਵੰਦ ਨੋਟ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪ੍ਰੋਟੋਕਾਲ, ਸੈਸ਼ਨ ਕਿਸ ਦਿਸ਼ਾ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਰਾਹ ਵਿੱਚ ਰਿਲੇ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਤਾਰ ਉੱਤੇ ਕੀ ਦੇਖਿਆ ਗਿਆ। “ਸਮੈਟ੍ਰਿਕ NAT, ਕੰਮ ਨਹੀਂ ਕਰਦਾ” ਬੇਕਾਰ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇੱਕੋ ਸਮੇਂ ਟਨਲ ਬਾਰੇ ਗਲਤ ਹੈ ਅਤੇ ਪੀਅਰ ਦੇ ਰਾਹ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦਿੰਦਾ।
ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਪਰਖ ਕੀਤੀ ਹੈ ਤਾਂ ਮਾਪੀ ਗਈ ਪੋਰਟ ਸਥਿਰਤਾ ਅਤੇ ਫਿਲਟਰਿੰਗ ਦਾ ਵਿਵਹਾਰ ਸ਼ਾਮਲ ਕਰੋ। ਇਹ ਦੋ ਤੱਥ ਕਿਸੇ ਹੋਰ ਨੂੰ ਪੂਰੀ ਜਾਂਚ ਦੁਹਰਾਏ ਬਿਨਾਂ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦਿੰਦੇ ਹਨ ਕਿ ਨਵੀਂ ਸੁਵਿਧਾ ਉਸ ਨੈੱਟਵਰਕ ਉੱਤੇ ਕੰਮ ਕਰੇਗੀ ਜਾਂ ਨਹੀਂ। ਹਰ ਸਹਾਇਤਾ ਪੰਨੇ ਉੱਤੇ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਅਰਥ ਰੱਖਣ ਵਾਲੀ ਵਿਕਰੇਤਾ-ਸ਼੍ਰੇਣੀ ਨਾਲੋਂ ਉਹ ਵਧੇਰੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪੁਰਾਣੇ ਵੀ ਹੁੰਦੇ ਹਨ।
ਅੰਤ ਵਿੱਚ, ਇਹ ਲਿਖਦਿਆਂ RFC 4787 ਦੀ ਸ਼ਬਦਾਵਲੀ ਹੱਥ ਵਿੱਚ ਰੱਖੋ। ਸਹੀ ਸ਼ਬਦ ਵਰਤਣ ਦੀ ਕੀਮਤ ਇੱਕ ਵਾਕ ਹੈ ਅਤੇ ਇਹ ਅਗਲੇ ਪਾਠਕ ਨੂੰ ਉਹੀ ਗਲਤ ਨਿਦਾਨ ਦੁਹਰਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਨੋਟ ਲਿਖਣ ਦਾ ਪੂਰਾ ਮਕਸਦ ਇਹੀ ਹੈ।