ਕੰਮ ਕਰਦੇ VPN ਹੁੰਦਿਆਂ ਵੀ ਜਵਾਬ ’ਤੇ ਸਮਾਂ ਕਿਉਂ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ
ਕਿਸੇ ਨਿੱਜੀ ਸਰਵਰ ਤੱਕ ਬੇਨਤੀ ਪਹੁੰਚਣਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਦਾ ਅੱਧਾ ਹਿੱਸਾ ਹੈ। ਇਸ ਦੇ ਜਵਾਬ ਨੂੰ ਲੋੜੀਂਦੇ ਗੇਟਵੇ, ਮਾਰਗ ਜਾਂ ਤਰਜਮੇ ਰਾਹੀਂ ਟਨਲ ਕਲਾਇੰਟ ਲੱਭਣਾ ਪੈਂਦਾ ਹੈ।
ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ, ਸਰਵਰ ਇਸ ਨੂੰ ਲੌਗ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਫਿਰ ਵੀ ਸਮਾਂ ਖ਼ਤਮ ਹੋਣ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। ਇਸ ਮੇਲ ਦਾ ਅਰਥ ਹੈ ਕਿ ਜਵਾਬ ਨੂੰ ਵਾਪਸ ਜਾਣ ਦਾ ਰਾਹ ਨਹੀਂ ਮਿਲਿਆ, ਅਤੇ ਇਹ ਉਨ੍ਹਾਂ ਥੋੜ੍ਹੀਆਂ ਖ਼ਰਾਬੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਪੁਸ਼ਟੀ ਤੁਸੀਂ ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੋਂ ਇੱਕੋ ਸਮੇਂ ਕਰ ਸਕਦੇ ਹੋ। ਜਾਂਚਾਂ ਕ੍ਰਮ ਨਾਲ ਕਰੋ ਅਤੇ ਜਦੋਂ ਕੋਈ ਇੱਕ ਫੇਲ੍ਹ ਹੋਵੇ ਤਾਂ ਰੁਕ ਜਾਓ।
ਬੇਨਤੀ ਕਿੱਥੇ ਪਹੁੰਚੀ ਉੱਥੋਂ ਸ਼ੁਰੂ ਕਰੋ
ਹੋਰ ਕੁਝ ਵੀ ਜਾਂਚਣ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਪੈਕੇਟ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਗਿਆ ਹੈ। ਸਰਵਰ ਪਾਸੇ ਦੀ ਲੌਗ ਐਂਟਰੀ, ਕਨੈਕਸ਼ਨ ਗਿਣਤੀ ਜਾਂ ਦੂਰਲੇ ਸਿਰੇ ’ਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕੈਪਚਰ—ਸਭ ਇੱਕੋ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਦਾ ਨਾ ਹੋਣਾ ਤੁਹਾਨੂੰ ਜਵਾਬ ਵੱਲ ਨਹੀਂ, ਟਨਲ ਵੱਲ ਵਾਪਸ ਭੇਜਦਾ ਹੈ। ਇਹੀ ਉਹ ਜਾਂਚ ਹੈ ਜੋ ਫ਼ਾਰਵਰਡਿੰਗ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਵਾਪਸੀ ਮਾਰਗ ਦੀ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ।
ਜੇ ਬੇਨਤੀ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚੀ, ਤਾਂ ਇੱਥੇ ਹੀ ਰੁਕੋ। ਟਨਲ, ਨਿੱਜੀ ਪ੍ਰੀਫ਼ਿਕਸ ਤੱਕ ਰੂਟਿੰਗ ਜਾਂ ਐਕਸੈਸ ਨਿਯਮ ਵਿਸ਼ਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਦਾ ਮਾਰਗ ਹਾਲੇ ਪ੍ਰਸੰਗਿਕ ਨਹੀਂ ਹੈ। ਸਰਵਰ ਨੇ ਜੋ ਸਰੋਤ ਪਤਾ ਦੇਖਿਆ ਉਹ ਵੀ ਲਿਖੋ। ਉਹ ਜਾਂ ਤਾਂ ਕਲਾਇੰਟ ਨੂੰ ਮਿਲਿਆ ਪੂਲ ਪਤਾ ਹੈ ਜਾਂ ਤਰਜਮਾ ਕੀਤਾ ਪਤਾ, ਅਤੇ ਇਹੀ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਅੱਗੇ ਕਿਹੜੀ ਜਾਂਚ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।
ਜਵਾਬ ਨੂੰ ਪੂਲ ਤੱਕ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ
ਰਿਮੋਟ-ਐਕਸੈਸ ਕਲਾਇੰਟ ਨੂੰ ਆਮ ਤੌਰ ’ਤੇ ਪੂਲ ਵਿੱਚੋਂ ਪਤਾ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਨੂੰ ਉਸ ਪੂਲ ਤੱਕ ਵਾਪਸੀ ਦਾ ਮਾਰਗ ਚਾਹੀਦਾ ਹੁੰਦਾ ਹੈ। ਜਿਸ ਸਰਵਰ ਦਾ ਡਿਫ਼ਾਲਟ ਮਾਰਗ ਆਪਣੇ ਹੀ ਗੇਟਵੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਉਹ ਪੈਕੇਟ ਉਸ ਗੇਟਵੇ ਨੂੰ ਦੇ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਪੂਲ ਕਿੱਥੇ ਹੈ ਦੀ ਕੋਈ ਭਿਣਕ ਨਹੀਂ, ਇਸ ਲਈ ਜਵਾਬ ਉੱਥੇ ਹੀ ਮਰ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਵੀ ਵਾਪਸ ਨਾ ਆਉਣ ਕਰਕੇ ਕਲਾਇੰਟ ਨੂੰ ਸਮਾਂ ਖ਼ਤਮ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਕਦੇ ਨਾ ਨਿਕਲੀ ਬੇਨਤੀ ਤੋਂ ਵੱਖ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।
ਸਰਵਰ ਆਪਣੇ ਸਬਨੈੱਟ ਲਈ ਜੋ ਮਾਰਗ ਵਰਤਦਾ ਹੈ ਉਹ ਨਹੀਂ, ਸਗੋਂ ਕਲਾਇੰਟ ਪਤੇ ਲਈ ਜੋ ਮਾਰਗ ਚੁਣਦਾ ਹੈ ਉਹ ਜਾਂਚੋ। ਇਹ ਦੋ ਖੋਜਾਂ ਵੱਖਰੇ ਜਵਾਬ ਦੇ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਥੇ ਦੂਜੀ ਹੀ ਮਾਅਨੇ ਰੱਖਦੀ ਹੈ। ਤਰਜਮਾ ਬਦਲਵੀਂ ਬਣਾਵਟ ਹੈ ਅਤੇ ਇਹ ਬਦਲ ਦਿੰਦਾ ਹੈ ਕਿ ਸਰਵਰ ਕੀ ਦੇਖਦਾ ਹੈ। ਇਹ ਵਾਪਸੀ ਮਾਰਗ ਸੌਖਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਦੇ ਲੌਗਾਂ ਵਿੱਚੋਂ ਮੂਲ ਕਲਾਇੰਟ ਪਤਾ ਵੀ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਜੋ ਉਸ ਖੇਤਰ ’ਤੇ ਬਣੇ ਕਿਸੇ ਵੀ ਨਿਯਮ ਜਾਂ ਰਿਪੋਰਟ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।
ਸਰਵਰ ਕੈਪਚਰ ਦੀ ਗੇਟਵੇ ਕੈਪਚਰ ਨਾਲ ਤੁਲਨਾ ਕਰੋ
ਸਰਵਰ ਤੋਂ ਜੋ ਨਿਕਲਦਾ ਹੈ ਉਸ ਦੀ ਗੇਟਵੇ ’ਤੇ ਜੋ ਪਹੁੰਚਦਾ ਹੈ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਸਰਵਰ ਦੇ ਆਊਟਬਾਊਂਡ ਇੰਟਰਫ਼ੇਸ ’ਤੇ ਕੈਪਚਰ ਅਤੇ ਟਨਲ ਗੇਟਵੇ ’ਤੇ ਕੈਪਚਰ ਸਵਾਲ ਦੇ ਵੱਖਰੇ ਅੱਧਿਆਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰਲਾ ਵਿਥਕਾ ਨੁਕਸਾਨ ਦੀ ਥਾਂ ਦਿਖਾਉਂਦਾ ਹੈ।
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
ਗੇਟਵੇ ਆਪ ਬਣਾਉਂਦਾ ਬੇਨਤੀ ਕਲਾਇੰਟ ਜਾਂਚ ਦਾ ਮਾੜਾ ਬਦਲ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਦੂਜੇ ਪਤੇ ਤੋਂ ਆਉਂਦੀ ਹੈ ਅਤੇ ਦੂਜੇ ਨਿਯਮਾਂ ਨਾਲ ਟਕਰਾਉਂਦੀ ਹੈ। ਇਸੇ ਲਈ ਗੇਟਵੇ ਤੋਂ ਸਫਲ ping ਅਤੇ ਕਲਾਇੰਟ ਤੋਂ ਫੇਲ੍ਹ ਬੇਨਤੀ ਦੋਵੇਂ ਇੱਕੋ ਸਮੇਂ ਸੱਚ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਜੇ ਮਾਰਗ ’ਤੇ ਕਈ ਰਾਊਟਰ ਹੋਣ, ਤਾਂ ਪੂਲ ਤੱਕ ਮਾਰਗ ਲੋੜੀਂਦਾ ਹਰ ਇੱਕ ਜਾਂਚੋ। ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਬਣਾਵਟ ਵਿੱਚ ਦੂਰਲਾ ਪ੍ਰੀਫ਼ਿਕਸ ਇੱਕ ਤੋਂ ਵੱਧ ਡਿਵਾਈਸ ’ਤੇ ਜਾਣਿਆ ਹੋਣਾ ਅਕਸਰ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਗੇਟਵੇ ਨੂੰ ਆਪ ਟਨਲ ਅਤੇ LAN ਵਿਚਕਾਰ ਫ਼ਾਰਵਰਡ ਕਰਨਾ ਪੈਂਦਾ ਹੈ; strongSwan ਦੇ ਫ਼ਾਰਵਰਡਿੰਗ ਨੋਟ ਇਸ ਦੇ sysctl ਅਤੇ ਫ਼ਾਇਰਵਾਲ ਪਾਸੇ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ।
ਪੂਲ, ਪ੍ਰੀਫ਼ਿਕਸ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ ਦਰਜ ਕਰੋ
ਨੋਟ ਵਿੱਚ ਚਾਰ ਤੱਥ ਆਉਂਦੇ ਹਨ: ਕਲਾਇੰਟ ਨੂੰ ਮਿਲਿਆ ਪੂਲ, ਉਸ ਨੂੰ ਲੋੜੀਂਦਾ ਨਿੱਜੀ ਪ੍ਰੀਫ਼ਿਕਸ, ਜਵਾਬ ਦਾ ਜ਼ਿੰਮੇਵਾਰ ਰਾਊਟਰ, ਅਤੇ ਜੇ ਹੋਵੇ ਤਾਂ ਤਰਜਮਾ ਨਿਯਮ। ਇਨ੍ਹਾਂ ਨਾਲ ਬਾਅਦ ਵਿੱਚ ਗੇਟਵੇ ਬਦਲਣਾ ਜਾਂਚ ਨਹੀਂ, ਤੁਲਨਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਫਿਰ ਆਮ ਕਲਾਇੰਟ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅਸਲ ਖਾਤੇ ਨਾਲ ਦੁਬਾਰਾ ਜਾਂਚ ਕਰੋ। ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅਧਿਕਾਰ ਵਧਾਉਣ ਨਾਲ ਪੈਕੇਟ ਦਾ ਵਾਪਸੀ ਮਾਰਗ ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਇਸ ਨਿਦਾਨ ਦੌਰਾਨ ਖਾਤਾ ਬਦਲਣ ਨਾਲ ਅਗਲੀ ਤੁਲਨਾ ਉਲਝ ਜਾਵੇਗੀ। ਜੇ ਬਣਾਵਟ ਤਰਜਮੇ ’ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਉੱਥੇ ਦਸਤਾਵੇਜ਼ਬੱਧ ਕਰੋ ਜਿੱਥੇ ਸਰਵਰ ਦੇ ਲੌਗ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ। ਆਡਿਟ ਟ੍ਰੇਲ ਵਿੱਚ ਅਣਜਾਣ ਸਰੋਤ ਪਤਾ ਦੇਖਣ ਵਾਲੇ ਨੂੰ ਟਿਕਟ ਤੋਂ ਮੈਪਿੰਗ ਦੁਬਾਰਾ ਲੱਭਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।