VPN ਅੰਤ ਬਿੰਦੂਆਂ ਦੀ ਇਜਾਜ਼ਤ ਸੂਚੀ: ਉਹ DNS ਰਿਫ਼੍ਰੈਸ਼ ਜੋ ਤੁਸੀਂ ਭੁੱਲ ਗਏ

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

ਨਿਯਮ ਵਿੱਚ ਹੋਸਟਨਾਮ ਜੀਵਤ ਸਦੱਸਤਾ ਨਹੀਂ ਹੈ

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

ਸਹੀ ਹੋਸਟ ਦਾ ਨਾਮ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਵੀ ਗਲਤ ਪਤੇ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਸਕਦਾ ਹੈ। ਉਹ ਵਿਰਾਮ ਕਥਾ ਹੈ, ਸ਼ਬਦ-ਜੋੜ ਦੀ ਗਲਤੀ ਨਹੀਂ।

ਕੈਸ਼ TTL ਤੁਹਾਡੇ ਫਾਇਰਵਾਲ ਦਾ ਟਾਈਮਰ ਨਹੀਂ ਹੈ

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

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

dig +short vpn.example.com
resolvectl query vpn.example.com

ਰਿਫ਼੍ਰੈਸ਼ ਅਤੇ ਅਸਫਲਤਾ ਨੂੰ ਇੱਕ ਨੀਤੀ ਵਜੋਂ ਡਿਜ਼ਾਈਨ ਕਰੋ

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

ਅਸਫਲਤਾ ਦਾ ਵਿਵਹਾਰ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣੋ। ਪੁਰਾਣਾ ਪਤਾ ਰੱਖਣਾ ਸੈਸ਼ਨ ਬਚਾ ਸਕਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣੀ ਇਜਾਜ਼ਤ ਛੱਡ ਸਕਦਾ ਹੈ; ਸੈੱਟ ਖਾਲੀ ਕਰਨਾ ਰਿਕਵਰੀ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਸਫਲ ਖੋਜ ਦਾ ਸੰਜੋਗਿਕ ਨਤੀਜਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਚੁਣਿਆ ਵਿਵਹਾਰ ਰਨਬੁੱਕ ਵਿੱਚ ਲਿਖੋ ਤਾਂ ਜੋ ਅਗਲਾ ਓਪਰੇਟਰ ਦਬਾਅ ਹੇਠ ਤੁਰੰਤ ਫੈਸਲਾ ਨਾ ਕਰੇ।

ਬੂਟਸਟ੍ਰੈਪ DNS ਨੂੰ ਵੀ ਤੰਗ ਰੱਖੋ। ਜਨਤਕ ਰਿਜ਼ੌਲਵਰ ਲਈ ਬਿਨਾਂ ਸ਼ਰਤ ਛੋਟ ਜੋ ਵੀ ਮੇਲ ਖਾਂਦਾ ਹੈ ਉਸ ਲਈ ਸਿੱਧਾ DNS ਮਾਰਗ ਹੈ, ਸਿਰਫ਼ ਅੰਤ ਬਿੰਦੂ ਦੇ ਨਾਮ ਲਈ ਨਹੀਂ।

ਅੰਤ ਬਿੰਦੂ ਬਦਲਾਅ ਸਾਬਤ ਕਰੋ, ਪਹਿਲਾ ਕਨੈਕਸ਼ਨ ਨਹੀਂ

ਕਲਾਇੰਟ ਦੇ ਸਮਰਥਿਤ ਮੈਨੇਜਰ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੇ ਇਹ ਪਹਿਲਾਂ ਹੀ ਹੱਲ ਅਤੇ ਬਲਾਕਿੰਗ ਦਾ ਤਾਲਮੇਲ ਕਰਦਾ ਹੈ। ਸਾਈਟ-ਪ੍ਰਬੰਧਿਤ PF ਹੋਸਟ ਉੱਤੇ, ਵੱਖਰੇ ਜੀਵਨ ਚੱਕਰ ਵਿਵਹਾਰ ਵਾਲੇ ਹੋਰ ਪਲੇਟਫਾਰਮ ਤੋਂ ਹੋਸਟਨਾਮ-ਟੇਬਲ ਸਿੰਟੈਕਸ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ ਸਾਈਟ ਦੀ ਮਾਲਕੀ ਅਤੇ ਰਿਕਵਰੀ ਯੋਜਨਾ ਰੱਖੋ।

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