ਆਉਣ ਵਾਲਾ ਟਨਲ ਕਿਹੜਾ RRAS ਸਾਈਟ ਇੰਟਰਫ਼ੇਸ ਚੁਣਦਾ ਹੈ?
RRAS ਆਉਣ ਵਾਲੇ ਸਾਈਟ ਇੰਟਰਫ਼ੇਸ ਨੂੰ ਪੀਅਰ ਪਤਾ, ਵਰਤੋਂਕਾਰ ਨਾਮ ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਦੇ ਵਿਸ਼ੇ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣਦਾ ਹੈ, ਇਸ ਲਈ ਉਹ ਕੁੰਜੀ ਇਸ ਦੀਆਂ ਸਮਰੱਥ ਅਤੇ ਜੁੜੀਆਂ ਸਥਿਤੀਆਂ ਤੋਂ ਵੱਖਰੀ ਪੜ੍ਹੋ।
ਕਈ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਇੰਟਰਫ਼ੇਸਾਂ ਵਾਲੇ Windows ਸਰਵਰ 'ਤੇ ਕੰਸੋਲ ਦਾ ਲੇਬਲ ਸਿਰਫ਼ ਲੋਕਾਂ ਲਈ ਨੋਟ ਨਹੀਂ ਹੈ। RRAS ਆਉਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਦੇ ਇੱਕ ਖ਼ਾਸ ਖੇਤਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਤਾਰਕਿਕ ਇੰਟਰਫ਼ੇਸ ਜਵਾਬ ਦੇਵੇਗਾ, ਅਤੇ ਉਹ ਖੇਤਰ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ ਨਾਲ ਬਦਲਦਾ ਹੈ। ਕੁੰਜੀ ਗ਼ਲਤ ਹੋਈ ਤਾਂ ਤੁਸੀਂ ਇੰਟਰਫ਼ੇਸਾਂ ਦੇ ਨਾਮ ਬਦਲਦੇ ਰਹੋਗੇ ਜਦ ਤੱਕ ਕੁਝ ਸੰਜੋਗ ਨਾਲ ਜੁੜ ਨਾ ਜਾਵੇ। ਚੋਣ ਨਿਯਮ, ਪ੍ਰਬੰਧਕੀ ਸਥਿਤੀ ਅਤੇ ਸੈਸ਼ਨ ਸਥਿਤੀ ਤਿੰਨ ਵੱਖਰੇ ਤੱਥ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਨਾਮਕਰਨ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ।
ਭਰਮ: ਨਾਮ ਬਦਲਿਆ ਇੰਟਰਫ਼ੇਸ ਹਰ ਚੀਜ਼ ਨਾਲ ਮੇਲ ਖਾਵੇਗਾ
ਜਦੋਂ ਕੋਈ ਸ਼ਾਖਾ ਜੁੜ ਨਹੀਂ ਸਕਦੀ ਤਾਂ ਲਾਲਚ ਦੇਣ ਵਾਲਾ ਉਪਾਅ ਇਹ ਹੈ ਕਿ ਕਾਲ ਕਰਨ ਵਾਲੇ ਵਰਗਾ ਦਿਸਣ ਤੱਕ ਸਾਈਟ ਇੰਟਰਫ਼ੇਸ ਬਣਾਇਆ ਜਾਂ ਉਸਦਾ ਨਾਮ ਬਦਲਿਆ ਜਾਵੇ। ਇਹ ਇੱਕ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਬਾਕੀਆਂ ਲਈ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਇਸੇ ਲਈ ਉਹੀ ਵਿਧੀ ਵਿਰੋਧਾਭਾਸੀ ਨਤੀਜਿਆਂ ਨਾਲ ਫੈਲਦੀ ਹੈ। ਸਾਈਟ ਇੰਟਰਫ਼ੇਸ ਆਪਣੀ ਮੰਜ਼ਿਲ, ਸੁਰੱਖਿਅਤ ਪ੍ਰੀਫ਼ਿਕਸ ਅਤੇ ਸਥਿਤੀ ਵਾਲੀ ਤਾਰਕਿਕ ਕਨੈਕਸ਼ਨ ਵਸਤੂ ਹੈ। ਇਹ ਐਨਕ੍ਰਿਪਟਿਡ ਪੈਕਟ ਢੋਣ ਵਾਲਾ ਭੌਤਿਕ ਅਡੈਪਟਰ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਨੈੱਟਵਰਕ ਅਡੈਪਟਰਾਂ ਵੱਲ ਵੇਖਣ ਨਾਲ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਕਿਹੜੀ ਸਾਈਟ ਵਸਤੂ ਚੁਣੀ ਗਈ।
ਚੋਣ ਦਾ ਆਮ ਦੂਰ-ਪਹੁੰਚ ਵਰਤੋਂਕਾਰਾਂ ਨਾਲ ਵੀ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ। ਜੇ ਕਰਮਚਾਰੀਆਂ ਦੇ VPN ਕਲਾਇੰਟ ਡਾਇਲ ਕਰਦੇ ਹਨ ਤਾਂ ਉਹਨਾਂ ਦੀ ਭੂਮਿਕਾ ਵੱਖਰੀ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਵਰਤੋਂਕਾਰ ਨਾਮ ਇਸ ਮੈਪਿੰਗ ਵਿੱਚ ਕਦੇ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੇ। ਕਿਸੇ ਜਾਣੇ-ਪਛਾਣੇ ਨਾਮ ਤੋਂ ਕੁਝ ਵੀ ਅਰਥ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਾਲ ਕਰਨ ਵਾਲਾ ਕਿਹੜੀ ਭੂਮਿਕਾ ਦਾ ਹੈ।
ਤਿੰਨ ਪ੍ਰਮਾਣਿਕਤਾ ਰੂਪ, ਤਿੰਨ ਚੋਣ ਕੁੰਜੀਆਂ
ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਕੁੰਜੀ ਨਾਲ, ਇੰਟਰਫ਼ੇਸ ਦਾ ਸੰਰਚਿਤ ਮੰਜ਼ਿਲ ਪਤਾ ਆਉਣ ਵਾਲੇ ਪੀਅਰ ਦੇ ਪਤੇ ਨਾਲ ਤੁਲਨਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਲੇਬਲ ਕੁਝ ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਫ਼ੈਸਲਾ ਪਤਾ ਹੀ ਢੋਂਦਾ ਹੈ। ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਧਾਰਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿੱਚ, ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਕਾਲ ਕਰਨ ਵਾਲੇ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੇ ਵਰਤੋਂਕਾਰ ਨਾਮ ਨਾਲ ਤੁਲਨਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਥੇ ਲੇਬਲ ਹੀ ਕੁੰਜੀ ਹੈ, ਅਤੇ ਨਾਮ ਬਦਲਣ ਨਾਲ ਇੱਕ ਸਾਈਟ ਠੀਕ ਅਤੇ ਦੂਜੀ ਖਰਾਬ ਹੁੰਦੀ ਦਿਸਣ ਦਾ ਇਹੀ ਕਾਰਨ ਹੈ।
ਸਰਟੀਫਿਕੇਟਾਂ ਨਾਲ, ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਪੇਸ਼ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਵਿੱਚ ਵਿਸ਼ਾ ਨਾਮ ਨਾਲ ਤੁਲਨਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਨਾਮ ਉਸ ਵਿਸ਼ੇ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਆਪਰੇਟਰ ਵੱਲੋਂ ਘੜਿਆ ਸੋਹਣਾ ਲੇਬਲ ਕਾਫ਼ੀ ਨਹੀਂ ਹੋਵੇਗਾ।
ਇਸ ਤੋਂ ਦੋ ਨਤੀਜੇ ਨਿਕਲਦੇ ਹਨ। ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਕੁੰਜੀ ਦੀ ਬਣਤਰ ਵਿੱਚ ਦਿੱਤੀ ਮੰਜ਼ਿਲ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਇੰਟਰਫ਼ੇਸ ਸਮਰੱਥ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕੋ ਦੇਖਿਆ ਗਿਆ ਜਨਤਕ ਪਤਾ ਸਾਂਝਾ ਕਰਨ ਵਾਲੀਆਂ ਦੋ ਸ਼ਾਖਾਵਾਂ ਨੂੰ ਨਕਲੀ ਐਂਟਰੀਆਂ ਨਾਲ ਦੋਵੇਂ ਸੇਵਾ ਨਹੀਂ ਮਿਲ ਸਕਦੀ। ਅਤੇ ਕੰਸੋਲ ਚਾਹੇ ਕੁਝ ਵੀ ਸੁਝਾਏ, ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਸੰਰਚਿਤ ਕੀਤਾ ਢੰਗ ਹੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।
| Authentication in use | The field RRAS compares | Symptom when the two disagree |
|---|---|---|
| Pre-shared key | The peer address in the incoming connection against the interface destination | Renaming the interface changes nothing; a destination that does not match the caller stays unused |
| Username | The caller login against the interface name | A site with a friendly label never answers, while a differently named site may answer instead |
| Certificate | The subject name in the presented certificate against the interface name | An interface named after the office rather than the subject CN is never selected |
ਸਮਰੱਥ ਹੋਣਾ ਜੁੜਿਆ ਹੋਣਾ ਨਹੀਂ ਹੈ
ਪ੍ਰਬੰਧਕੀ ਸਥਿਤੀ ਦੱਸਦੀ ਹੈ ਕਿ ਤਾਰਕਿਕ ਇੰਟਰਫ਼ੇਸ ਨੂੰ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ ਜਾਂ ਨਹੀਂ। ਕਨੈਕਸ਼ਨ ਸਥਿਤੀ ਦੱਸਦੀ ਹੈ ਕਿ ਹੁਣ ਸੈਸ਼ਨ ਹੈ ਜਾਂ ਨਹੀਂ। ਸੈਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਸਮਰੱਥ ਇੰਟਰਫ਼ੇਸ ਮੰਗ ਅਨੁਸਾਰ ਡਾਇਲ ਹੋਣ ਵਾਲੀ ਲਿੰਕ ਲਈ ਆਮ ਆਰਾਮ ਸਥਿਤੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਖ਼ਰਾਬੀ ਦੱਸਣ ਨਾਲ ਲੋਕ ਨਾ-ਮੌਜੂਦ ਰੁਕਾਵਟ ਦੇ ਪਿੱਛੇ ਭੱਜਦੇ ਹਨ।
ਨਾਮਿਤ ਖੋਜ ਜਾਂ ਦਸਤਾਵੇਜ਼ੀ ਰੂਟਿੰਗ-ਡੋਮੇਨ ਖੋਜ ਵਰਤੋ, ਪਰ ਦੋਵੇਂ ਪੈਰਾਮੀਟਰ ਇਕੱਠੇ ਨਹੀਂ, ਅਤੇ ਇਸਨੂੰ ਮਨਜ਼ੂਰ ਸਰਵਰ ਸੰਦਰਭ ਵਿੱਚ ਚਲਾਓ। ਜੇ ਤੁਸੀਂ ਜਿਸ ਇੰਟਰਫ਼ੇਸ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ ਉਹ ਪਹਿਲੀ ਸੂਚੀ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਸਥਿਤੀ ਤੋਂ ਪਹਿਲਾਂ ਹੈ: ਕੁਝ ਵੀ ਨਹੀਂ ਚੁਣਿਆ ਗਿਆ।
ਜੋੜੀ ਨੂੰ ਵੱਖਰਾ ਨਹੀਂ, ਇਕੱਠੇ ਪੜ੍ਹੋ। ਜਿਹੜੀ ਲਿੰਕ ਸਥਿਰ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਡਿਸਕਨੈਕਟ ਦਿਸਦੀ ਹੈ ਉਹ ਜਾਂਚ ਦੇ ਯੋਗ ਹੈ, ਜਦਕਿ ਮੰਗ ਅਨੁਸਾਰ ਜੁੜਨ ਵਾਲੀ ਨਿਸ਼ਕਿਰਿਆ ਲਿੰਕ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। ਇਸ ਦੌਰਾਨ ਪ੍ਰਬੰਧਕੀ ਤੌਰ 'ਤੇ ਅਯੋਗ ਕੀਤਾ ਇੰਟਰਫ਼ੇਸ ਸਾਹਮਣੇ ਵਾਲਾ ਧਿਰ ਆਪਣਾ ਰਾਊਟਰ ਕਿੰਨੀ ਵੀ ਵਾਰ ਰੀਬੂਟ ਕਰੇ, ਹਨੇਰਾ ਹੀ ਰਹੇਗਾ।
ਦੋਵੇਂ ਮੁੱਲਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਪ੍ਰਮਾਣਿਕਤਾ ਸਫਲ ਹੋਈ, ਗੱਲਬਾਤ ਕੀਤੀ ਸੁਰੱਖਿਆ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਰੂਟ ਸਥਾਪਿਤ ਹੋਏ ਜਾਂ ਨਿੱਜੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। ਇਹ ਚਾਰ ਵੱਖਰੇ ਸਵਾਲ ਅਤੇ ਚਾਰ ਵੱਖਰੇ ਜਵਾਬ ਹਨ।
Get-VpnS2SInterface | Select-Object Name, Destination, AdminStatus, ConnectionState
Get-VpnS2SInterface -Name 'Branch-A' | Format-List Name, Destination, AdminStatus, ConnectionStateਕੁਝ ਵੀ ਸਮਰੱਥ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣ ਦਾ ਲੈਣ-ਦੇਣ ਪੜ੍ਹੋ
ਜਦੋਂ ਆਉਣ ਵਾਲਾ ਕਾਲ ਕਰਨ ਵਾਲਾ ਤੁਹਾਡੀ ਉਮੀਦ ਤੋਂ ਵੱਖਰੇ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਮੈਪ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਲਾਹੇਵੰਦ ਸਬੂਤ ਉਸਦੀ ਪੇਸ਼ ਕੀਤੀ ਪਛਾਣ ਹੈ, ਅਯੋਗ ਇੰਟਰਫ਼ੇਸਾਂ ਦੀ ਸੂਚੀ ਨਹੀਂ। ਹਾਲੀਆ ਦੂਰ-ਪਹੁੰਚ ਘਟਨਾਵਾਂ ਕੱਢੋ ਅਤੇ ਕਾਲ ਕਰਨ ਵਾਲੇ ਦਾ ਪਤਾ, ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਨਤੀਜਾ ਅਤੇ ਚੁਣੇ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਪੜ੍ਹੋ। ਅਯੋਗ ਇੰਟਰਫ਼ੇਸ ਜਾਣ-ਬੁੱਝ ਕੇ ਹਟਾਈ ਸਾਈਟ ਜਾਂ ਪਾਬੰਦੀਸ਼ੁਦਾ ਸਾਥੀ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਲੌਗਇਨ ਗ਼ਲਤੀ ਹਟਦੀ ਹੈ ਕਿ ਨਹੀਂ ਇਹ ਵੇਖਣ ਲਈ ਇਸਨੂੰ ਸਮਰੱਥ ਕਰਨਾ ਰੂਟਿੰਗ ਅਤੇ ਪਹੁੰਚ ਦੇ ਨਤੀਜਿਆਂ ਵਾਲਾ ਸੰਰਚਨਾ ਬਦਲਾਅ ਹੈ, ਇਸ ਲਈ ਫ਼ੈਸਲਾ ਉਸ ਸਾਈਟ ਸੰਬੰਧ ਦੇ ਮਾਲਕ ਰਾਹੀਂ ਭੇਜੋ, ਉਸਦੀ ਮੰਜ਼ਿਲ, ਸੁਰੱਖਿਅਤ ਪ੍ਰੀਫ਼ਿਕਸ ਅਤੇ ਨੀਤੀ ਸਮੇਤ।
ਜੇ ਮੈਪਿੰਗ ਸੱਚਮੁੱਚ ਗ਼ਲਤ ਹੈ, ਤਾਂ ਲੱਛਣ ਨਹੀਂ, ਕੁੰਜੀ ਸੁਧਾਰੋ: ਸਰਟੀਫਿਕੇਟ ਦਾ ਵਿਸ਼ਾ ਜਾਂ ਵਰਤੋਂਕਾਰ ਨਾਮ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਸੁਧਾਰੋ, ਅਤੇ ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਕੁੰਜੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਮੰਜ਼ਿਲ ਸੁਧਾਰੋ। ਫਿਰ ਇੱਕ ਵਾਰ ਦੁਬਾਰਾ ਜੁੜੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਹੀ ਕਾਲ ਕਰਨ ਵਾਲਾ ਹੁਣ ਮਨਜ਼ੂਰ ਵਸਤੂ ਚੁਣ ਰਿਹਾ ਹੈ।
Get-WinEvent -LogName Application -MaxEvents 50 | Where-Object { $_.ProviderName -like '*RemoteAccess*' }ਮਨਜ਼ੂਰ ਕਾਰਵਾਈ ਨਾਲ ਚੱਕਰ ਬੰਦ ਕਰੋ
ਹਰੀ ਸਥਿਤੀ ਸਵੀਕ੍ਰਿਤੀ ਨਹੀਂ ਹੈ। ਸਹੀ ਇੰਟਰਫ਼ੇਸ ਚੁਣੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਡਿਜ਼ਾਈਨ ਜਿਸ ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਉਹ ਪੈਦਾ ਕਰੋ, ਇੱਕ ਸੁਰੱਖਿਅਤ ਪ੍ਰੀਫ਼ਿਕਸ ਦੇ ਹੋਸਟ ਤੋਂ ਦੂਜੇ ਦੇ ਹੋਸਟ ਤੱਕ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਉਸੇ ਰਾਹੀਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਜਿਸ ਹੋਸਟ ਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਉਸ ਤੋਂ ਵੀ ਉਹੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਇਹ ਵਰਤ ਕੇ Test-NetConnection -ComputerName 10.44.2.10 -Port 445 ਡਿਜ਼ਾਈਨ ਜਿਸ ਸੇਵਾ ਨੂੰ ਬਾਹਰ ਰੱਖਦਾ ਹੈ ਉਸ ਵਿਰੁੱਧ, ਅਤੇ ਦੂਰ-ਪਹੁੰਚ ਘਟਨਾਵਾਂ ਦੁਬਾਰਾ ਪੜ੍ਹੋ। ਜੋ ਸਾਈਟ ਲਿੰਕ ਆਪਣੇ ਮਨਜ਼ੂਰ ਪ੍ਰੀਫ਼ਿਕਸਾਂ ਤੋਂ ਵੱਧ ਢੋਂਦੀ ਹੈ, ਜਾਂ ਨੀਤੀ ਜਿਸ ਸੇਵਾ ਨੂੰ ਬਾਹਰ ਰੱਖਦੀ ਹੈ ਉਸਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਉਹ ਰੂਟਿੰਗ ਗ਼ਲਤੀ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਵੀ ਸਥਿਤੀ-ਜਾਂਚ ਉਜਾਗਰ ਨਹੀਂ ਕਰੇਗੀ।
ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ, ਚੋਣ ਕੁੰਜੀ ਅਤੇ ਮਨਜ਼ੂਰ ਪ੍ਰੀਫ਼ਿਕਸ ਇਕੱਠੇ ਸਾਈਟ ਦੀ ਸੰਚਾਲਨ ਪੁਸਤਿਕਾ ਵਿੱਚ ਦਰਜ ਕਰੋ। ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਉਹੀ ਤਿੰਨ-ਮੁੱਲਾਂ ਵਾਲੀ ਸਾਰਣੀ ਮਿਲੇਗੀ, ਅਤੇ ਨਾਮਕਰਨ ਦੀ ਪਰੰਪਰਾ ਦਾ ਅਰਥ ਤਦ ਹੀ ਬਣਦਾ ਹੈ ਜਦੋਂ ਉਹ ਸੰਦਰਭ ਲਿਖਿਆ ਹੋਵੇ।