Nebula punchy ਸੈਟਿੰਗਾਂ: ਕਿਹੜੀ ਤੁਹਾਡਾ NAT ਠੀਕ ਕਰਦੀ ਹੈ

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

ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਐਂਡਪੌਇੰਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਜੋ ਪੀਅਰ ਕਦੇ ਵੀ ਉਮੀਦ ਕੀਤੇ ਪਤੇ ਉੱਤੇ ਨਹੀਂ ਦਿਸਦਾ, ਉਸਨੂੰ punch ਟਿਊਨਿੰਗ ਨਹੀਂ ਬਚਾਏਗੀ। ਦੇਖੋ ਕਿ ਦੀਪਸਤੰਭ ਪੀਅਰ ਬਾਰੇ ਕੀ ਜਾਣਦਾ ਹੈ ਅਤੇ ਪੀਅਰ ਦੀ ਆਪਣੀ ਸੰਰਚਨਾ ਕੀ ਐਲਾਨ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਪੁਰਾਣਾ bootstrap ਪਤਾ ਜਾਂ ਗਲਤੀ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਨਿੱਜੀ ਪਤਾ ਹਰ ਲੰਘਣ ਦੀ ਜੁਗਤ ਨੂੰ ਨਕਾਰਾ ਕਰ ਦਿੰਦਾ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਭਰੋਸੇਯੋਗ ਹੋਣ ਦੀ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲੀ ਪਛਾਣ NAT ਦੇ ਮਹੱਤਵਪੂਰਨ ਹੋਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਗੱਲਬਾਤ ਰੋਕ ਦਿੰਦੀ ਹੈ। ਫਿਰ ਜਾਂਚੋ ਕਿ UDP ਦੀਪਸਤੰਭ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਵੀ ਜਾਂ ਨਹੀਂ। ਸਮੇਂ ਦੇ ਮੁੱਲ ਪਹਿਲਾਂ ਨਹੀਂ, ਸਭ ਤੋਂ ਬਾਅਦ ਦੇਖਣ ਵਾਲੀ ਚੀਜ਼ ਹਨ।

ਤੁਸੀਂ ਜਿਸ ਐਂਡਪੌਇੰਟ ਜੋੜੀ ਨਾਲ ਪਰਖ ਰਹੇ ਹੋ ਉਹ ਲਿਖੋ, ਤਾਂ ਜੋ ਬਾਅਦ ਦੀਆਂ ਤੁਲਨਾਵਾਂ ਦੋ ਹੋਰ ਮਸ਼ੀਨਾਂ ਦੀ ਥਾਂ ਉਹੀ ਪੀਅਰ ਵਰਤਣ।

punch ਮੈਪਿੰਗ ਰੱਖਦਾ ਹੈ, respond ਦਿਸ਼ਾ ਖੋਲ੍ਹਦਾ ਹੈ

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

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

ਦੇਰੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਦੋਂ, ਨਾ ਕਿ ਹੋਵੇਗਾ ਜਾਂ ਨਹੀਂ

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

ਤੰਤਰ ਸਹੀ ਹੋਣ ਤੱਕ ਉਹਨਾਂ ਨੂੰ ਛੱਡ ਦਿਓ। ਫਿਰ ਇੱਕ ਨੂੰ ਸਮਾਯੋਜਿਤ ਕਰੋ, ਅਤੇ ਪੁਰਾਣਾ ਮੁੱਲ ਲਿਖ ਕੇ ਰੱਖੋ।

ਜਦੋਂ ਰਿਲੇ ਹੀ ਇਮਾਨਦਾਰ ਜਵਾਬ ਹੋਵੇ

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

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

ਫੇਲ੍ਹ ਹੋਈ ਜੋੜੀ ਨੂੰ ਨਿਸ਼ਕਿਰਿਆ ਰਹਿਣ ਤੋਂ ਬਾਅਦ ਪਰਖੋ

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

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