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

ਨਿਯਮ ਕੀ ਪਿੰਨ ਕਰਦਾ ਹੈ ਅਤੇ DNS ਕੀ ਵਾਪਸ ਕਰਦਾ ਹੈ

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

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

ਮੇਲ ਟੁੱਟਣ ਦੇ ਤਿੰਨ ਤਰੀਕੇ

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

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

ਐਪ ਅਸਲ ਵਿੱਚ ਜੋ ਮੰਜ਼ਿਲ ਵਰਤਦੀ ਹੈ ਉਹ ਪੜ੍ਹੋ

ਬ੍ਰਾਊਜ਼ਰ ਟੈਬ ਨਹੀਂ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਤੇ socket ਸਾਰਣੀ ਨੂੰ ਪੁੱਛੋ। ਖੋਜ ਦੱਸਦੀ ਹੈ ਕਿ ਨਾਮ ਹੁਣ ਕੀ ਬਣਦਾ ਹੈ, ਅਤੇ socket ਸਾਰਣੀ ਉਹ ਪਤਾ ਦਿਖਾਉਂਦੀ ਹੈ ਜਿਸ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਜੁੜੀ ਹੋਈ ਹੈ, ਜੋ ਪੁਰਾਣਾ ਹੋ ਸਕਦਾ ਹੈ। ਸਿਧਾਂਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਚਲਾਓ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਲਗਭਗ ਅੱਧੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਆਪ ਹੀ ਜਵਾਬ ਹੈ।

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

ਲੱਖਣ ਨਹੀਂ, ਮਕੈਨਿਜ਼ਮ ਦੀ ਮੁਰੰਮਤ ਕਰੋ

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

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

ਸਿਰਫ ਛੋਟੀ ਜਾਂਚ ਦੌਰਾਨ ਦੇਖੇ ਹਰ ਪਤੇ ਨੂੰ ਫੜਨ ਲਈ ਅਪਵਾਦ ਨੂੰ ਵੱਡੇ ਗੁਆਂਢੀ ਨੈੱਟਵਰਕ ਤੱਕ ਨਾ ਫੈਲਾਓ। ਇਹ ਮੁਰੰਮਤ ਨਹੀਂ ਹੈ; ਇਹ ਸੁਰੱਖਿਆ ਸੀਮਾ ਵਿੱਚ ਪਾਇਦਾ ਬਦਲਾਅ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੱਕ ਨਿਯਮ ਮੌਜੂਦ ਹੈ ਇਹ ਅਸੰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਨੂੰ ਚੁੱਪਚਾਪ ਟਨਲ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੇਵੇਗਾ।

ਇਰਾਦੇ ਦੇ ਦੋਵੇਂ ਅੱਧੇ ਹਿੱਸੇ ਜਾਂਚੋ

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

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

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

ਸੰਬੰਧਿਤ ਲੇਖ