ਦੂਜੀ WAN VPN ਐਂਟਰੀ ਫੇਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕਿ ਮੁੱਖ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ

ਮੁੱਖ ਟਨਲ ਚਾਲੂ ਰਹਿੰਦੀ ਹੈ, ਵਰਤੋਂਕਾਰ ਕੰਮ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਕੁਝ ਵੀ ਬਦਲੋ ਦੂਜਾ ISP ਸਰਕਟ ਵਿਹਲਾ ਪਿਆ ਰਹਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਬੈਕਅਪ ਸਰਕਟ ਲਈ ਪਤਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ, ਉਸ ਵੱਲ ਇੱਕ ਨਾਮ ਦਿਸ਼ਾ ਦਿੱਤੀ, ਸ਼ਾਇਦ ਕਲਾਇੰਟ ਵਿੱਚ ਬੈਕਅਪ ਐਂਟਰੀ ਜੋੜੀ, ਅਤੇ ਕਲਾਇੰਟ ਜਾਂ ਤਾਂ ਇਸਨੂੰ ਕਦੇ ਅਜ਼ਮਾਉਂਦਾ ਹੀ ਨਹੀਂ ਜਾਂ ਪ੍ਰਮਾਣਿਤ ਹੋ ਕੇ ਫਿਰ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ। ਮੈਂ ਜਿਨ੍ਹਾਂ ਮਾਮਲਿਆਂ ਦੀ ਪੜਤਾਲ ਕੀਤੀ, ਉਨ੍ਹਾਂ ਵਿੱਚ ਫੇਲਓਵਰ ਵਿਸ਼ੇਸ਼ਤਾ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਸੀ; ਉਹ ਗੁੰਮ ਸੀ ਜੋ ਐਂਟਰੀ ਨੂੰ ਵਰਤਣਯੋਗ ਬਣਾਉਣ ਵਾਲੀਆਂ ਪੰਜ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਨਾਮ ਬੈਕਅਪ ਪਤੇ 'ਤੇ ਰਿਜ਼ੋਲਵ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਉਸ ਇੰਟਰਫੇਸ 'ਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਸੁਣ ਰਿਹਾ, ਅਤੇ ਲਿਸਨਰ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਜਵਾਬ ਮੁੱਖ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ। ਹਰ WAN ਨੂੰ ਆਪਣੇ ਕਰਾਰ ਵਾਲੀ ਵੱਖਰੀ ਐਂਟਰੀ ਮੰਨੋ, ਫਿਰ ਫੇਲ ਹੋਣਾ ਕਲਾਇੰਟ ਦੀ ਬੱਗ ਵਾਂਗ ਨਹੀਂ ਲੱਗਦਾ।

ਹਰ WAN ਨੂੰ ਆਪਣਾ ਐਂਟਰੀ ਕਰਾਰ ਚਾਹੀਦਾ ਹੈ

ਹਰ WAN ਲਈ ਪੰਜ ਖੇਤਰ ਦਰਜ ਕਰੋ: ਜਨਤਕ ਨਾਮ ਅਤੇ ਪਤਾ, ਟਰਾਂਸਪੋਰਟ ਅਤੇ ਪੋਰਟ, ਉਹ ਇੰਟਰਫੇਸ ਜਾਂ ਸੰਦਰਭ ਜੋ ਇਸਨੂੰ ਸਮਾਪਤ ਕਰਦਾ ਹੈ, ਉਹ ਪੀਅਰ ਪਛਾਣ ਜੋ ਇਸਨੂੰ ਪੇਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਜਵਾਬ ਕਿੱਥੋਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ। ਦੋ ਸਰਕਟ ਮਤਲਬ ਦੋ ਪੂਰੇ ਸੈੱਟ। ਜੇ ਦੂਜੇ ਸੈੱਟ ਵਿੱਚ ਸਮਾਪਤ ਕਰਨ ਵਾਲਾ ਇੰਟਰਫੇਸ ਨਹੀਂ ਜਾਂ ਵਾਪਸੀ ਦਾ ਰਾਹ ਨਹੀਂ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਬੈਕਅਪ ਐਂਟਰੀ ਨਹੀਂ ਹੈ; ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਇਰਾਦੇ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲਾ DNS ਰਿਕਾਰਡ ਹੈ।

ਉਪਕਰਨ ਅਤੇ ਇਸਦਾ ਰੀਲੀਜ਼ ਵੀ ਇਸ ਪ੍ਰਬੰਧ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। DNS ਰਿਕਾਰਡ ਦੂਜੇ ਇੰਟਰਫੇਸ 'ਤੇ ਸੇਵਾ ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਦਾ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਲਿਸਨਰ ਡਿਵਾਈਸ ਦੇ ਬਜਾਏ ਪਤੇ ਅਨੁਸਾਰ ਸੰਰਚਿਤ ਹੁੰਦਾ ਹੈ। ASA 'ਤੇ ਇੰਟਰਫੇਸ-ਅਧਾਰਿਤ IPsec ਕ੍ਰਿਪਟੋ ਮੈਪ ਅਤੇ ਟਨਲ ਗਰੁੱਪ ਨੂੰ ਬਾਹਰੀ ਇੰਟਰਫੇਸ ਨਾਲ ਬੰਨ੍ਹਦਾ ਹੈ, ਇਸ ਲਈ ਦੂਜੀ ਅਪਲਿੰਕ ਨੂੰ ਉਸ ਥਾਂ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ ਜਿੱਥੇ ਉਹ ਪੈਕਟ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚਦੇ ਹਨ। ਰੂਟ-ਅਧਾਰਿਤ ਡਿਜ਼ਾਈਨ ਵੱਖਰੇ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ: ਲਿਸਨਰ ਹਰ ਪਤੇ 'ਤੇ ਜਾਂ ਇੱਕ ਨਾਮਿਤ ਪਤੇ 'ਤੇ ਬਾਈਂਡ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹ ਚੋਣ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ISP B ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਜਾਂਚੋ ਕਿ ਦੂਜਾ WAN ਸੱਚਮੁੱਚ ਜਵਾਬ ਦਿੰਦਾ ਹੈ

ਦੋਵੇਂ ਸਰਕਟਾਂ ਦੇ ਬਾਹਰੋਂ ਟੈਸਟ ਕਰੋ, ਗੇਟਵੇ ਪਿੱਛੇ ਦੀ ਮਸ਼ੀਨ ਤੋਂ ਨਹੀਂ, ਅਤੇ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਵਰਤਦਾ ਠੀਕ ਨਾਮ ਟੈਸਟ ਕਰੋ। TLS ਲਿਸਨਰ ਲਈ ਤੇਜ਼ ਜਾਂਚ openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts ਹੈ ਜੋ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਹਰਲੇ ਹੋਸਟ ਤੋਂ ਚਲਾਈ ਜਾਂਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਪੂਰਾ ਹੋਇਆ ਹੈਂਡਸ਼ੇਕ ਚਾਹੀਦਾ ਹੈ ਜਿਸਦੀ ਚੇਨ ਪ੍ਰੋਫਾਈਲ ਦੇ ਨਾਮ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਸਿਰਫ਼ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ TCP ਪੋਰਟ ਨਹੀਂ।

RFC 9525 ਦੱਸਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕੀ ਜਾਂਚ ਰਿਹਾ ਹੈ: ਉਹ ਪਛਾਣ ਜਿਸ ਤੱਕ ਪਹੁੰਚਣਾ ਸੀ, ਸੇਵਾ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਤੁਲਨਾ ਕੀਤੀ। ਮੁੱਖ ਐਂਟਰੀ ਦਾ ਸਰਟੀਫਿਕੇਟ ਵਾਪਸ ਦੇਣ ਵਾਲੀ ਦੂਜੀ ਐਂਟਰੀ, ਜਾਂ ਅਜਿਹਾ ਡਿਫਾਲਟ ਸਰਟੀਫਿਕੇਟ ਜੋ ਦੋਵਾਂ ਨਾਮਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ ਦਰਸਾਉਂਦਾ, ਪੋਰਟ ਖੁੱਲ੍ਹਾ ਅਤੇ ਫਾਇਰਵਾਲ ਮਨਜ਼ੂਰੀ ਦੇਣ ਦੇ ਬਾਵਜੂਦ ਇਸ ਟੈਸਟ ਵਿੱਚ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ।

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

ਜਵਾਬ ਦਾ ਪਿੱਛਾ ਕਰੋ, ਸਿਰਫ਼ ਬੇਨਤੀ ਦਾ ਨਹੀਂ

ਦੂਜਾ WAN ਆਮ ਤੌਰ 'ਤੇ ਵਾਪਸੀ ਦੇ ਰਾਹ 'ਤੇ ਟੁੱਟਦਾ ਹੈ। ਬੇਨਤੀ ISP B 'ਤੇ ਆਉਂਦੀ ਹੈ, ਉਪਕਰਨ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ISP A ਦੇ ਡਿਫਾਲਟ ਰੂਟ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ, ਅਜਿਹੇ ਸਰੋਤ ਪਤੇ ਨਾਲ ਜੋ ਕਲਾਇੰਟ ਨੇ ਕਦੇ ਨਹੀਂ ਮੰਗਿਆ। ਸਟੇਟਫੁਲ ਅਨੁਵਾਦ ਇਸਨੂੰ ਹੋਰ ਵਿਗਾੜਦਾ ਹੈ: ਜੇ ਮੈਪਿੰਗ ਮੁੱਖ ਇੰਟਰਫੇਸ ਲਈ ਬਣੀ ਸੀ, ਤਾਂ ਵਾਪਸ ਆਉਂਦਾ ਪੈਕਟ ਅਨੁਵਾਦ ਖੁੰਝਾ ਦਿੰਦਾ ਹੈ ਜਾਂ ਅਜਿਹਾ ਸਰੋਤ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਦਾ ਫਾਇਰਵਾਲ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਪ੍ਰਦਾਤਾ ਉਹ ਸਰੋਤ ਪਤੇ ਵੀ ਸੁੱਟ ਦਿੰਦੇ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਦਿੱਤੇ ਸਰਕਟ ਦੇ ਨਹੀਂ ਹਨ, ਇਸੇ ਲਈ ਇਹ ਸਾਫ਼ ਪ੍ਰੋਟੋਕੋਲ ਗਲਤੀ ਦੇ ਬਜਾਏ ਇੱਕ-ਤਰਫ਼ਾ ਬਲੈਕ ਹੋਲ ਵਾਂਗ ਦਿਸਦਾ ਹੈ।

ਦੂਜੀ ਐਂਟਰੀ ਤੋਂ ਸਰੋਤ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਲਈ ਰੂਟਿੰਗ ਫੈਸਲਾ ਜਾਂਚੋ। ਜਵਾਬ ਉਸ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੋਂ ਬੇਨਤੀ ਆਈ, ਜਾਂ ਘੱਟੋ-ਘੱਟ ਅਜਿਹਾ ਪਤਾ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸਨੂੰ ਦੂਰ ਦਾ ਪਾਸਾ ਉਸ ਰਾਹ ਦਾ ਹਿੱਸਾ ਮੰਨ ਕੇ ਸਵੀਕਾਰ ਕਰੇ। ਨੀਤੀ-ਰੂਟਿੰਗ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਆਉਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਜਾਂ ਅਨੁਵਾਦਿਤ ਸਰੋਤ 'ਤੇ ਬਣਿਆ ਨਿਯਮ, ਨਾਲ ਹੀ ਹਰ ਬਾਹਰੀ ਇੰਟਰਫੇਸ ਨਾਲ ਬੱਝਾ ਅਨੁਵਾਦ ਬਿਆਨ। ਕਲਾਇੰਟ ਜੁੜਦੇ ਸਮੇਂ ਦੋਵੇਂ ਇੰਟਰਫੇਸਾਂ 'ਤੇ ਇਕੱਠੇ ਕੈਪਚਰ ਕਰੋ; ISP B 'ਤੇ ਆਉਂਦਾ SYN ਅਤੇ ISP A 'ਤੇ ਬਾਹਰ ਜਾਂਦਾ SYN-ACK ਇੱਕੋ ਦੌੜ ਵਿੱਚ ਸਵਾਲ ਖ਼ਤਮ ਕਰ ਦਿੰਦੇ ਹਨ।

ਕਲਾਇੰਟ ਨੂੰ ਦੂਜੀ ਐਂਟਰੀ ਬਾਰੇ ਜਾਣਨ ਦਾ ਤਰੀਕਾ ਦਿਓ

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

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

ਦੋ ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ ਇੱਕੋ ਪਤਾ ਵੱਖਰਾ ਉਤਪਾਦ ਹੈ

ਇੱਕੋ ਜਨਤਕ ਪਤਾ ਦੋਵੇਂ ਸਰਕਟਾਂ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਰੱਖਣਾ ਰੂਟਿੰਗ ਸੇਵਾ ਹੈ, VPN 'ਤੇ ਚੈਕਬਾਕਸ ਨਹੀਂ। ਇਸਨੂੰ ਅਜਿਹੀ ਪਤਾ ਥਾਂ ਚਾਹੀਦੀ ਹੈ ਜੋ ਦੋਵੇਂ ਪ੍ਰਦਾਤਾ ਲੈ ਕੇ ਜਾਣ ਨੂੰ ਤਿਆਰ ਹੋਣ, ਉਨ੍ਹਾਂ ਦੇ ਨੈੱਟਵਰਕ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੇ ਢੰਗ ਨਾਲ ਐਲਾਨੀ ਗਈ, ਜੋ ਪ੍ਰਦਾਤਾ-ਸੁਤੰਤਰ ਥਾਂ ਅਤੇ BGP ਵਾਲੀ ਮਲਟੀਹੋਮਿੰਗ ਦਿੰਦੀ ਹੈ। ISP A ਦਾ ਪਤਾ ISP B ਦੇ ਇੰਟਰਫੇਸ 'ਤੇ ਦੇਣ ਨਾਲ ਤੁਸੀਂ ਉੱਥੇ ਨਹੀਂ ਪਹੁੰਚਦੇ; ਪੈਕਟ ਉਸ ਨੈੱਟਵਰਕ 'ਤੇ ਪਹੁੰਚਦਾ ਹੈ ਜਿਸਨੇ ਉਹ ਪ੍ਰੀਫਿਕਸ ਕਦੇ ਐਲਾਨਿਆ ਹੀ ਨਹੀਂ ਸੀ ਅਤੇ ਅੱਪਸਟ੍ਰੀਮ ਵਿੱਚ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

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

ਅੱਗੇ ਕੀ ਜਾਂਚਣਾ ਹੈ

ਫੇਲ ਹੋਈ ਐਂਟਰੀ ਤੋਂ ਬਾਹਰ ਵੱਲ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਕੰਮ ਕਰੋ: ਕੀ ਦੂਜਾ ਪਤਾ ਬਾਹਰੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਕੀ ਇਹ ਉਹ ਪਛਾਣ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਕੀ ਜਵਾਬ ਉਸੇ ਰਾਹ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਜਿਸ ਰਾਹ ਬੇਨਤੀ ਆਈ ਸੀ, ਅਤੇ ਕੀ ਕਲਾਇੰਟ ਲੋੜ ਪੈਣ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮ ਜਾਣ ਸਕਦਾ ਹੈ। ਜਿੱਥੇ ਜਵਾਬ ਨਾਂਹ ਹੈ, ਉਹ ਪਰਤ ਠੀਕ ਕਰੋ ਅਤੇ ਟੈਸਟ ਹੋਸਟ ਦੇ ਬਜਾਏ ਤੈਨਾਤ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ, ਕਿਉਂਕਿ ਲੈਬ ਦਾ ਹੈਂਡਸ਼ੇਕ ਅਸਲ ਕਲਾਇੰਟ ਦੇ ਪੂਰੇ ਕਨੈਕਸ਼ਨ ਤੋਂ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ।

ਹਰ WAN ਲਈ ਪਤਾ, ਪੋਰਟ, ਸਮਾਪਤ ਕਰਨ ਵਾਲਾ ਇੰਟਰਫੇਸ, ਸਰਟੀਫਿਕੇਟ ਨਾਮ, ਵਾਪਸੀ ਰਾਹ ਅਤੇ ਅਨੁਵਾਦ ਨਿਯਮ ਵਾਲਾ ਛੋਟਾ ਰਿਕਾਰਡ ਰੱਖੋ, ਅਤੇ ਜਦੋਂ ਵੀ ਸਰਕਟ, NAT ਡਿਵਾਈਸ ਜਾਂ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਬਦਲੇ ਤਾਂ ਦੁਬਾਰਾ ਜਾਂਚੋ। ਵਿਹਲੇ ਬੈਕਅਪ ਰਾਹ ਚੁੱਪਚਾਪ ਗਲਦੇ ਹਨ: ਕਿਸੇ ਦੁਆਰਾ ਨਾ ਵਰਤੀ ਗਈ ਐਂਟਰੀ ਬਾਰੇ ਕੋਈ ਚੇਤਾਵਨੀ ਨਹੀਂ ਆਉਂਦੀ, ਜਿਸ ਦਿਨ ਸਾਰੇ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ ਉਸ ਦਿਨ ਤੱਕ।