ਇੱਕੋ ਖਰਚ ਵਾਲੇ ਰੂਟ VPN ਦੀਆਂ ਖਰਾਬੀਆਂ ਨੂੰ ਵੇਖਣਾ ਔਖਾ ਕਿਉਂ ਬਣਾਉਂਦੇ ਹਨ
ਜਦੋਂ ਕਈ ਟਨਲ ਇੱਕੋ ਖਰਚ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਹਰ ਫਲੋ ਵੱਖਰਾ ਚੁਣ ਸਕਦਾ ਹੈ। ਸਫਲ ping ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਰਾਹ ਵਰਤਦੀ ਹੈ।
ਇੱਕ ਵਰਤੋਂਕਾਰ ਦੱਸਦਾ ਹੈ ਕਿ ਅੰਦਰੂਨੀ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਮਸ਼ੀਨ ਤੋਂ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਦੂਜੀ ਤੋਂ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਗੇਟਵੇ ਤੋਂ ਚਲਾਇਆ ping ਦੋਵਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਸਫਲ ਹੁੰਦਾ ਹੈ। ਇੱਕੋ ਖਰਚ ਵਾਲੇ ਕਈ ਟਨਲ ਹੋਣ ’ਤੇ ਇਹ ਵਿਰੋਧਾਭਾਸ ਨਹੀਂ। ਹਰ ਫਲੋ ਆਪਣੇ ਅਗਲੇ ਹਾਪ ’ਤੇ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਡੀ ਜਾਂਚ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦਾ ਸੈਸ਼ਨ ਵੱਖਰੇ ਰਾਹ ਵਰਤ ਰਹੇ ਹੋ ਸਕਦੇ ਹਨ। ਹੇਠਾਂ ਦਿੱਤਾ ਵੇਰਵਾ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹੀ ਚੋਣ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਇੱਕ ping, ਕਈ ਸੰਭਾਵਿਤ ਰਾਹ
ਜਦੋਂ ਇੱਕ ਰੂਟ ਵਿੱਚ ਇੱਕੋ ਖਰਚ ’ਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਅਗਲੇ ਹਾਪ ਹੁੰਦੇ ਹਨ, ਰਾਊਟਰ ਨੂੰ ਹਰ ਪੈਕਟ ਲਈ ਇੱਕ ਚੁਣਨਾ ਪੈਂਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਲਾਗੂਕਰਨ ਪੈਕਟ ਦੇ ਖੇਤਰਾਂ ਦਾ ਹੈਸ਼ ਬਣਾਉਂਦੇ ਹਨ, ਆਮ ਤੌਰ ’ਤੇ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਪਤੇ ਨਾਲ ਪਰੋਟੋਕੋਲ ਅਤੇ ਪੋਰਟ, ਤਾਂ ਜੋ ਜਵਾਬ ਉਸੇ ਰਾਹ ’ਤੇ ਰਹਿਣ। ਵੱਖਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ, ਜਾਂ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਵੱਖਰੇ ਕਨੈਕਸ਼ਨ ਵੀ ਵੱਖਰੇ ਹੈਸ਼ ਬਣਾਉਂਦੇ ਹਨ।
ਇਸੇ ਲਈ ਗੇਟਵੇ ਤੋਂ ਕੀਤਾ ਨਿਦਾਨ ਇੰਨਾ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਗੇਟਵੇ ਦੀ ਆਪਣੀ ਜਾਂਚ ਦੇ ਆਪਣੇ ਪਤੇ ਅਤੇ ਪੋਰਟ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਸ ਲਈ ਆਪਣਾ ਹੈਸ਼ ਵੀ। ਇਹ ਸਿਹਤਮੰਦ ਟਨਲ ’ਤੇ ਉਤਰ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਵਰਤੋਂਕਾਰ ਟੁੱਟੇ ਟਨਲ ’ਤੇ ਉਤਰਦਾ ਰਹਿੰਦਾ ਹੈ।
ਪਲੇਟਫਾਰਮ ਅਗਲਾ ਹਾਪ ਕਿਵੇਂ ਚੁਣਦਾ ਹੈ
ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਚੋਣ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰੋ। ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਫੇਲ ਹੋ ਰਹੇ ਸੈਸ਼ਨ ਵਰਗੇ ਉਸੇ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਲਈ ਇਹ ਕਿਹੜਾ ਰੂਟ ਵਰਤੇਗਾ। ਉਸ ਖੋਜ ਵਿੱਚ ਉਹ ਖੇਤਰ ਵੀ ਸ਼ਾਮਲ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਾਧਾਰਨ ਮੰਜ਼ਿਲ-ਖੋਜ ਅਣਡਿੱਠ ਕਰਦੀ ਹੈ। ਇਸਨੂੰ ਕੰਮ ਕਰ ਰਹੇ ਕਲਾਇੰਟ ਤੋਂ ਵੀ ਚਲਾਓ ਅਤੇ ਦੋਵੇਂ ਜਵਾਬ ਤੁਲਨਾ ਕਰੋ:
ip route get 10.20.5.7 from 10.20.0.14ਨਵੇਂ iproute2 ਸੰਸਕਰਣ ਪਰੋਟੋਕੋਲ ਅਤੇ ਮੰਜ਼ਿਲ ਪੋਰਟ ਵੀ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ, ਜੋ ਹੈਸ਼ ਵਿੱਚ ਉਹ ਸ਼ਾਮਲ ਹੋਣ ’ਤੇ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ। ਉਸ ਆਉਟਪੁੱਟ ਦੀ ਤੁਲਨਾ ਕੰਮ ਕਰ ਰਹੇ ਕਲਾਇੰਟ ਤੋਂ ਕੀਤੀ ਉਸੇ ਖੋਜ ਨਾਲ ਕਰੋ, ਅਤੇ ਫ਼ਰਕ ਹੀ ਤੁਹਾਡੇ ਕੋਲ ਨਾ ਹੋਇਆ ਸਬੂਤ ਹੈ।
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
ਫੇਲ ਹੁੰਦੇ ਫਲੋ ਦਾ ਪਿੱਛਾ ਕਰੋ, ਰੂਟ ਸਾਰਣੀ ਦਾ ਨਹੀਂ
ਰੂਟ ਸਾਰਣੀ ਦੋਵੇਂ ਟਨਲ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ ਅਤੇ ਪਰਿਭਾਸ਼ਾ ਅਨੁਸਾਰ ਸਹੀ ਦਿਸਦੀ ਹੈ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਚੁਣੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਹਰ ਟਨਲ ਪੈਕਟ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਦੋਵੇਂ ਇੱਕੋ ਸੁਰੱਖਿਅਤ ਪ੍ਰੀਫਿਕਸ, ਇੱਕੋ ਫਾਰਵਰਡਿੰਗ ਆਗਿਆ ਅਤੇ ਉਸੇ ਕਲਾਇੰਟ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ ਵਾਪਸੀ ਰਾਹ ਲੈ ਕੇ ਚੱਲਦੇ ਹਨ।
ਵਿਚਕਾਰਲੇ ਸਥਿਤੀ ਵਾਲੇ ਯੰਤਰਾਂ ਵੱਲ ਧਿਆਨ ਦਿਓ। ਜੇ ਬੇਨਤੀ ਇੱਕ ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ ਅਤੇ ਜਵਾਬ ਦੂਜੇ ਰਾਹੀਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਜਿਸ ਫਾਇਰਵਾਲ ਜਾਂ NAT ਨੇ ਮੂਲ ਫਲੋ ਕਦੇ ਨਹੀਂ ਦੇਖਿਆ, ਉਹ ਇਸਨੂੰ ਸੁੱਟ ਦੇਵੇਗਾ. ਦੋਵੇਂ ਟਨਲ ਟ੍ਰੈਫਿਕ ਸਹੀ ਢੰਗ ਨਾਲ ਫਾਰਵਰਡ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਨੈਕਸ਼ਨ ਫਿਰ ਵੀ ਫੇਲ ਹੁੰਦਾ ਹੈ।
ਹਰ ਰਾਹ ਲਈ MTU ਵੀ ਜਾਂਚੋ। ਵਾਧੂ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਵਾਲਾ ਰਾਹ ਵਰਤਣਯੋਗ ਆਕਾਰ ਘਟਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਟਨਲ ’ਤੇ ਸਫਲ ਹੋਣ ਵਾਲਾ ਟ੍ਰਾਂਸਫਰ ਦੂਜੇ ’ਤੇ ਠੀਕ ਉਸੇ ਆਕਾਰ ’ਤੇ ਰੁਕ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਛੋਟਾ ਟੁੱਟਦਾ ਹੈ।
ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਰਾਹ ਦੀ ਤੁਲਨਾ ਕਰੋ
ਜਿੱਥੇ ਡਿਜ਼ਾਈਨ ਸੰਭਾਲ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਉੱਥੇ ਇੱਕ ਟਨਲ ਸੇਵਾ ਤੋਂ ਹਟਾਓ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦਾ ਕੰਮ ਦੁਹਰਾਓ। ਜੇ ਖਰਾਬੀ ਗਾਇਬ ਹੋ ਜਾਵੇ, ਸਮੱਸਿਆ ਤੁਹਾਡੇ ਹਟਾਏ ਰਾਹ ਦੀ ਹੈ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਰੂਟਿੰਗ ਸਾਰਣੀ ਦੁਬਾਰਾ ਜਾਂਚਣ ਦੀ ਥਾਂ ਇਸ ਦੀ ਸੰਰਚਨਾ ਗੁਆਂਢੀ ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ ਹੈ।
ਵਾਰ-ਵਾਰ ping ਨਹੀਂ, ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਦਰਜ ਕਰੋ ਕਿ ਖਰਾਬੀ ਕਿਸੇ ਖਾਸ ਅਗਲੇ ਹਾਪ, ਪੈਕਟ ਆਕਾਰ ਜਾਂ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਦੇ ਬਦਲਾਅ ਦਾ ਪਿੱਛਾ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਇਹ ਤਿੰਨ ਪੈਟਰਨ ਵੱਖਰੀਆਂ ਮੁਰੰਮਤਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ।
ਅੰਤ ਵਿੱਚ ਲਿਖੋ ਕਿ ਰਾਹਾਂ ਨੂੰ ਸਮਕੱਖ ਕਿਉਂ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਖਰਾਬੀ ਨੇ ਇੱਕ ਨੂੰ ਸੇਵਾ ਤੋਂ ਕਿਵੇਂ ਹਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਮਲਟੀਪਾਥ ਸਿਰਫ਼ ਤਦ ਸੁਰੱਖਿਅਤ ਹੈ ਜਦੋਂ ਰਾਹ ਸੱਚਮੁੱਚ ਬਦਲੇ ਜਾ ਸਕਣ ਵਾਲੇ ਹੋਣ, ਅਤੇ ਇਹ ਮੰਨਣ ਦੀ ਥਾਂ ਜਾਂਚਣ ਯੋਗ ਡਿਜ਼ਾਈਨ-ਕਥਨ ਹੈ।