ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ: ਦੋ ਵੱਖਰੀਆਂ ਖਰਾਬੀਆਂ

ਸਾਈਟ A ਸਾਈਟ B ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, B ਸਾਈਟ A ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੀ, ਅਤੇ ਸੁਰੰਗ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਠੀਕ ਦਿਸਦੀ ਹੈ। ਸੁਰੰਗ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਖਰਾਬੀ ਹੈ। B ਉੱਤੇ ਸ਼ੁਰੂ ਹੋ ਕੇ ਰੱਦ ਹੋਣ ਵਾਲਾ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਅਤੇ A ਉੱਤੇ ਸ਼ੁਰੂ ਹੋਏ ਕਨੈਕਸ਼ਨ ਦਾ ਕਦੇ ਨਾ ਪਹੁੰਚਣ ਵਾਲਾ ਜਵਾਬ, ਦੋਵੇਂ ਇੱਕੋ ਜਿਹੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਅਤੇ ਬਿਲਕੁਲ ਵੱਖਰੇ ਨਿਦਾਨ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਇੱਕ ਰਾਹ ਦੀ ਨੀਤੀ ਜਾਂ ਰੂਟ ਦੀ ਸਮੱਸਿਆ ਹੈ; ਦੂਜੀ ਪਹਿਲਾਂ ਹੀ ਮਨਜ਼ੂਰ ਕੀਤੇ ਟਰੈਫ਼ਿਕ ਲਈ ਵਾਪਸੀ ਦੇ ਰਾਹ ਜਾਂ ਹਾਲਤ ਦੀ ਸਮੱਸਿਆ ਹੈ।

ਇਹੀ ਅੰਤਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਕਮਾਂਡ ਚਲਾਉਣਾ ਲਾਹੇਵੰਦ ਹੈ।

ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਣ ਵਾਲੀਆਂ ਦੋ ਖਰਾਬੀਆਂ

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

ਪੁੱਛੋ ਕਿ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ ਕਿਹੜੇ ਪਾਸਿਓਂ ਸ਼ੁਰੂ ਹੋਈ ਸੀ। ਇਹ ਇੱਕ ਤੱਥ ਅੱਧੇ ਸੰਭਾਵੀ ਕਾਰਨ ਹਟਾ ਦਿੰਦਾ ਹੈ।

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

ਪਹਿਲਾ ਮਾਮਲਾ: ਵਾਪਸੀ ਦਾ ਰਾਹ ਨਹੀਂ

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

ਅਨੁਵਾਦ ਤੋਂ ਬਾਅਦ ਮੰਜ਼ਿਲ ਅਸਲ ਵਿੱਚ ਜੋ ਪਤਾ ਦੇਖਦੀ ਹੈ ਉਹ ਜਾਂਚੋ, ਅਤੇ ਵਾਪਸੀ ਦਾ ਰਾਹ ਮੂਲ ਸਬਨੈੱਟ ਦੀ ਥਾਂ ਉਸ ਪਤੇ ਲਈ ਜਾਂਚੋ।

ਦੂਜਾ ਮਾਮਲਾ: ਨੀਤੀ ਨੇ ਇਸ ਨੂੰ ਕਦੇ ਮਨਜ਼ੂਰ ਨਹੀਂ ਕੀਤਾ

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

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

ਉਹੀ ਹੋਸਟਾਂ ਉੱਤੇ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

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

ਸੁਧਾਰ ਤੋਂ ਬਾਅਦ ਉਸੇ ਹੋਸਟ ਤੋਂ ਉਹੀ ਟੈਸਟ ਦੁਹਰਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਅਸੰਬੰਧਿਤ ਪਹੁੰਚ ਅਜੇ ਵੀ ਰੱਦ ਹੈ। “established” ਸੁਰੰਗ ਸਥਿਤੀ ਆਪਣੇ ਆਪ ਵਿੱਚ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਸਿੱਟੇ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੀ।