ਹੇਅਰਪਿਨ NAT: ਅੰਦਰੋਂ VPN ਐਂਡਪੁਆਇੰਟ ਕਿਉਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ
ਜਨਤਕ ਪਤਾ ਵਰਤਣ ਵਾਲਾ ਸਥਾਨਕ ਕਲਾਇੰਟ LAN ਛੱਡ ਕੇ ਮੁੜ ਅੰਦਰ ਆਉਂਦਾ ਹੈ। ਜੇ ਰਾਊਟਰ ਹੇਅਰਪਿਨ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਬਾਹਰੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਅੰਦਰੋਂ ਨਹੀਂ।
ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ ਤੋਂ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਪਰ ਸੋਫ਼ੇ ਤੋਂ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲਾ VPN ਸਰਵਰ ਆਮ ਤੌਰ 'ਤੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੁੰਦਾ। LAN ਦੇ ਅੰਦਰਲਾ ਕਲਾਇੰਟ ਰਾਊਟਰ ਨੂੰ ਇੱਕ ਪੈਕਟ ਦਾ ਅਨੁਵਾਦ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ ਜਿਸਦਾ ਮੰਜ਼ਿਲ ਰਾਊਟਰ ਦਾ ਆਪਣਾ ਜਨਤਕ ਪਤਾ ਹੈ, ਭਾਵ ਪੈਕਟ ਨੂੰ ਬਾਹਰ ਜਾ ਕੇ ਤੁਰੰਤ ਵਾਪਸ ਆਉਣਾ ਪੈਂਦਾ ਹੈ। ਇਸ ਚਾਲ ਨੂੰ ਹੇਅਰਪਿਨਿੰਗ ਕਹਿੰਦੇ ਹਨ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਰਾਊਟਰ ਇਸਨੂੰ ਜਾਂ ਤਾਂ ਲਾਗੂ ਹੀ ਨਹੀਂ ਕਰਦੇ ਜਾਂ ਸਿਰਫ਼ ਚੈੱਕਬਾਕਸ ਚਾਲੂ ਹੋਣ 'ਤੇ ਕਰਦੇ ਹਨ। ਬਾਹਰਲੀ ਜਾਂਚ ਦਾ ਪਾਸ ਹੋਣਾ ਹੀ ਉਲਝਣ ਦਾ ਕਾਰਨ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਰੋਤਾ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਠੀਕ ਹਨ।
ਪੈਕਟ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਅਤੇ ਵਾਪਸ ਅੰਦਰ ਆਉਂਦਾ ਹੈ
ਪੈਕਟ ਦਾ ਪਿੱਛਾ ਕਰੋ। ਕਲਾਇੰਟ ਜਨਤਕ ਨਾਮ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ, ਜਨਤਕ ਪਤੇ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਅਤੇ ਰਾਊਟਰ ਦਾ ਮੰਜ਼ਿਲ NAT ਮੰਜ਼ਿਲ ਨੂੰ ਅੰਦਰੂਨੀ ਸਰਵਰ ਵੱਲ ਮੁੜ ਲਿਖਦਾ ਹੈ। ਸਰਵਰ ਦਾ ਜਵਾਬ ਕਲਾਇੰਟ ਦੇ LAN ਪਤੇ 'ਤੇ ਸੰਬੋਧਿਤ ਹੈ, ਇਸ ਲਈ ਇਹ ਰਾਊਟਰ ਦੇ LAN ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਵਾਪਸ ਜਾਂਦਾ ਹੈ, ਸਰੋਤ ਨੂੰ ਵਾਪਸ ਅਨੁਵਾਦ ਕਰਨ ਵਾਲੇ NAT ਨਿਯਮ ਵਿੱਚੋਂ ਕਦੇ ਨਾ ਲੰਘਦੇ ਹੋਏ।
ਹੁਣ ਕਲਾਇੰਟ ਨੂੰ ਅਜਿਹੇ ਪਤੇ ਤੋਂ ਪੈਕਟ ਮਿਲਦਾ ਹੈ ਜਿੱਥੇ ਉਸਨੇ ਕਦੇ ਕੁਝ ਨਹੀਂ ਭੇਜਿਆ, ਅਤੇ ਉਹ ਇਸਨੂੰ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਇਹੀ ਅਸਮਾਨਤਾ ਪੂਰੀ ਖਰਾਬੀ ਹੈ।
RFC 4787 ਇਸ ਸਥਿਤੀ ਵਿੱਚ NAT ਤੋਂ ਉਮੀਦ ਕੀਤੇ ਵਿਵਹਾਰ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਛੋਟਾ ਰੂਪ ਇਹ ਹੈ ਕਿ ਇਹ ਸਿਧਾਂਤ ਵਿੱਚ ਨਿਰਧਾਰਤ ਹੋਣ 'ਤੇ ਵੀ ਅਮਲ ਵਿੱਚ ਵਿਕਲਪਿਕ ਹੈ। ਕੁਝ ਰਾਊਟਰ ਇਸ ਸੈਟਿੰਗ ਨੂੰ NAT loopback ਕਹਿੰਦੇ ਹਨ, ਕੁਝ ਹੇਅਰਪਿਨ NAT ਜਾਂ NAT reflection ਕਹਿੰਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਕੁਝ ਵੀ ਨਹੀਂ ਦਿਖਾਉਂਦੇ। ਜਿਸ ਰਾਊਟਰ ਵਿੱਚ ਇਹ ਨਹੀਂ ਹੈ ਉਹ ਗਲਤ ਕਨਫ਼ਿਗਰ ਨਹੀਂ; ਉਹ ਆਮ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਹੱਲ ਕਿਤੇ ਹੋਰ ਆਉਂਦਾ ਹੈ। ਸਥਾਨਕ ਜਾਂਚ ਫੇਲ੍ਹ ਹੋਣ ਤੋਂ ਇਹ ਨਤੀਜਾ ਨਾ ਕੱਢੋ ਕਿ ਜਨਤਕ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਗਲਤ ਹੈ।
ਜਾਂਚ 1: ਦੋਵੇਂ ਰਾਹ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ
LAN ਤੋਂ ਬਾਹਰੋਂ, ਉਸੇ ਪਰੋਫ਼ਾਈਲ ਨਾਲ ਜੁੜੋ ਜੋ ਅਸਲੀ ਵਰਤੋਂਕਾਰ ਵਰਤੇਗਾ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੈਸ਼ਨ ਬਣਦਾ ਹੈ। ਅੰਦਰੋਂ, ਉਸੇ ਪਰੋਫ਼ਾਈਲ ਨਾਲ ਜਨਤਕ ਪਤੇ 'ਤੇ ਜੁੜੋ ਅਤੇ ਸਹੀ ਗਲਤੀ ਤੇ ਸਮਾਂ ਨੋਟ ਕਰੋ।
ਸਹੀ ਸਥਾਨਕ ਜਾਂਚ ਹੋਸਟਨਾਮ ਰੱਖਦੀ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਪਤਾ ਬਦਲਦੀ ਹੈ: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ ਬੇਨਤੀ ਨੂੰ ਜਨਤਕ ਪਤੇ 'ਤੇ ਭੇਜਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਸਹੀ ਸਰਵਰ ਨਾਮ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਇਹ ਨਾਮ-ਹੱਲ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਅਨੁਵਾਦ ਦੀ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਉਦੋਂ ਆਸਾਨੀ ਨਾਲ ਉਲਝ ਜਾਂਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹੀ ਨਾਮ ਕੈਫ਼ੇ ਤੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਨੋਟ ਕਰੋ ਕਿ ਕਲਾਇੰਟ TCP ਕਨੈਕਸ਼ਨ 'ਤੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜਾਂ ਬਾਅਦ ਵਿੱਚ TLS 'ਤੇ, ਕਿਉਂਕਿ ਪਹਿਲਾ ਅਨੁਵਾਦ ਵੱਲ ਅਤੇ ਦੂਜਾ ਪਛਾਣ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
ਜਾਂਚ 2: ਪੜ੍ਹੋ ਕਿ ਸਰਵਰ ਕੀ ਦੇਖਦਾ ਹੈ
ਸਭ ਤੋਂ ਲਾਹੇਵੰਦ ਨਿਰੀਖਣ ਸਰਵਰ ਦਾ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਹੈ। VPN ਹੋਸਟ 'ਤੇ ਕਲਾਇੰਟ ਦੇ LAN ਪਤੇ ਅਤੇ ਰਾਊਟਰ ਦੇ LAN ਪਤੇ 'ਤੇ ਫਿਲਟਰ ਕੀਤਾ ਕੈਪਚਰ ਚਲਾਓ, ਫਿਰ ਸਥਾਨਕ ਕੋਸ਼ਿਸ਼ ਦੁਹਰਾਓ। ਜੇ ਕੁਝ ਨਾ ਆਵੇ, ਤਾਂ ਪੈਕਟ ਅਨੁਵਾਦ ਵਿੱਚੋਂ ਨਹੀਂ ਬਚਿਆ।
ਜੇ ਕਨੈਕਸ਼ਨ ਕਲਾਇੰਟ ਦੇ ਪਤੇ ਦੀ ਥਾਂ ਰਾਊਟਰ ਦੇ LAN ਪਤੇ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਹੇਅਰਪਿਨਿੰਗ ਹੋ ਰਹੀ ਹੈ ਅਤੇ ਸਰੋਤ ਮੁੜ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਇਹ ਕੰਮ ਕਰਦਾ ਸੰਰਚਨਾ ਹੈ, ਖਰਾਬੀ ਨਹੀਂ।
ਜਾਂਚ 3: ਬਾਹਰਲੇ ਰਾਹ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਠੀਕ ਕਰੋ
ਤਿੰਨ ਸਮਰਥਿਤ ਰੂਪ ਹਨ, ਪ੍ਰਭਾਵ ਦੇ ਦਾਇਰੇ ਦੇ ਵਧਦੇ ਕ੍ਰਮ ਵਿੱਚ। ਸਭ ਤੋਂ ਸੰਕੀਰਣ ਹੈ ਵੰਡਿਆ DNS: ਅੰਦਰੂਨੀ ਰਿਕਾਰਡ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਤਾਂ ਜੋ ਉਹੀ ਸਰਵਰ ਨਾਮ LAN ਦੇ ਕਲਾਇੰਟਾਂ ਲਈ ਅੰਦਰੂਨੀ ਪਤੇ 'ਤੇ ਹੱਲ ਹੋਵੇ, ਜੋ ਜਨਤਕ ਰਾਹ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਟਾਲਦਾ ਹੈ। ਅਗਲਾ ਹੈ ਰਾਊਟਰ ਦਾ ਦਸਤਾਵੇਜ਼ੀ loopback ਜਾਂ reflection ਵਿਕਲਪ ਸਮਰੱਥ ਕਰਨਾ, ਜੇ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਸਿਰਫ਼ ਇਸ ਸੇਵਾ 'ਤੇ ਲਾਗੂ ਕਰਨਾ। ਸਭ ਤੋਂ ਚੌੜਾ ਹੈ ਰਾਊਟਰ 'ਤੇ source-NAT ਨਿਯਮ ਜੋ LAN ਤੋਂ ਆਉਣ ਵਾਲੀ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਸਰਵਰ ਵੱਲ ਮੁੜ ਲਿਖਦਾ ਹੈ ਤਾਂ ਜੋ ਜਵਾਬ ਰਾਊਟਰ ਰਾਹੀਂ ਵਾਪਸ ਆਵੇ; Linux ਰਾਊਟਰ 'ਤੇ ਇਹ ਸਰਵਰ ਦੇ ਪਤੇ ਅਤੇ ਪੋਰਟ ਨਾਲ ਮੇਲ ਖਾਂਦਾ MASQUERADE ਨਿਯਮ POSTROUTING ਹੈ। ਤਿੰਨੇ ਬਾਹਰਲੇ ਰਾਹ ਨੂੰ ਅਛੂਤਾ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਇਹੀ ਗੁਣ ਬਚਾਉਣਾ ਹੈ।
ਸਥਾਨਕ ਰਾਹ ਨੂੰ ਬਾਹਰਲੇ ਵਰਗਾ ਬਣਾਉਣ ਲਈ ਅਸੰਬੰਧਿਤ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਨਾ ਫੈਲਾਓ, ਅਤੇ ਸਮੱਸਿਆ ਟਾਲਣ ਲਈ ਸੇਵਾ ਨੂੰ ਹੋਰ ਪੋਰਟ 'ਤੇ ਨਾ ਲੈ ਜਾਓ। ਦੋਵੇਂ ਬਦਲਾਅ ਬਾਹਰਲੀ ਦੁਨੀਆ ਕਿੱਥੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ ਇਹ ਬਦਲਦੇ ਹਨ, ਸਿਰਫ਼ ਅੰਦਰਲੀ ਦੁਨੀਆ ਜੋ ਦੇਖਦੀ ਹੈ ਉਸਨੂੰ ਠੀਕ ਕਰਨ ਲਈ।
ਵੰਡੇ DNS ਵਿੱਚ ਇੱਕ ਜਾਲ ਹੈ ਜਿਸਦਾ ਜ਼ਿਕਰ ਕਰਨਾ ਬਣਦਾ ਹੈ। ਹੋਸਟਨਾਮ ਨੂੰ ਮਨਮਾਨੀ IP ਨਾਲ ਬਦਲਣਾ ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕੀ ਤਸਦੀਕ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਅੰਦਰੂਨੀ ਰਿਕਾਰਡ ਨੂੰ ਅਜੇ ਵੀ ਸਰਟੀਫਿਕੇਟ ਦੇ ਨਾਮ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜਾਂਚ 4: ਬਾਅਦ ਵਿੱਚ ਦੋਵੇਂ ਰਾਹ ਤਸਦੀਕ ਕਰੋ
LAN ਤੋਂ ਬਾਹਰੋਂ ਬਾਹਰਲੀ ਕੋਸ਼ਿਸ਼ ਦੁਹਰਾਓ, ਉਸੇ ਪਰੋਫ਼ਾਈਲ ਨਾਲ ਅੰਦਰਲੀ ਕੋਸ਼ਿਸ਼ ਦੁਹਰਾਓ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰਵਰ ਲੌਗ ਇੱਕ ਸਫਲਤਾ ਅਤੇ ਇੱਕ ਚੁੱਪ ਦੀ ਥਾਂ ਦੋ ਵੱਖਰੇ ਸਫਲ ਸੈਸ਼ਨ ਦਿਖਾਉਂਦਾ ਹੈ। ਫਿਰ ਜਾਂਚੋ ਕਿ ਹੋਰ ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਸਰੋਤੇ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਅਤੇ ਨਿੱਜੀ ਸਰੋਤਾਂ ਦੇ ਰਾਹ ਨਹੀਂ ਬਦਲੇ।
ਰਿਕਾਰਡ ਛੋਟਾ ਰੱਖੋ: ਕਿਸ ਕਲਾਇੰਟ ਨੇ ਕਿਹੜਾ ਪਤਾ ਵਰਤਿਆ, ਸਰਵਰ ਨੇ ਕੀ ਦੇਖਿਆ, ਅਤੇ ਤਿੰਨ ਹੱਲਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਲਾਗੂ ਹੋਇਆ। RFC 4787 ਦੀਆਂ ਹੇਅਰਪਿਨਿੰਗ ਲੋੜਾਂ ਇੱਥੇ NAT ਤੋਂ ਕੀ ਉਮੀਦ ਹੈ ਦਾ ਸੰਦਰਭ ਹਨ, ਅਤੇ ਸਮਝਾਉਂਦੀਆਂ ਹਨ ਕਿ ਇਸ ਸੁਵਿਧਾ ਤੋਂ ਬਿਨਾਂ ਰਾਊਟਰ ਆਮ ਵਿਵਹਾਰ ਕਿਉਂ ਕਰਦਾ ਹੈ। ਬਾਹਰਲੀ ਦੁਨੀਆ ਜਿਸਨੂੰ ਦੁਹਰਾ ਨਹੀਂ ਸਕਦੀ ਅਜਿਹੀ ਸਥਾਨਕ ਫੇਲ੍ਹਤਾ ਉਲਟ ਸਾਬਤ ਹੋਣ ਤੱਕ ਅਨੁਵਾਦ ਦਾ ਸਵਾਲ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਜਾਂਚੋ।