Linux ਉੱਤੇ IPsec ਤੋਂ ਬਿਨਾਂ L2TP: xl2tpd, pppd ਅਤੇ NAT

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

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

ਤਿੰਨ ਫਾਈਲਾਂ ਕੰਮ ਵੰਡਦੀਆਂ ਹਨ

xl2tpd ਨਿਯੰਤਰਣ ਕਨੈਕਸ਼ਨ ਖ਼ਤਮ ਕਰਦਾ ਹੈ ਅਤੇ ਹਰ ਸੈਸ਼ਨ PPP ਡੈਮਨ ਨੂੰ ਸੌਂਪਦਾ ਹੈ, ਇਸ ਲਈ ਸੰਰਚਨਾ ਦੋ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ ਵੰਡੀ ਹੁੰਦੀ ਹੈ ਜੋ ਕਦੇ ਇੱਕ ਦੂਜੇ ਦੀਆਂ ਫਾਈਲਾਂ ਨਹੀਂ ਪੜ੍ਹਦੇ। ਸਰੋਤਾ /etc/xl2tpd/xl2tpd.conf ਵਿੱਚ, [lns default] ਭਾਗ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ, ਜੋ ਪਤਾ ਪੂਲ ਨੂੰ ip range ਨਾਲ, ਸਰਵਰ ਪਾਸੇ ਨੂੰ local ip ਨਾਲ ਅਤੇ PPP ਨੂੰ ਸੌਂਪਣ ਨੂੰ pppoptfile ਨਾਲ ਨਾਮ ਦਿੰਦਾ ਹੈ। require authentication = yes ਚਾਲੂ ਕਰੋ, length bit ਅਤੇ flow bit ਸਕ੍ਰਿਆ ਰੱਖੋ, ਅਤੇ ਅਜਿਹਾ ਪੂਲ ਚੁਣੋ ਜਿਸ ਨੂੰ ਹੋਸਟ ਉੱਤੇ ਹੋਰ ਕੋਈ ਨਹੀਂ ਵਰਤ ਰਿਹਾ।

PPP ਨੀਤੀ ਉਸ ਫਾਈਲ ਦੀ ਹੈ ਜਿਸ ਦਾ ਨਾਮ ਉਹ ਚੋਣ ਦੱਸਦੀ ਹੈ, ਆਮ ਤੌਰ ਉੱਤੇ /etc/ppp/options.xl2tpd: auth, pap, chap ਅਤੇ mschap ਲਈ ਇਨਕਾਰ, require-mschap-v2, 1460 ਦਾ MTU ਅਤੇ MRU, ਅਤੇ ਲਿੰਕ ਉੱਠਣ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ ਦੀ ਪਹੁੰਚ ਵਾਲਾ DNS ਪਤਾ। ਪ੍ਰਮਾਣ ਪੱਤਰ ਫਿਰ ਤੀਜੀ ਫਾਈਲ ਹਨ, /etc/ppp/chap-secrets, ਜਿੱਥੇ ਦੂਜਾ ਖੇਤਰ LNS ਭਾਗ ਦੇ ਨਾਮ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਚੌਥਾ ਖੇਤਰ ਪੂਲ ਵਿੱਚੋਂ ਕੋਈ ਖ਼ਾਸ ਪਤਾ ਪਿੰਨ ਕਰ ਸਕਦਾ ਹੈ।

ਟਨਲ ਕਿਉਂ ਜੁੜਦਾ ਹੈ ਅਤੇ ਫਿਰ ਅਟਕਦਾ ਹੈ

1500 ਬਾਈਟ ਦਾ Ethernet ਫਰੇਮ ਉਸ ਰਾਹ ਵਿੱਚ ਨਹੀਂ ਸਮਾਉਂਦਾ ਜੋ ਪਹਿਲਾਂ ਹੀ ਆਪਣੇ ਹੈਡਰਾਂ ਉੱਤੇ ਬਾਈਟ ਖ਼ਰਚ ਕਰਦਾ ਹੈ। ਬਾਹਰਲਾ IPv4 ਹੈਡਰ 20 ਲੈਂਦਾ ਹੈ, UDP 8, ਅਤੇ L2TP ਹੈਡਰ ਲਗਭਗ 12, ਜਿਸ ਨਾਲ PPP ਅਤੇ ਇਸ ਦੇ ਪੇਲੋਡ ਲਈ 1460 ਬਚਦਾ ਹੈ। PPP ਵਿੱਚ ਇਹੋ ਛੋਟੀ ਸੰਖਿਆ ਘੋਸ਼ਿਤ ਕਰਨਾ ਵੱਡੇ ਪੈਕਟਾਂ ਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡੇ ਜਾਣ ਜਾਂ ਵਿਚਕਾਰ ਕਿਤੇ ਚੁੱਪਚਾਪ ਡਿੱਗਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

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

ਇੱਕ ਪੋਰਟ ਦੋ ਗੱਲਬਾਤਾਂ ਢੋਂਦਾ ਹੈ

UDP 1701 ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਦੋਵੇਂ ਅੱਧਾਂ ਦੇ ਹੇਠਾਂ ਬੈਠਦਾ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਤੱਥ ਸੈੱਟਅੱਪ ਦੇ ਕਿਸੇ ਵੀ ਹੋਰ ਹਿੱਸੇ ਨਾਲੋਂ ਵੱਧ ਫਾਇਰਵਾਲ ਨਿਯਮ ਤੋੜਦਾ ਹੈ। ਪਹਿਲਾਂ ਨਿਯੰਤਰਣ-ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬੇਨਤੀ ਅਤੇ ਉਸ ਦਾ ਜਵਾਬ ਆਉਂਦੇ ਹਨ; ਉਸ ਤੋਂ ਬਾਅਦ ਦੀ ਸੈਸ਼ਨ ਬੇਨਤੀ ਅਤੇ ਪੁਸ਼ਟੀ ਪਛਾਣਕਰਤਾ ਜੋੜੀ ਤੋਂ ਵੱਧ ਕੁਝ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦੀਆਂ। ਫਿਰ PPP ਸੰਭਾਲਦਾ ਹੈ: ਲਿੰਕ ਨਿਯੰਤਰਣ, ਫਿਰ ਪ੍ਰਮਾਣੀਕਰਣ, ਫਿਰ ਪਤੇ ਤੈਅ ਕਰਨ ਲਈ IP ਨਿਯੰਤਰਣ ਪ੍ਰੋਟੋਕੋਲ। ਹਰ ਪੜਾਅ ਦੀ ਲੌਗ ਵਿੱਚ ਆਪਣੀ ਸ਼ਬਦਾਵਲੀ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਆਪਣੇ ਆਪ ਨੂੰ L2TP ਵਿਫ਼ਲਤਾ ਘੋਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ।

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

ਟਨਲ ਨੂੰ ਲਾਭਦਾਇਕ ਬਣਾਉਣਾ: ਫਾਰਵਰਡਿੰਗ ਅਤੇ NAT

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

ਸਰਵਰ ਉੱਤੇ sysctl -w net.ipv4.ip_forward=1 ਨਾਲ ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ ਕਰੋ, iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE ਨਾਲ ਪੂਲ ਦਾ ਅਨੁਵਾਦ ਕਰੋ, ਫਿਰ -i ppp0 -o eth0 ਲਈ FORWARD ਨਿਯਮ ਨਾਲ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਟਨਲ ਟ੍ਰੈਫਿਕ ਅਤੇ ਸ਼ੀਸ਼ੇ ਵਾਲੇ ਨਿਯਮ ਸਮੇਤ -m state --state RELATED,ESTABLISHED ਨਾਲ ਵਾਪਸ ਆਉਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਕਰੋ। ਇਹ ਨਿਯਮ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਵੀ ਟਿਕਾਊ ਰੱਖੋ, ਕਿਉਂਕਿ ਇਨ੍ਹਾਂ ਤੋਂ ਬਿਨਾਂ ਵਾਪਸ ਆਉਣ ਵਾਲਾ ਸਰਵਰ ਬਿਲਕੁਲ ਟੁੱਟੀ L2TP ਸੰਰਚਨਾ ਵਰਗਾ ਦਿਸਦਾ ਹੈ।

ਸਰਵਰ ਦੇ ਆਪਣੇ LAN ਤੱਕ ਪਹੁੰਚਣਾ ਦੂਜਾ ਕੰਮ ਹੈ: LAN ਰਾਊਟਰ ਉੱਤੇ ਪੂਲ ਲਈ ਵਾਪਸੀ ਰਾਹ ਜੋੜੋ, ਜਾਂ ਸਰਵਰ ਉੱਤੇ proxy ARP ਚਲਾਓ। ਜਦੋਂ LAN ਦੇ ਅੰਦਰ ਕੁਝ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸਿੱਧਾ ਸੰਬੋਧਨ ਕਰਨਾ ਹੋਵੇ, ਤਦ ਉਨ੍ਹਾਂ ਨੂੰ NAT ਪਿੱਛੇ ਲੁਕਾਉਣਾ ਬੱਸ ਬਾਅਦ ਲਈ ਦੂਜਾ ਡੀਬੱਗ ਸੈਸ਼ਨ ਤੈਅ ਕਰਨਾ ਹੈ।

ਨੰਗਾ ਸਟੈਕ ਕੀ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਕਿਵੇਂ ਜਾਂਚੀਏ

ਇਸ ਸਟੈਕ ਦਾ ਕੋਈ ਵੀ ਹਿੱਸਾ PPP ਫਰੇਮਾਂ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਸ ਵਿੱਚ ਕੁਝ ਵੀ ਦੂਰਲੇ ਸਿਰੇ ਨੂੰ ਉਸ ਸਰਵਰ ਵਜੋਂ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰਦਾ ਜੋ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਚੁਣਿਆ ਸੀ। MS-CHAPv2 ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੀ ਅਦਲਾ-ਬਦਲੀ ਨੂੰ ਸਿਰਫ਼ ਵੇਖਣ ਵਾਲੇ ਸਰੋਤੇ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ, ਪਰ ਰਾਹ ਵਿੱਚ ਬੈਠਾ ਹਮਲਾਵਰ ਫਿਰ ਵੀ ਸੈਸ਼ਨ ਵਿੱਚ ਦਖ਼ਲ ਦੇ ਸਕਦਾ ਹੈ। Windows ਦਾ ਮੂਲ ਕਲਾਇੰਟ L2TP ਸਿਰਫ਼ IPsec ਨਾਲ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ Linux, ਰਾਊਟਰ ਫਰਮਵੇਅਰ ਅਤੇ ਤੀਜੀ ਧਿਰ ਦੇ ਕਲਾਇੰਟਾਂ ਨੂੰ ਆਪਣੇ ਸਾਥੀ ਮੰਨੋ। ਨੰਗੀ ਸੰਰਚਨਾ ਨੂੰ ਨਿਦਾਨ ਦੀ ਪੌੜੀ ਮੰਨੋ, ਕਦੇ ਵੀ ਰੁਕਣ ਦੀ ਥਾਂ ਨਹੀਂ।

ਨਿਸ਼ਚਿਤ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ: xl2tpd -D ਨੂੰ ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਚਲਾਓ, PPP ਪੜਾਅ ਲਈ ਜਰਨਲ ਵੇਖੋ, ਦੋਵੇਂ ਸਿਰਿਆਂ ਉੱਤੇ ip addr ਤੋਂ ਦਿੱਤਾ ਪਤਾ ਪੜ੍ਹੋ, ਫਿਰ ਸੈਸ਼ਨ ਉੱਠਣ ਤੋਂ ਬਾਅਦ ਡੇਟਾ ਵਗਦਾ ਹੈ ਦੀ ਪੁਸ਼ਟੀ ਲਈ UDP 1701 ਕੈਪਚਰ ਕਰੋ। ਜੇ ਚਾਰੇ ਮੇਲ ਖਾਂਦੇ ਹਨ ਅਤੇ ਟ੍ਰੈਫਿਕ ਫਿਰ ਵੀ ਵਿਫ਼ਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਦੋਸ਼ ਰਾਊਟਿੰਗ, NAT ਜਾਂ MTU ਵਿੱਚ ਹੈ, L2TP ਆਪਣੇ ਆਪ ਵਿੱਚ ਨਹੀਂ।