ਸਥਿਰ VPN IP: RADIUS Framed-IP-Address ਜਾਂ ਪੂਲ ਰਿਜ਼ਰਵੇਸ਼ਨ

VPN ਕਲਾਇੰਟ ਲਈ ਸਥਿਰ ਅੰਦਰੂਨੀ ਪਤਾ ਤਿੰਨ ਥਾਵਾਂ ’ਤੇ ਰਹਿ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਦੀ ਹੀ ਇਸ ’ਤੇ ਮਾਲਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। RADIUS ਪਤਾ Access-Accept ਵਿੱਚ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ, ਗੇਟਵੇ ਖਾਤੇ ਲਈ ਸਥਿਰ ਮੈਪਿੰਗ ਰੱਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਐਡਾਪਟਰ ਹੱਥ ਨਾਲ ਸੈੱਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਪਹਿਲੇ ਦੋ ਨੀਤੀ ਹਨ ਅਤੇ ਤੀਜਾ ਸਥਾਨਕ ਅੰਦਾਜ਼ਾ ਹੈ ਜਿਸ ਨੂੰ ਗੇਟਵੇ ਅਣਡਿੱਠਾ ਜਾਂ ਉੱਪਰ ਲਿਖ ਸਕਦਾ ਹੈ। ਪਹਿਲੇ ਦੋ ਵਿੱਚੋਂ ਚੋਣ ਕਰਨਾ ਅਸਲ ਫ਼ੈਸਲਾ ਹੈ, ਅਤੇ ਇਹ ਇਸ ਗੱਲ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਐਕਸੈਸ ਸਰਵਰ ਅਸਲ ਵਿੱਚ ਕੀ ਲਾਗੂ ਕਰਦਾ ਹੈ।

ਤਿੰਨ ਥਾਵਾਂ ਜਿੱਥੇ ਸਥਿਰ ਪਤਾ ਹੋ ਸਕਦਾ ਹੈ

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

ਦੋ ਮਾਲਕ ਹੀ ਟੁੱਟਣ ਵਾਲੀ ਸੰਰਚਨਾ ਹੈ। RADIUS ਜਵਾਬ 172.28.4.77 ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਜਦਕਿ ਗੇਟਵੇ 172.28.4.90 ਲਈ ਸਥਿਰ ਮੈਪਿੰਗ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਉਹ ਮੁੱਲ ਮਿਲਦਾ ਹੈ ਜਿਸ ਨੂੰ ਵਿਕਰੇਤਾ ਦਾ ਕੋਡ ਪਹਿਲਾਂ ਜਾਂਚਦਾ ਹੈ, ਅਤੇ ਹਾਰਨ ਵਾਲਾ ਲੌਗ ਲਾਈਨ ਤੋਂ ਬਿਨਾਂ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਉਹੀ ਖਾਤਾ ਦੂਜੇ ਡਿਵਾਈਸ ’ਤੇ ਨਕਲੀ ਪਤਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਲੱਛਣ ਨਿਰਧਾਰਨ ਟਕਰਾਅ ਨਹੀਂ ਸਗੋਂ ਰਾਊਟਿੰਗ ਖਰਾਬੀ ਵਜੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਦੂਜੀ ਵਿਵਸਥਾ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕ ਤੈਅ ਕਰੋ।

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

RADIUS ਜਵਾਬ ਕੀ ਵਾਅਦਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

RFC 2865Framed-IP-Address ਨੂੰ ਉਸ IPv4 ਪਤੇ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਵਰਤੋਂਕਾਰ ਲਈ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ, ਅਤੇ ਇਹ Access-Accept ਵਿੱਚ ਆਉਂਦਾ ਹੈ। Access-Request ਵਿੱਚ ਉਹੀ ਵਿਸ਼ੇਸ਼ਤਾ ਸਿਰਫ਼ ਇੱਕ ਸੰਕੇਤ ਹੈ ਜਿਸ ਨੂੰ ਸਰਵਰ ਅਣਡਿੱਠਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਤਦ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ ਕਲਾਇੰਟ ਜਾਂ ਗੇਟਵੇ ਪਸੰਦੀਦਾ ਪਤਾ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਕੁਝ ਵੀ ਗੇਟਵੇ ਨੂੰ ਜਵਾਬ ਦਾ ਸਤਿਕਾਰ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਐਕਸੈਸ ਸਰਵਰ ਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਇਸ ਨੂੰ ਸੈਸ਼ਨ ’ਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ।

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

ਗੇਟਵੇ ਜਿਸ ਜਵਾਬ ਨੂੰ ਅਣਡਿੱਠਾ ਕਰਦਾ ਹੈ ਉਹ ਬਿਲਕੁਲ ਉਸ ਜਵਾਬ ਵਰਗਾ ਦਿਖਦਾ ਹੈ ਜੋ ਕਦੇ ਭੇਜਿਆ ਨਹੀਂ ਗਿਆ। Access-Accept ਅਤੇ ਸੈਸ਼ਨ ਦੇ ਪਤੇ ਨੂੰ ਨਾਲ-ਨਾਲ ਪੜ੍ਹਨਾ ਹੀ ਦੋਵਾਂ ਸਥਿਤੀਆਂ ਨੂੰ ਵੱਖ ਕਰਨ ਦਾ ਇੱਕੋ ਤਰੀਕਾ ਹੈ।

ਪਤੇ ਨੂੰ ਉਸ ਪੂਲ ਦੇ ਅੰਦਰ ਰਿਜ਼ਰਵ ਕਰੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਰਾਊਟ ਕਰਦੇ ਹੋ

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

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

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

ਰਿਜ਼ਰਵੇਸ਼ਨ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਦੀ ਜਾਂਚ ਕਰੋ

AAA ਪਾਸੇ ਅਤੇ ਸੈਸ਼ਨ ਪਾਸੇ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੇ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਸਥਾਨਕ radtest ਗੇਟਵੇ ਨੂੰ ਸ਼ਾਮਲ ਕੀਤੇ ਬਿਨਾਂ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸਰਵਰ ਖਾਤੇ ਲਈ ਕੀ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਰਤੋਂਕਾਰ ਫ਼ਾਈਲ ਦੀ ਐਂਟਰੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਸਰਵਰ ਨੂੰ ਕਿਸ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਕਲਾਇੰਟ ਨੂੰ ਮੁੜ ਜੋੜੋ ਅਤੇ ਮਿਲੇ ਪਤੇ ਦੀ ਤੁਲਨਾ ਜਵਾਬ ਵਿੱਚਲੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਾਲ ਕਰੋ।

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

ਵਿਸ਼ੇਸ਼ਤਾ ਤੋਂ ਬਿਨਾਂ Access-Accept ਦਾ ਅਰਥ ਹੈ ਕਿ ਸਰਵਰ ਨੇ ਐਂਟਰੀ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਧਾ ਜਾਂ ਉਸ ਵਰਤੋਂਕਾਰ ’ਤੇ ਵਿਸ਼ੇਸ਼ਤਾ ਲਾਗੂ ਨਹੀਂ ਹੋਈ। ਵਿਸ਼ੇਸ਼ਤਾ ਵਾਲਾ Access-Accept ਅਤੇ ਅਜੇ ਵੀ ਪੂਲ ਪਤਾ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਦਾ ਅਰਥ ਹੈ ਕਿ ਗੇਟਵੇ ਨੇ ਇਸ ਨੂੰ ਅਣਡਿੱਠਾ ਕੀਤਾ। Access-Reject ਤੁਹਾਨੂੰ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਜਾਂ ਸਮੂਹ ਨੀਤੀ ਵੱਲ ਵਾਪਸ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਤੀਜਾ ਕਲਾਇੰਟ ਐਡਾਪਟਰ ਸੋਧ ਕੇ ਡੀਬੱਗ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।

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

ਇੱਕ ਮਾਲਕ ਚੁਣੋ ਅਤੇ ਉਸ ਨੂੰ ਲਿਖੋ

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

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