Docker ਵਿੱਚ PPTP ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ ਪਰ ਕੋਈ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਲੈ ਜਾਂਦਾ

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

ਪੰਜ ਜਾਂਚਾਂ, ਉਸ ਕ੍ਰਮ ਵਿੱਚ ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ।

ਜਾਂਚ 1: ਨਿਯੰਤਰਣ ਚੈਨਲ ਨੂੰ ਪੇਲੋਡ ਤੋਂ ਵੱਖ ਕਰੋ

PPTP TCP 1723 ਉੱਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ PPP ਪੇਲੋਡ ਨੂੰ GRE, IP ਪ੍ਰੋਟੋਕੋਲ 47 ਦੇ ਅੰਦਰ ਲੈ ਜਾਂਦਾ ਹੈ। GRE ਨਾ TCP ਹੈ ਨਾ UDP, ਇਸ ਲਈ ਨਿਯੰਤਰਣ ਪੋਰਟ ਫਾਰਵਰਡ ਕਰਨ ਵਾਲਾ ਹਰ ਨਿਯਮ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। 1723 ਪਾਸ ਕਰਨ ਵਾਲਾ NAT ਜਾਂ ਫਾਇਰਵਾਲ 47 ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਬਿਨਾਂ ਸ਼ਿਕਾਇਤ ਡਿੱਗਣ ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ ਸੈਸ਼ਨ ਸਫਲਤਾ ਵਾਂਗ ਦਿਖਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਅੱਧਾ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ।

ਜੇ ਲੌਗਇਨ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕੋਈ ਪੈਕੇਟ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਪਹਿਲਾਂ GRE ਮੰਨੋ ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਸਾਬਤ ਕਰੋ।

ਜਾਂਚ 2: ਹੋਸਟ ਕਰਨਲ ਵਿੱਚ ਸਹਾਇਕ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕਿੰਗ ਸਹਾਇਕ ਤੋਂ ਬਿਨਾਂ TCP ਨਿਯੰਤਰਣ ਕਨੈਕਸ਼ਨ ਨੂੰ GRE ਪ੍ਰਵਾਹ ਨਾਲ ਜੋੜ ਨਹੀਂ ਸਕਦੀ। ਮੌਡਿਊਲ nf_conntrack_pptp ਹੈ, ਇਹ ਹੋਸਟ ਕਰਨਲ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਕੰਟੇਨਰ ਇਮੇਜ ਦੇ ਅੰਦਰ ਇਸਨੂੰ ਲੋਡ ਕਰਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ ਕਿਉਂਕਿ ਮੌਡਿਊਲ ਪੂਰੇ ਹੋਸਟ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। Docker ਹੋਸਟ 'ਤੇ lsmod | grep nf_conntrack_pptp ਇਹੀ ਜਾਂਚ ਹੈ। ਜੇ ਇਹ ਨਹੀਂ ਹੈ, ਤਾਂ modprobe nf_conntrack_pptp ਇਸਨੂੰ ਚੱਲ ਰਹੇ ਕਰਨਲ ਲਈ ਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਅਗਲੇ ਬੂਟ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਇਸ ਲਈ ਇਸਨੂੰ ਹੋਸਟ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਵੀ ਸ਼ਾਮਲ ਕਰੋ।

ਰੀਬੂਟ 'ਤੇ ਗਾਇਬ ਹੋਣ ਵਾਲਾ ਮੌਡਿਊਲ ਅਗਲੇ ਮਹੀਨੇ ਉਹੀ ਟਿਕਟ ਬਣ ਜਾਂਦਾ ਹੈ।

ਜਾਂਚ 3: ਉਹ ਕਰਨਲ ਨੀਤੀ ਪੜ੍ਹੋ ਜੋ ਇਸਨੂੰ ਬੰਦ ਕਰਦੀ ਹੈ

ਮੌਡਿਊਲ ਹੋਣ 'ਤੇ ਵੀ, 4.7 ਤੋਂ ਕਰਨਲ net.netfilter.nf_conntrack_helper ਨੂੰ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ 0 'ਤੇ ਸੈੱਟ ਕਰਦੇ ਹਨ, ਜੋ ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਸਵੈਚਾਲਿਤ ਸਹਾਇਕ ਅਲਾਟਮੈਂਟ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹੀ ਡਿਫਾਲਟ ਕਾਰਨ ਹੈ ਕਿ ਸਹੀ ਢੰਗ ਨਾਲ ਸਥਾਪਿਤ ਮੌਡਿਊਲ ਵੀ ਕੁਝ ਨਹੀਂ ਕਰਦਾ: ਕੋਡ ਮੌਜੂਦ ਹੈ ਅਤੇ ਨੀਤੀ ਕਹਿੰਦੀ ਹੈ ਕਿ ਇਸਨੂੰ ਵਰਤੋ ਨਾ। sysctl net.netfilter.nf_conntrack_helper ਮੌਜੂਦਾ ਮੁੱਲ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਰਨਟਾਈਮ 'ਤੇ ਇਸਨੂੰ 1 'ਤੇ ਸੈੱਟ ਕਰਨ ਨਾਲ ਸਹਾਇਕ ਦੁਬਾਰਾ ਉਪਲਬਧ ਹੁੰਦਾ ਹੈ। ਜੇ ਡਿਜ਼ਾਈਨ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਤਾਂ ਹੋਸਟ ਦੀ sysctl ਕਨਫਿਗਰੇਸ਼ਨ ਰਾਹੀਂ ਮੁੱਲ ਨੂੰ ਕਾਇਮ ਰੱਖੋ।

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

ਜਾਂਚ 4: ਕੰਟੇਨਰ ਦਾ ਰਾਹ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵੇਖੋ

ਲੋਡ ਕੀਤਾ ਸਹਾਇਕ ਕੋਈ ਰੂਟ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਕੰਟੇਨਰ ਨੂੰ PPTP ਸਰਵਰ ਤੱਕ ਰਾਹ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਹੋਸਟ ਫਾਰਵਰਡਿੰਗ ਨੂੰ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ GRE ਦੀ ਇਜਾਜ਼ਤ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ: iptables -L FORWARD -v -n ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ 47 ਪ੍ਰੋਟੋਕੋਲ ਸਵੀਕਾਰ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਕਾਊਂਟਰ ਹਿਲਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। Docker ਦੇ masquerade ਨਿਯਮ TCP ਅਤੇ UDP ਦਾ ਅਨੁਵਾਦ ਕਰਦੇ ਹਨ, 47 ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਨਹੀਂ, ਇਸ ਲਈ ਬ੍ਰਿਜ ਕੰਟੇਨਰ ਨੂੰ ਸਪਸ਼ਟ forward ਮਨਜ਼ੂਰੀ ਅਤੇ ਕੁਝ ਹੋਸਟਾਂ 'ਤੇ ਆਪਣਾ ਅਨੁਵਾਦ ਨਿਯਮ ਚਾਹੀਦਾ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੰਟੇਨਰ ਕੋਲ ਉਹ PPP ਡਿਵਾਈਸ ਸਹਾਇਤਾ ਹੈ ਜੋ ਇਸਦੀ ਇਮੇਜ ਉਮੀਦ ਕਰਦੀ ਹੈ।

ਨਿਯਮ ਦਾ ਪਾਠ ਨਹੀਂ, ਕਾਊਂਟਰ ਪੜ੍ਹੋ। ਜੋ ਨਿਯਮ ਮੌਜੂਦ ਹੈ ਪਰ ਕਿਸੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਉਹ ਸਜਾਵਟ ਹੈ।

ਜਾਂਚ 5: ਸਾਬਤ ਕਰੋ ਕਿ GRE ਟ੍ਰੈਕ ਹੁੰਦਾ ਹੈ, ਫਿਰ PPTP ਬਾਰੇ ਫੈਸਲਾ ਕਰੋ

ਕਲਾਇੰਟ ਚੱਲਦੇ ਸਮੇਂ ਟ੍ਰੈਕਿੰਗ ਟੇਬਲ ਪੜ੍ਹੋ। ਸਥਾਪਿਤ PPTP ਨਿਯੰਤਰਣ ਐਂਟਰੀ ਅਤੇ ਸੰਬੰਧਿਤ GRE ਐਂਟਰੀ ਦਾ ਅਰਥ ਹੈ ਕਿ ਸਹਾਇਕ ਪ੍ਰਵਾਹਾਂ ਨੂੰ ਜੋੜ ਰਿਹਾ ਹੈ ਅਤੇ ਬਾਕੀ ਖਰਾਬੀ ਕਿਤੇ ਹੋਰ ਹੈ। GRE ਐਂਟਰੀ ਤੋਂ ਬਿਨਾਂ ਨਿਯੰਤਰਣ ਐਂਟਰੀ ਦਾ ਅਰਥ ਹੈ ਕਿ ਪੇਲੋਡ ਸੁੱਟਿਆ ਜਾ ਰਿਹਾ ਹੈ ਜਾਂ ਟ੍ਰੈਕ ਨਹੀਂ ਹੋ ਰਿਹਾ, ਜੋ ਤੁਹਾਨੂੰ ਜਾਂਚ 2 ਅਤੇ 3 'ਤੇ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ।

PPTP ਆਪਣੇ ਆਪ ਵਿੱਚ ਪੁਰਾਣਾ ਹੈ ਅਤੇ MS-CHAPv2 ਕਮਜ਼ੋਰ ਹੈ। ਜੇ ਸਰਵਰ L2TP/IPsec, IKEv2 ਜਾਂ WireGuard ਵੀ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੱਲ ਜਾਣ ਨਾਲ ਇਹ ਪੂਰੀ ਸ਼੍ਰੇਣੀ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਟ ਜਾਂਦੀਆਂ ਹਨ।

ਜਿੱਥੇ PPTP ਰਹਿਣਾ ਹੀ ਹੈ, ਉੱਥੇ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਨਹੀਂ ਬਲਕਿ ਹੋਸਟ 'ਤੇ ਕਲਾਇੰਟ ਚਲਾਉਣਾ NAT ਅਤੇ ਫਿਲਟਰਿੰਗ ਦੀ ਇੱਕ ਪਰਤ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਜੋ ਅਕਸਰ ਸਸਤਾ ਫੈਸਲਾ ਹੈ।