VPN ਸਾਈਡਕਾਰ ਲਈ ਕਿੱਲ ਸਵਿੱਚ: ਬਾਹਰ ਨਿਕਲਣ ਵੇਲੇ ਟਰੈਫਿਕ ਰੋਕੋ

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

ਨੇਮਸਪੇਸ ਸਾਂਝਾ ਕਰਨਾ ਕਿੱਲ ਸਵਿੱਚ ਕਿਉਂ ਨਹੀਂ

ਨੇਮਸਪੇਸ ਸਾਂਝਾ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਐਪ VPN ਕੰਟੇਨਰ ਦੇ ਇੰਟਰਫ਼ੇਸ, ਪਤੇ ਅਤੇ ਰੂਟ ਸਾਰਣੀ ਵਰਤਦਾ ਹੈ। ਇਹ ਸਾਂਝੇ ਨੇਮਸਪੇਸ ਦੇ ਸੁਰੱਖਿਅਤ ਰਹਿਣ ਤੱਕ ਐਪ ਦਾ ਨੈੱਟਵਰਕ ਤੱਕ ਆਜ਼ਾਦ ਰਾਹ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਟਨਲ ਦੇ ਜਾਣ 'ਤੇ ਉਹ ਨੇਮਸਪੇਸ ਕੀ ਕਰੇਗਾ।

Compose ਦੀਆਂ ਨਿਰਭਰਤਾ ਸ਼ਰਤਾਂ ਐਪ ਦੀ ਸ਼ੁਰੂਆਤ ਨੂੰ ਉਦੋਂ ਤੱਕ ਦੇਰ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਦੋਂ ਤੱਕ ਕੋਈ ਨਿਰਭਰਤਾ ਸਿਹਤਮੰਦ ਨਾ ਹੋ ਜਾਵੇ। ਇਹ ਸਮੇਂ ਦੇ ਇੱਕ ਪਲ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਬਾਅਦ ਦੀ ਫੇਲ੍ਹਤਾ ਨੂੰ ਨਹੀਂ, ਇਸ ਲਈ ਇਹ ਸ਼ੁਰੂਆਤੀ ਕ੍ਰਮ ਦਾ ਸੰਦ ਹੈ, ਲਗਾਤਾਰ ਐਗਰੈਸ ਫਾਇਰਵਾਲ ਨਹੀਂ।

ਕੰਟੇਨਰ ਦੇ ਬਾਹਰ ਨਿਕਲਣ 'ਤੇ ਅਸਲ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ

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

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

ਸਪਸ਼ਟ ਐਗਰੈਸ ਨੀਤੀ ਬਣਾਓ

ਨੀਤੀ ਸਾਂਝੇ ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰ ਲਿਖੋ ਤਾਂ ਜੋ ਇਹ ਐਪ ਦੇ ਪੈਕਟਾਂ 'ਤੇ ਲਾਗੂ ਹੋਵੇ। ਰੂਪ ਸੰਕੀਰਣ ਅਪਵਾਦਾਂ ਨਾਲ ਡਿਫ਼ਾਲਟ ਛੱਡਣਾ ਹੈ: loopback, ਟਨਲ ਦਾ ਇੰਟਰਫ਼ੇਸ, ਅਤੇ ਉਹ ਖ਼ਾਸ ਐਂਡਪੁਆਇੰਟ ਪਤਾ ਤੇ ਪੋਰਟ ਜੋ ਟਨਲ ਟਰਾਂਸਪੋਰਟ ਨੂੰ ਲੋੜੀਂਦਾ ਹੈ।

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

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

ਜੀਵਨ ਚੱਕਰ ਜਾਂਚੋ, ਸਿਰਫ਼ ਡਿਸਕਨੈਕਟ ਨਹੀਂ

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

ਰੋਕਣ ਦੀ ਵਿਧੀ ਵਜੋਂ ਸਿਹਤ ਜਾਂਚ ਜਾਂ ਐਗਰੈਸ IP ਖੋਜ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ। ਜਾਂਚ ਹਾਲਤ ਦੇਖਦੀ ਹੈ ਅਤੇ ਉਸ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ; ਨੀਤੀ ਟਰੈਫਿਕ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ ਇੱਕੋ ਤੈਨਾਤੀ ਦੇ ਹਿੱਸੇ ਹਨ, ਅਤੇ ਉਹ ਇੱਕ ਦੂਜੇ ਦੇ ਬਦਲ ਨਹੀਂ।

ਨਿਯਮ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਜਾਂਚ ਕਿਸੇ ਅੱਪਡੇਟ ਤੋਂ ਬਚ ਜਾਵੇ

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

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