VPN ਦਾ ਕਿਹੜਾ ਪੜਾਅ ਫੇਲ੍ਹ ਹੋਇਆ: IPsec, L2TP ਨਿਯੰਤਰਣ ਜਾਂ PPP ਪ੍ਰਮਾਣੀਕਰਨ
ਆਖਰੀ ਸਫਲ ਪੜਾਅ ਲੱਭੋ ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਪਰਤ ਠੀਕ ਕਰੋ: IPsec, L2TP ਨਿਯੰਤਰਣ ਚੈਨਲ, PPP ਪ੍ਰਮਾਣੀਕਰਨ ਜਾਂ ਪਤਾ ਨਿਰਧਾਰਨ।
ਤੁਸੀਂ ਪਾਸਵਰਡ ਬਦਲਿਆ ਅਤੇ ਕੁਝ ਨਹੀਂ ਹਿਲਿਆ, ਕਿਉਂਕਿ ਨੁਕਸ ਕਦੇ PPP ਵਿੱਚ ਨਹੀਂ ਸੀ। L2TP/IPsec ਪੰਜ ਬਿਲਕੁਲ ਵੱਖਰੇ ਹੈਂਡਓਫ਼ਾਂ ਲਈ ਇੱਕੋ ਕਨੈਕਸ਼ਨ ਗਲਤੀ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਹਰ ਹੈਂਡਓਫ਼ ਦੀ ਆਪਣੀ ਮੁਰੰਮਤ ਹੈ। ਉਲਟਾ ਕੰਮ ਕਰੋ: ਆਖਰੀ ਸਫਲ ਪੜਾਅ ਲੱਭੋ ਅਤੇ ਸਿਰਫ਼ ਉਸ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲਾ ਬਦਲੋ। ਹੇਠਾਂ ਦਿੱਤਾ ਕ੍ਰਮ ਇਹ ਵੀ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਸਬੂਤ ਪਹਿਲਾਂ ਇਕੱਠਾ ਕਰੋਗੇ।
ਚਾਰ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਕ੍ਰਮ ਨਾਲ ਦਿਓ
ਨਵਾਂ ਯਤਨ ਜ਼ਬਰਦਸਤੀ ਕਰੋ, ਕਿਉਂਕਿ ਕੁਝ ਕਲਾਇੰਟ ਪ੍ਰੋਫ਼ਾਈਲ ਡਿਸਕਨੈਕਟ ਅਤੇ ਦੁਬਾਰਾ ਕਨੈਕਟ ਨਾ ਹੋਣ ਤੱਕ ਪਿਛਲੀ ਗਲਤੀ ਦਿਖਾਉਂਦੇ ਰਹਿੰਦੇ ਹਨ। ਫਿਰ ਇਸ ਦਾ ਜਵਾਬ ਦਿਓ: IPsec ਸੁਰੱਖਿਆ ਸੰਬੰਧ ਸੀ, L2TP ਨਿਯੰਤਰਣ ਕਨੈਕਸ਼ਨ ਅਤੇ ਕਾਲ ਦਿਖੇ, PPP ਪ੍ਰਮਾਣੀਕਰਨ ਫੈਸਲੇ ਤੱਕ ਪਹੁੰਚਿਆ, ਅਤੇ IPCP ਨੇ ਕਲਾਇੰਟ ਨੂੰ ਪਤਾ ਦਿੱਤਾ? ਪਹਿਲਾ ਨਹੀਂ ਹੀ ਉਹ ਪੜਾਅ ਹੈ ਜੋ ਤੁਸੀਂ ਠੀਕ ਕਰਦੇ ਹੋ। ਉਸ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਅਣਜਾਂਚਿਆ ਹੈ, ਇਸ ਲਈ ਜਦੋਂ ਕਦੇ ਸੰਬੰਧ ਨਹੀਂ ਸੀ ਤਾਂ ਰੱਦ ਕੀਤਾ ਵਰਤੋਂਕਾਰਨਾਮ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।
ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੀਆਂ ਘੜੀਆਂ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰੋ। ਜਿਸ ਮੁੜ-ਯਤਨ ਨੇ IPsec ਸਾਫ਼ ਕੀਤਾ ਅਤੇ PPP 'ਤੇ ਫੇਲ੍ਹ ਹੋਇਆ, ਉਹ ਇੱਕੋ ਨੁਕਸ ਵਾਂਗ ਦਿਖਦਾ ਹੈ ਜਦੋਂ ਕਲਾਇੰਟ ਸਿਰਫ਼ ਆਖਰੀ ਸੁਨੇਹਾ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਲੌਗ ਅਜੇ ਵੀ ਪਿਛਲਾ ਯਤਨ ਰੱਖਦਾ ਹੈ। ਸਭ ਤੋਂ ਉੱਚੀ ਆਵਾਜ਼ ਵਾਲੀ ਲਾਈਨ ਨਾਲ ਨਹੀਂ, ਸਮਾਂ-ਛਾਪ ਨਾਲ ਪੜ੍ਹੋ।
ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਵਰਤੋਂਕਾਰ ਦਾ ਸਕ੍ਰੀਨਸ਼ਾਟ ਹੋਵੇ, ਸਭ ਤੋਂ ਸਸਤੀ ਵੰਡ 'ਤੇ ਭਰੋਸਾ ਕਰੋ: ਗਲਤ ਪੂਰਵ-ਸਾਂਝੀ ਕੁੰਜੀ ਅਤੇ ਕਦੇ ਜਵਾਬ ਨਾ ਦੇਣ ਵਾਲਾ xl2tpd Windows ਸੰਵਾਦ ਵਿੱਚ ਇੱਕੋ ਪਾਠ ਪੈਦਾ ਕਰਦੇ ਹਨ, ਪਰ ਇੱਕ ਨੂੰ ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਬਦਲਿਆ ਭੇਤ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਨੂੰ ਸਰਵਰ 'ਤੇ ਹੀ ਡੈਮਨ ਚਾਲੂ ਕਰਨਾ ਜਾਂ ਫਾਇਰਵਾਲ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ। ਵਿਚਕਾਰਲਾ ਯੰਤਰ ਟ੍ਰਾਂਸਪੋਰਟ-ਮੋਡ IPsec ਦੁਆਰਾ ਲਪੇਟੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਅੰਦਰਲਾ 1701 ਨਹੀਂ ਡਾ ਸਕਦਾ, ਇਸ ਲਈ ਨਾ-ਹੋਣ ਵਾਲਾ ਪਥ-ਫਿਲਟਰ ਨਾ ਲੱਭੋ।
ਹਰ ਪਰਤ ਅਸਲ ਵਿੱਚ ਕੀ ਰੱਖਦੀ ਹੈ
IPsec ਦੋ ਸਾਥੀਆਂ ਵਿਚਕਾਰ ਪੈਕਟ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ; L2TP ਉਸ ਸੁਰੱਖਿਅਤ ਪਥ ਦੇ ਅੰਦਰ PPP ਸੈਸ਼ਨ ਢੋਂਦਾ ਹੈ, ਇਸੇ ਲਈ RFC 3193 ਆਪਣੀ ਵੱਖਰੀ ਸੁਰੰਗ ਦੀ ਥਾਂ ਟ੍ਰਾਂਸਪੋਰਟ ਮੋਡ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ ਦਾ ਲੇਬਲ L2TP ਕਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਸੁਰੰਗ ਅਤੇ ਲੌਗਇਨ ਇੱਕੋ ਵਿਧੀ ਜਾਪਦੇ ਹਨ। ਅਜਿਹਾ ਨਹੀਂ: L2TP ਨਿਯੰਤਰਣ ਕਨੈਕਸ਼ਨ ਉੱਥੇ ਸੁਰੰਗ ਦੇ ਸਿਰਿਆਂ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਤੈਨਾਤੀ ਇਸ ਨੂੰ ਚਾਲੂ ਕਰਦੀ ਹੈ, ਅਤੇ PPP ਸਰਵਰ ਨੀਤੀ ਅਨੁਸਾਰ CHAP, PAP ਜਾਂ MS-CHAPv2 ਨਾਲ ਵਰਤੋਂਕਾਰ ਦੀ ਵੱਖਰੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ।
ਇਹ ਵੰਡ ਉਹ ਦੋ ਭੇਤ ਸਮਝਾਉਂਦੀ ਹੈ ਜੋ ਲੋਕ ਵਾਰ-ਵਾਰ ਗੁੰਝਲਦੇ ਹਨ। ਪੂਰਵ-ਸਾਂਝੀ ਕੁੰਜੀ IPsec ਸਾਥੀਆਂ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦੀ ਹੈ। ਵਰਤੋਂਕਾਰਨਾਮ ਅਤੇ ਪਾਸਵਰਡ PPP ਸਾਹਮਣੇ ਵਰਤੋਂਕਾਰ ਦੀ ਪਛਾਣ ਕਰਦੇ ਹਨ। ਜਿਸ ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਪ੍ਰਮਾਣਿਕਤਾ ਹੁੰਦੀ ਹੈ ਉਸ 'ਤੇ Windows ਦਾ ਸਾਂਝਾ ਭੇਤ ਦੁਬਾਰਾ ਟਾਈਪ ਕਰਨ ਨਾਲ ਫੇਲ੍ਹ ਹੋ ਰਹੇ ਪੜਾਅ 'ਤੇ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ PPP ਪਾਸਵਰਡ ਸੋਧਣ ਨਾਲ ਗੁੰਮ ਸੁਰੱਖਿਅਤ ਚੈਨਲ ਨਹੀਂ ਮਿਲ ਸਕਦਾ। ਇਹੀ ਸੰਜਮ ਪਛਾਣ ਜਾਂਚ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਸੁਰੰਗ ਲੈਣ ਲਈ ਸਾਥੀ ਦੀ ਪਛਾਣ ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਕਤਾ ਬੰਦ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਤਦ ਜੁੜਨ ਵਾਲਾ ਪਥ ਹੈ, ਸਾਥੀ ਨਹੀਂ।
ਪ੍ਰਮਾਣੀਕਰਨ ਵੀ PPP ਦਾ ਅੰਤ ਨਹੀਂ। ਵਰਤੋਂਕਾਰ ਸਵੀਕਾਰ ਹੋਣ ਤੋਂ ਬਾਅਦ IPCP ਕਲਾਇੰਟ ਦੇ ਪਤੇ ਅਤੇ ਸਰਵਰ ਦੇ ਦੇਣ ਲਈ ਤਿਆਰ DNS ਤੇ WINS ਵਿਕਲਪਾਂ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ CHAP ਜਾਂ MS-CHAPv2 ਪਾਸ ਕਰਕੇ ਵੀ ਪਤੇ ਬਿਨਾਂ ਰਹਿ ਸਕਦਾ ਹੈ, ਜੋ PPP ਦੇ ਅੰਦਰਲਾ ਨੁਕਸ ਹੈ, ਰਾਊਟਿੰਗ ਸਮੱਸਿਆ ਨਹੀਂ। IPsec ਤੋਂ ਬਿਨਾਂ ਸਾਧਾਰਨ L2TP ਵੈਧ ਅਤੇ ਅਸੁਰੱਖਿਅਤ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਫਲ ਕਨੈਕਸ਼ਨ ਕਦੇ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਟ੍ਰੈਫਿਕ ਸੁਰੱਖਿਅਤ ਹੈ; ਜਾਂਚੋ ਸਰਵਰ ਕੀ ਮੰਗਦਾ ਹੈ, ਕਲਾਇੰਟ ਦਾ ਲੇਬਲ ਨਹੀਂ।
ਪਹਿਲੇ ਗੁੰਮ ਪੜਾਅ ਤੋਂ ਫੈਸਲਾ ਕਰੋ
ਸਾਰਣੀ ਨੂੰ ਪਹਿਲੀ ਗੁੰਮ ਵਸਤੂ ਅਨੁਸਾਰ ਖੱਬੇ ਤੋਂ ਸੱਜੇ ਪੜ੍ਹੋ। ਸੱਜਾ ਕਾਲਮ ਉਸ ਸਮੇਂ ਦੀ ਇੱਕੋ-ਇੱਕ ਲਾਹੇਵੰਦ ਕਾਰ ਹੈ; ਉਸ ਦੇ ਖੱਬੇ ਪਾਸੇ ਸਭ ਪਹਿਲਾਂ ਹੀ ਸਾਬਤ ਹੈ, ਅਤੇ ਦੁਬਾਰਾ ਜਾਂਚਣ ਨਾਲ ਜਾਣਕਾਰੀ ਜੋੜੇ ਬਿਨਾਂ ਰੁਕਾਵਟ ਦੀ ਖਿੜਕੀ ਸੜਦੀ ਹੈ।
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
ਤਿੰਨ ਕਤਾਰਾਂ ਚੇਤਾਵਨੀ ਦੇ ਯੋਗ ਹਨ। 1701 ਕਤਾਰ ਉਹ ਹੈ ਜਿੱਥੇ NAT ਪਿੱਛੇ ਦੇ Windows ਕਲਾਇੰਟ ਆਮ ਤੌਰ 'ਤੇ ਉਤਰਦੇ ਹਨ: ਸੰਬੰਧ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਕੁਝ ਨਹੀਂ ਆਉਂਦਾ, ਅਤੇ ਕਾਰਨ ਮਾੜਾ ਪਾਸਵਰਡ ਨਹੀਂ, ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਹੈ। IPCP ਕਤਾਰ ਉਹ ਹੈ ਜਿਸ ਨੂੰ ਗਲਤੀ ਨਾਲ ਰਾਊਟ ਸਮੱਸਿਆ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ Windows ਗੁੰਮ ਪਤੇ ਨੂੰ ਗਲਤੀ 720 ਵਿੱਚ ਲਪੇਟਦਾ ਹੈ ਅਤੇ ਟਰੇ ਆਈਕਨ ਸਿਰਫ਼ ਕਹਿੰਦਾ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਫੇਲ੍ਹ ਹੋਇਆ; ਉਹ ਨੁਕਸ ਪ੍ਰਮਾਣੀਕਰਨ ਤੋਂ ਬਾਅਦ ਅਤੇ ਰਾਊਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਬੈਠਦਾ ਹੈ। ਆਖਰੀ ਕਤਾਰ IPsec ਨੁਕਸ ਹੀ ਨਹੀਂ, ਭਾਵੇਂ ਟਰੇ ਆਈਕਨ ਡਿਸਕਨੈਕਟਿਡ ਕਹੇ।
ਪਰਤਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਵਾਲੇ ਆਦੇਸ਼
strongSwan ਚਲਾਉਣ ਵਾਲੇ Linux ਸਰਵਰ 'ਤੇ swanctl --list-sas ਸਥਾਪਿਤ ਸੰਬੰਧਾਂ ਨੂੰ ਸਾਥੀ ਦੀ ਪਛਾਣ ਸਮੇਤ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ ipsec statusall ਪੁਰਾਣੇ strongSwan ਤੇ libreswan ਹੋਸਟ ਕਵਰ ਕਰਦਾ ਹੈ। ਉਸ ਹੇਠ ip xfrm state ਕਰਨਲ ਦੇ ਅਸਲ ਸੰਬੰਧ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਦਕਿ ss -lunp | grep 1701 ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ xl2tpd ਕਿੱਥੇ ਬੱਝਿਆ ਹੈ। ਨਿਯੰਤਰਣ ਕਨੈਕਸ਼ਨ ਅਤੇ ਕਾਲ ਆਉਂਦੇ ਵੇਖਣ ਲਈ xl2tpd -D ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਚਲਾਓ, ਅਤੇ ਪੇਸ਼ ਕੀਤੀ ਵਿਧੀ ਤੇ ਜਵਾਬ ਵੇਖਣ ਲਈ /etc/ppp/options.xl2tpd ਵਿੱਚ pppd ਡੀਬੱਗ ਚਾਲੂ ਕਰੋ।
ਲੌਗ ਸਫਲ ਪ੍ਰਮਾਣੀਕਰਨ ਦਿਖਾਉਣ ਤੋਂ ਬਾਅਦ ਅਗਲਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ IPCP ਪੂਰਾ ਹੋਇਆ। ਜਾਂਚੋ ਕਿ /etc/xl2tpd/xl2tpd.conf ਦੇ [lns default] ਭਾਗ ਵਿੱਚ ip range ਕੋਲ ਅਜੇ ਖਾਲੀ ਪਤੇ ਹਨ, ਅਤੇ ਜੇ ਕਲਾਇੰਟ ਉਮੀਦ ਕਰਦਾ ਹੈ ਤਾਂ /etc/ppp/options.xl2tpd ਸੱਚਮੁੱਚ ms-dns ਤੇ ms-wins ਰੱਖਦਾ ਹੈ। ਖ਼ਤਮ ਹੋਇਆ ਪੂਲ ਅਤੇ ਗੁੰਮ DNS ਵਿਕਲਪ ਤਾਰ 'ਤੇ ਵੱਖਰੇ ਦਿਸਦੇ ਹਨ: ਪਹਿਲਾ ਕਲਾਇੰਟ ਨੂੰ ਪਤੇ ਬਿਨਾਂ ਅਤੇ 720 ਨਾਲ ਛੱਡਦਾ ਹੈ, ਦੂਜਾ ਪਤਾ ਦਿੰਦਾ ਹੈ ਪਰ ਕੋਈ ਹੱਲਕਰਤਾ ਨਹੀਂ, ਇਸ ਲਈ ਨਾਮ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ ਜਦਕਿ ਕੱਚੇ ਪਤਿਆਂ ਨੂੰ ping ਕੰਮ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਪਾਸਵਰਡ ਮੁੜ ਪਾ ਕੇ ਠੀਕ ਨਹੀਂ ਹੁੰਦੇ।
ਕਲਾਇੰਟ 'ਤੇ NetworkManager ਦਾ L2TP ਪਲੱਗਇਨ pppd ਦੀ ਗੱਲਬਾਤ ਜਰਨਲ ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਇਸ ਲਈ journalctl -u NetworkManager -b ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੰਗ ਉੱਪਰ, ਪ੍ਰਮਾਣੀਕਰਨ ਰੱਦ ਨੂੰ ਕੋਈ ਸੁਰੰਗ ਹੀ ਨਹੀਂ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। Windows 'ਤੇ Get-VpnConnection ਪ੍ਰੋਫ਼ਾਈਲ ਦੀਆਂ ਅਸਲ ਪ੍ਰਮਾਣੀਕਰਨ ਸੈਟਿੰਗਾਂ ਦੱਸਦਾ ਹੈ, ਅਤੇ Event Viewer ਵਿੱਚ Application ਹੇਠਲੇ RasClient ਘਟਨਾਵਾਂ ਫੇਲ੍ਹ ਹੋਏ ਹਿੱਸੇ ਦਾ ਨਾਮ ਲੈਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਸੰਵਾਦ ਬਹੁਤ ਅਸਪਸ਼ਟ ਹੋਵੇ, netsh ras set tracing * enable ਸਮਰੱਥ ਕਰੋ।
ਕੈਪਚਰ ਲਈ ਇੱਕ ਸਾਵਧਾਨੀ ਚਾਹੀਦੀ ਹੈ। ਟ੍ਰਾਂਸਪੋਰਟ-ਮੋਡ IPsec ਨਾਲ ਅੰਦਰਲਾ UDP 1701 ਐਨਕ੍ਰਿਪਟ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਬਾਹਰਲੇ ਇੰਟਰਫੇਸ 'ਤੇ ਕੈਪਚਰ ESP ਦਿਖਾਉਂਦਾ ਹੈ, ਜਾਂ NAT-T ਹੇਠ UDP 4500, ਅਤੇ L2TP ਬਿਲਕੁਲ ਨਹੀਂ। ਕੈਪਚਰ ਵਿੱਚ 1701 ਨਾ ਹੋਣਾ ਆਮ ਗੱਲ ਹੈ ਅਤੇ ਬਲੌਕ ਪੋਰਟ ਦਾ ਸਬੂਤ ਨਹੀਂ; ਵੇਖੋ ESP ਜਾਂ 4500 ਕਾਊਂਟਰ ਹਿੱਲਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।
NAT, MTU ਅਤੇ ਰਾਊਟ: ਜਿੱਥੇ ਸਟੈਕ ਤੁਹਾਨੂੰ ਭਰਮਾਉਂਦਾ ਹੈ
ਕੁਝ ਵੀ ਪ੍ਰਮਾਣਿਤ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ NAT ਧਾਰਨਾਵਾਂ ਤੋੜਦਾ ਹੈ। ESP ਆਪਣਾ ਵੱਖਰਾ IP ਪ੍ਰੋਟੋਕੋਲ ਹੈ, ਇਸ ਲਈ ਅਨੁਵਾਦ ਕਰਨ ਵਾਲਾ ਯੰਤਰ ਇਸ ਨੂੰ ਸੁੱਟ ਦਿੰਦਾ ਹੈ ਜਦ ਤੱਕ ਸਾਥੀ ਇਨਕੈਪਸੂਲੇਟ ਨਾ ਕਰਨ; UDP 4500 ਇਹੀ ਦਿੰਦਾ ਹੈ। ਜੋ Windows ਸਰਵਰ ਆਪ ਘਰੇਲੂ ਰਾਊਟਰ ਜਾਂ ਕਲਾਊਡ NAT ਗੇਟਵੇ ਪਿੱਛੇ ਹੈ, ਉੱਥੇ IPsec ਪੜਾਅ ਗਲਤੀ 789 ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜਦ ਤੱਕ PolicyAgent ਕੁੰਜੀ ਹੇਠ AssumeUDPEncapsulationContextOnSendRule ਨੂੰ 2 'ਤੇ ਸੈਟ ਕਰਕੇ ਮਸ਼ੀਨ ਮੁੜ ਚਾਲੂ ਨਾ ਹੋਵੇ, ਅਤੇ ਨੁਕਸ ਬੰਦ ਪੋਰਟ ਤੋਂ ਅਲੱਗ ਨਹੀਂ ਪਛਾਣਿਆ ਜਾਂਦਾ। NAT ਪਿੱਛੇ ਦੇ ਕਲਾਇੰਟ ਸੌਖੇ ਹਨ: ਸਰਵਰ 'ਤੇ ਜਨਤਕ ਪਤਾ ਹੋਵੇ ਤਾਂ UDP 4500 'ਤੇ NAT-T ਉਨ੍ਹਾਂ ਨੂੰ ਢੋਂਦਾ ਹੈ ਅਤੇ ਉਹ ਮੁੱਲ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ।
PPP ਉੱਪਰ ਆਉਣ ਤੋਂ ਬਾਅਦ ਕਾਲੇ ਮੋਰੀ ਵਾਲਾ MTU ਮਰੀ ਸੁਰੰਗ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ: ਛੋਟੇ ਪੈਕਟ ਲੰਘਦੇ ਹਨ, TLS ਹੱਥ ਮਿਲਾਉਣਾ ਜਾਂ ਪੰਨਾ ਲੋਡ ਅਟਕ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਕਨੈਕਟਿਡ ਦਿਖਾ ਸਕਦਾ ਹੈ। ਸਰਵਰ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਇੰਟਰਫੇਸ MTU ਘਟਾਓ ਜਾਂ ਗੇਟਵੇ 'ਤੇ MSS ਕੱਸੋ। ਵੰਡੀ ਸੁਰੰਗ ਰਾਊਟਿੰਗ ਦੂਜਾ ਧੋਖੇਬਾਜ਼ ਹੈ; ਗਲਤ ਮਾਸਕ ਨਾਲ ਭੇਜੀ ਸਬਨੈੱਟ ਸੁਰੰਗ ਨੂੰ ਸਿਹਤਮੰਦ ਅਤੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਪਹੁੰਚ ਰੱਖਦੀ ਹੈ। ਨਿੱਜੀ ਹੋਸਟਨਾਮ ਆਪਣਾ ਕਦਮ ਜੋੜਦਾ ਹੈ: ਜੇ ਕਵੈਰੀ ਸਥਾਨਕ ਹੱਲਕਰਤਾ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕੋਈ ਵੀ ਰਾਊਟ ਜਾਂਚੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ।
ਪ੍ਰਮਾਣਪੱਤਰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਜਾਂਚ-ਸੂਚੀ
ਸੂਚੀ ਕ੍ਰਮ ਨਾਲ ਕਰੋ ਅਤੇ ਪਹਿਲੀ ਫੇਲ੍ਹ ਵਸਤੂ 'ਤੇ ਰੁਕੋ। ਹਰ ਕਦਮ ਸਸਤਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਸੋਧਾਂ ਦਾ ਪੂਰਾ ਵਰਗ ਬਾਹਰ ਕਰਦਾ ਹੈ।
- ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੰਬੰਧ ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਹੈ, ਜੁੜਿਆ ਲੇਬਲ ਨਹੀਂ ਸਗੋਂ ਸਾਥੀ ਦੀ ਪਛਾਣ ਨਾਲ ਮਿਲਾਇਆ।
- ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ UDP 1701 xl2tpd ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ; ਕਾਲ ਬਿਨਾਂ ਸੰਬੰਧ ਹੀ ਤੁਹਾਡਾ ਨੁਕਸ ਹੈ।
- ਪਾਸਵਰਡ ਗਲਤ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ PPP ਦਾ ਫੈਸਲਾ, ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਹੋਇਆ ਤਾਂ IPCP ਦਾ ਨਤੀਜਾ ਪੜ੍ਹੋ।
- ਹੁਣ ਹੀ ਪ੍ਰਮਾਣਪੱਤਰ ਸਰਵਰ ਵੱਲੋਂ ਉਮੀਦ ਕੀਤੇ ਫਾਰਮੈਟ ਵਿੱਚ ਦੁਬਾਰਾ ਪਾਓ, ਕਿਉਂਕਿ ਡੋਮੇਨ ਉਪਸਰਗ ਖਾਤਾ ਬਦਲਦਾ ਹੈ।
- ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ ਤਾਂ ਦੋਵੇਂ ਸਿਰੇ ਸੰਰੇਖਿਤ ਸਮਾਂ-ਛਾਪਾਂ ਨਾਲ ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਪੜਾਅ-ਦਰ-ਪੜਾਅ ਤੁਲਨਾ ਕਰੋ।
ਦੂਜੇ ਕਦਮ 'ਤੇ ਰੁਕਣਾ ਭਾਵ ਪਥ ਜਾਂ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਸਮੱਸਿਆ, ਅਤੇ ਪਾਸਵਰਡ ਦੀ ਕੋਈ ਸੋਧ ਉਸ ਨੂੰ ਨਹੀਂ ਹਿਲਾਏਗੀ। ਤੀਜੇ ਕਦਮ 'ਤੇ ਰੁਕਣਾ ਭਾਵ ਲੌਗ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਕਰਨ ਵਾਲੀ ਵਿਧੀ ਜਾਂ ਪਤਾ-ਪੂਲ ਦਾ ਨਾਮ ਲੈ ਚੁੱਕਾ ਹੈ। ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ ਅਗਲਾ ਬਦਲਾਅ ਉਹ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਜਾਇਜ਼ ਠਹਿਰਾ ਸਕੋ, ਅਤੇ ਤੁਸੀਂ ਕਦੇ ਸ਼ਾਮਲ ਨਾ ਹੋਈਆਂ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਘੁੰਮਣਾ ਛੱਡ ਦਿੰਦੇ ਹੋ।