L2TP, GRE ਜਾਂ IPsec: ਸੈਸ਼ਨ ਕਿਹੜੀ ਪਰਤ ਚੁੱਕਣੀ ਚਾਹੀਦੀ ਹੈ?
L2TP PPP ਸੈਸ਼ਨ ਚੁੱਕਦਾ ਹੈ, GRE ਰੂਟ ਕੀਤੇ ਪੈਕਟ, IPsec ਚੁਣੀ ਟ੍ਰੈਫਿਕ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ। ਹਰ ਪਰਤ ਨੂੰ ਇੱਕ ਕੰਮ ਦਿਓ, ਫਿਰ ਹਰ ਇੱਕ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ।
ਇੱਕੋ ਡਿਜ਼ਾਈਨ ਨੋਟ ਵਿੱਚ L2TP, GRE ਅਤੇ IPsec ਇਕੱਠੇ ਆਉਣ 'ਤੇ ਦੋ ਸਵਾਲ ਉਲਝ ਜਾਂਦੇ ਹਨ: ਮੈਂ ਕਿਹੜਾ ਸੈਸ਼ਨ ਚੁੱਕ ਰਿਹਾ ਹਾਂ, ਅਤੇ ਇਸਨੂੰ ਕਿਹੜੀ ਪਰਤ ਸੁਰੱਖਿਅਤ ਕਰਦੀ ਹੈ? ਪਹਿਲਾ ਗ਼ਲਤ ਹੋਇਆ ਤਾਂ ਹੇਠਾਂ ਦਾ ਸਭ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਸੁਸੰਗਤ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਗ਼ਲਤ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਾ ਹੈ — ਜਿੱਥੇ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਡਾਇਲ-ਇਨ ਕਰਨ ਦੀ ਲੋੜ ਸੀ ਉੱਥੇ ਬਣਾਇਆ ਰੂਟ ਕੀਤਾ ਓਵਰਲੇ, ਜਾਂ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਗੇਟਵੇ ਦੀ ਥਾਂ ਖੜ੍ਹਾ ਡਾਇਲ-ਇਨ ਕੇਂਦਰ। ਹੇਠਾਂ ਦਿੱਤਾ ਵਰਕਸ਼ੀਟ ਕਿਸੇ ਦੇ ਵੀ ਜੰਤਰ ਵਿੱਚ ਲੌਗਇਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫ਼ਰਕ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਭਰੋ ਅਤੇ ਹਰ ਲਾਈਨ ਆਪਣੇ ਆਪ ਵਿੱਚ ਜਾਂਚਣਯੋਗ ਚੀਜ਼ ਬਣ ਜਾਂਦੀ ਹੈ।
ਪ੍ਰੋਟੋਕੋਲ ਸੂਚੀ ਤੋਂ ਨਹੀਂ, ਸੈਸ਼ਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ
PPP ਸੈਸ਼ਨ ਰੱਖਣ ਵਾਲਾ ਦੂਰਸਥ ਵਰਤੋਂਕਾਰ ਅਤੇ ਦੋ ਗੇਟਵੇ ਵਿਚਕਾਰ ਰੂਟ ਕੀਤਾ ਓਵਰਲੇ ਦੋਵੇਂ ਅੰਤ ਵਿੱਚ IPsec ਵਿੱਚ ਲਿਪਟੇ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਵੱਖਰੇ ਜਾਲੀ ਸੰਬੰਧ ਹਨ। ਪਹਿਲਾ ਹਰ ਵਰਤੋਂਕਾਰ ਦੀ ਲਿੰਕ ਖ਼ਤਮ ਕਰਦਾ ਹੈ ਅਤੇ ਪਤਾ ਵੰਡ, ਵਿਅਕਤੀ ਜਾਂ ਜੰਤਰ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ, ਅਤੇ ਉਹ ਵਰਤੋਂਕਾਰ ਕਿਹੜੇ ਅੰਦਰੂਨੀ ਜਾਲਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਇਹ ਨਾਮ ਦੇਣ ਵਾਲੀ ਨੀਤੀ ਲੋੜਦਾ ਹੈ। ਦੂਜਾ ਉਹਨਾਂ ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਪੈਕਟ ਅੱਗੇ ਭੇਜਦਾ ਹੈ ਜਿੱਥੇ ਕੋਈ ਡਾਇਲ-ਇਨ ਨਹੀਂ ਕਰਦਾ।
ਤੁਸੀਂ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਬਣਾ ਰਹੇ ਹੋ ਇਹ ਨਾਮ ਦੇਣ ਵਾਲਾ ਇੱਕ ਵਾਕ ਲਿਖੋ, ਫਿਰ ਇਸਨੂੰ ਉਸ ਵਿਅਕਤੀ ਵਾਂਗ ਪੜ੍ਹੋ ਜਿਸਨੂੰ ਇਸਨੂੰ ਚਲਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਜੇ ਵਾਕ ਨੂੰ «ਅਤੇ» ਸ਼ਬਦ ਦੀ ਲੋੜ ਹੈ, ਤੁਸੀਂ ਦੋਵੇਂ ਬਣਾ ਰਹੇ ਹੋ, ਅਤੇ ਵਰਕਸ਼ੀਟ ਨੂੰ ਹਰ ਇੱਕ ਨੂੰ ਅੱਧੀ ਸੇਵਾ ਦੇਣ ਵਾਲੇ ਇੱਕ ਸਮਝੌਤਾ ਕਾਲਮ ਦੀ ਥਾਂ ਦੋ ਕਾਲਮ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਇਹ ਵਰਤੋਂਕਾਰ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਪਰ ਪਤਾ ਪੂਲ ਨਹੀਂ, ਜਾਂ ਅਗੇਤਰ ਦਿੰਦਾ ਹੈ ਪਰ ਅੱਗੇ ਭੇਜਣ ਦੀ ਨੀਤੀ ਨਹੀਂ, ਤਾਂ ਵਾਕ ਹਾਲੇ ਅਧੂਰਾ ਹੈ। ਸ਼ਬਦਾਵਲੀ ਨੌਕਰਸ਼ਾਹੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਨਹੀਂ ਤਾਂ ਸਹਾਇਤਾ ਡੈਸਕ ਟਿਕਟ ਰਾਹੀਂ ਲੱਭਣ ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਫੜਨ ਦੀ ਸਭ ਤੋਂ ਸਸਤੀ ਥਾਂ ਇਹੀ ਹੈ।
ਹਰ ਪਰਤ ਨੂੰ ਠੀਕ ਇੱਕ ਕੰਮ ਦਿਓ
L2TPv2 ਆਪਣੇ ਦੋ ਸਿਰੇ ਬਿੰਦੂਆਂ ਵਿਚਕਾਰ PPP ਸੈਸ਼ਨ ਚੁੱਕਦਾ ਹੈ। PPP ਲਿੰਕ ਗੱਲਬਾਤ ਅਤੇ ਉਹ ਗੱਲਬਾਤ ਹੋਣ 'ਤੇ ਵਰਤੋਂਕਾਰ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਚਲਾਉਂਦਾ ਹੈ; L2TP ਕੋਈ ਗੁਪਤਲੇਖਨ ਨਹੀਂ ਜੋੜਦਾ, ਇਸ ਲਈ ਨਿਰਾ L2TP ਡੈਮਨ IPsec ਸੁਰੱਖਿਆ ਸੰਬੰਧ ਦਾ ਕੋਈ ਵੀ ਹਿੱਸਾ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਸਿਰਫ਼ ਉਸ ਲਿੰਕ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਭਰੋਸਾ ਕਰਦੇ ਹੋ।
GRE ਦੋ ਪਤਿਆਂ ਵਿਚਕਾਰ ਆਵਰਣ ਹੈ। ਇਹ ਜਾਲੀ ਪਰਤ ਦੇ ਪੈਕਟ ਤਾਰਕਿਕ ਓਵਰਲੇ ਰਾਹੀਂ ਚੁੱਕਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਨਾ ਗੋਪਨੀਯਤਾ ਨਾ ਪ੍ਰਮਾਣਿਤ ਸਾਥੀ ਪਛਾਣ ਦਿੰਦਾ ਹੈ। ਇਹ ਕਮੀ ਨਹੀਂ: ਸਿਰਲੇਖ ਸਧਾਰਨ ਰੱਖਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਤਾਂ ਜੋ ਅੱਗੇ ਭੇਜਣ ਵਾਲੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਸਸਤੀ ਰਹੇ। ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ GRE ਸਿਰਫ਼ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਕਿ ਇਸ ਪੈਕਟ ਨੂੰ ਦੋ ਪਤਿਆਂ ਵਿਚਕਾਰ ਕਿਵੇਂ ਲਿਜਾਣਾ ਹੈ, ਹੋਰ ਕਿਸੇ ਦਾ ਨਹੀਂ, ਅਤੇ ਇਸਨੂੰ ਪੁੱਛਣ ਵਾਲਾ ਸਵਾਲ ਠੀਕ ਉਹੀ ਹੈ।
ਫਿਰ IPsec ਪਰਤ ਰਹਿੰਦੀ ਹੈ ਜੋ ਟ੍ਰੈਫਿਕ ਚੁਣਦੀ ਹੈ, ਸਾਥੀਆਂ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦੀ ਹੈ ਅਤੇ ਜੋ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਕਿਹਾ ਗਿਆ ਉਸਨੂੰ ਗੁਪਤਲੇਖਿਤ ਕਰਦੀ ਹੈ। ਕਿਹੜੀ ਟ੍ਰੈਫਿਕ ਸੁਰੱਖਿਅਤ ਕਰਨੀ ਹੈ ਇਹ ਸੰਰਚਨਾ ਦਾ ਫ਼ੈਸਲਾ ਹੈ ਜੋ ਸਿਰਿਆਂ ਵੱਲੋਂ ਅਸਲ ਵਿੱਚ ਬਣਾਏ ਜਾਂਦੇ ਆਵਰਣ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ GRE ਦੇ ਬਾਹਰੀ ਪਤੇ ਲਈ ਲਿਖੀ ਨੀਤੀ ਅੰਦਰੂਨੀ ਅਗੇਤਰਾਂ ਲਈ ਲਿਖੀ ਨੀਤੀ ਨਾਲੋਂ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। GRE ਵਿਸ਼ੇਸ਼ਤਾ ਭਾਰ, GRE ਸਿਰਲੇਖ ਅਤੇ ਬਾਹਰੀ ਡਿਲੀਵਰੀ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਦਿੱਸਣਯੋਗ ਤੌਰ 'ਤੇ ਵੱਖ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਨੀਤੀ ਨੂੰ ਵੀ ਉਹੀ ਵੱਖਰਾਪਣ ਚਾਹੀਦਾ ਹੈ।
| Layer | Its one job | What it never does |
|---|---|---|
| PPP | Link negotiation, optional user authentication, address assignment | Protect traffic between gateways |
| L2TPv2 | Carry the PPP session between two endpoints | Encrypt or authenticate peers |
| GRE | Encapsulate network-layer packets between two addresses | Hide or authenticate the payload |
| IPsec | Authenticate peers and encrypt selected traffic | Carry a dial-in user session by itself |
ਸੰਰਚਨਾ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕਟ ਦਾ ਰਾਹ ਲਿਖੋ
ਇੱਕ ਪੈਕਟ ਲਓ ਅਤੇ ਜੁੜਨ ਵਾਲਾ ਹਰ ਸਿਰਲੇਖ ਜੁੜਨ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰੋ, ਅਤੇ ਇਸਨੂੰ ਜੋੜਨ ਵਾਲਾ ਜੰਤਰ ਨਾਮ ਦਿਓ। ਡਾਇਲ-ਇਨ ਵਰਤੋਂਕਾਰ ਲਈ ਇਹ ਆਮ ਤੌਰ 'ਤੇ IPsec ਅੰਦਰ L2TP ਅੰਦਰ PPP ਹੁੰਦਾ ਹੈ; ਸਾਈਟ ਓਵਰਲੇ ਲਈ ਇਹ IPsec ਅੰਦਰ GRE ਅੰਦਰ ਅੰਦਰੂਨੀ IP ਪੈਕਟ ਹੁੰਦਾ ਹੈ। ਜੇ ਦੋ ਜੰਤਰ ਇੱਕੋ ਸਿਰਲੇਖ ਜੋੜਦੇ ਹਨ, ਤੁਹਾਡੇ ਕੋਲ ਲੂਪ ਜਾਂ ਦੁੱਗਣੀ ਸੁਰੰਗ ਹੈ, ਅਤੇ ਕਿੰਨੀ ਵੀ ਨੀਤੀ ਸੋਧ ਕਰੋ ਇਹ ਸੁਧਰੇਗਾ ਨਹੀਂ।
ਉਹੀ ਸੂਚੀ MTU ਤੈਅ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਵਰਤਣਯੋਗ ਅੰਦਰੂਨੀ ਆਕਾਰ ਮਾਪੇ ਰਾਹ ਦੇ MTU ਵਿੱਚੋਂ ਹੁਣੇ ਗਿਣੇ ਸਿਰਲੇਖ ਘਟਾਉਣ 'ਤੇ ਬਚਦਾ ਹੈ, ਹੋਰ ਕੁਝ ਨਹੀਂ। ਫੋਰਮ ਪੋਸਟ ਤੋਂ ਸੰਖਿਆ ਨਕਲ ਨਾ ਕਰੋ: ਬਾਹਰੀ IP, UDP ਅਤੇ ESP ਦਾ ਖ਼ਰਚ, ਫਿਰ GRE ਜਾਂ L2TP, ਫਿਰ ਜਿੱਥੇ ਲਾਗੂ ਹੋਵੇ PPP ਜੋੜੋ, ਅਤੇ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਮਾਪੇ ਰਾਹ ਦੇ MTU ਵਿੱਚੋਂ ਘਟਾਓ। ਸਿਰਫ਼ ਵੱਡੇ ਟ੍ਰਾਂਸਫਰਾਂ 'ਤੇ ਦਿੱਸਣ ਵਾਲੇ ਲੱਛਣ, ਜਾਂ ਸਥਾਪਿਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪਹਿਲੇ ਵੱਡੇ ਜਵਾਬ 'ਤੇ ਮਰਨ ਵਾਲੇ ਸੈਸ਼ਨ, ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਜੋੜ ਦੇ ਅੰਦਾਜ਼ੇ ਨਾਲ ਕੀਤੇ ਜਾਣ ਵੱਲ ਮੁੜਦੇ ਹਨ।
ਹਰ ਪਰਤ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਬਾਹਰ ਤੋਂ ਅੰਦਰ ਜਾਂਚੋ
ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਚਲਾਓ ਅਤੇ ਪਹਿਲੀ ਅਸਫਲ 'ਤੇ ਰੁਕੋ। ਹਰ ਲਾਈਨ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਅਸਫਲਤਾ ਸੁਰੰਗ ਟੁੱਟੀ ਹੋਣ ਦੀ ਥਾਂ ਵਰਕਸ਼ੀਟ ਦੇ ਇੱਕ ਕਾਲਮ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।
ip xfrm state # is the IPsec SA up?
ip -s link show gre1 # does the overlay interface carry packets?
ip route get 10.20.0.5 # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500" # are the L2TP and NAT-T listeners bound?Cisco ਬਾਕਸ 'ਤੇ ਬਰਾਬਰ ਦੀ ਚੀਜ਼ ਭੂਮਿਕਾ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਅਤੇ ਸਹੀ ਵਾਕਬਣਤਰ ਪਲੇਟਫਾਰਮ ਅਤੇ ਰਿਲੀਜ਼ 'ਤੇ ਨਿਰਭਰ ਹੈ: IPsec ਸਾਥੀਆਂ ਲਈ show crypto session, GRE ਜਾਂ ਸੁਰੰਗ ਇੰਟਰਫ਼ੇਸ ਲਈ ਇੰਟਰਫ਼ੇਸ ਗਿਣਤੀ, ਅਤੇ ਡਾਇਲ-ਇਨ ਭੂਮਿਕਾ ਲਈ VPDN ਜਾਂ PPP ਪੜਤਾਲ। PPP ਖ਼ਤਮ ਕਰਨ ਵਾਲਾ ਹੁਕਮ ਸਮੂਹ GRE ਸਮਰਥਨ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਕੰਮ ਕਰਦਾ GRE ਇੰਟਰਫ਼ੇਸ PPP ਸੇਵਾ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਚਿੱਤਰ ਵਾਲੀ ਨਹੀਂ, ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਸੰਰਚਿਤ ਕੀਤੀ ਭੂਮਿਕਾ ਜਾਂਚੋ।
ਹਰ ਆਉਟਪੁੱਟ ਨੂੰ ਉਸ ਵਰਕਸ਼ੀਟ ਲਾਈਨ ਦੇ ਕੋਲ ਦਰਜ ਕਰੋ ਜਿਸ ਨਾਲ ਇਹ ਸੰਬੰਧਿਤ ਹੈ। ਖ਼ਰਾਬੀ ਸਰਗਰਮ ਹੁੰਦਿਆਂ ਲਏ ਨੋਟ ਬਾਅਦ ਵਿੱਚ ਯਾਦ ਤੋਂ ਮੁੜ ਖਿੱਚੀ ਟੋਪੋਲੋਜੀ ਨਾਲੋਂ ਵਧੇਰੇ ਕੀਮਤੀ ਹੁੰਦੇ ਹਨ।
ਤੋੜਨ ਦਾ ਕ੍ਰਮ ਸੈੱਟ ਕਰੋ, ਫਿਰ ਮੁੜ ਜਾਂਚੋ
ਤੋੜਨ ਦਾ ਕੰਮ ਉਲਟ ਕ੍ਰਮ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਕਾਰਨ ਹੈ: ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫਿਕ ਨੂੰ IPsec ਨੀਤੀ ਵਿੱਚੋਂ ਬਾਹਰ ਕੱਢੋ, ਉਸ ਲਈ ਲਿਖੇ ਆਵਰਣ ਨੂੰ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਨਹੀਂ ਤਾਂ ਨੀਤੀ ਹੁਣ ਨਾ ਰਹੇ ਇੰਟਰਫ਼ੇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਅਗਲੀ ਸੰਰਚਨਾ ਲੋਡ ਅਸੰਬੰਧਿਤ ਦਿੱਸਣ ਵਾਲੀ ਥਾਂ 'ਤੇ ਅਸਫਲ ਹੁੰਦੀ ਹੈ। Linux 'ਤੇ ਇਸ ਦਾ ਅਰਥ ਸੁਰੰਗ ਇੰਟਰਫ਼ੇਸ ਤੋਂ ਪਹਿਲਾਂ ਸਥਿਤੀ ਅਤੇ ਨੀਤੀ ਐਂਟਰੀ ਮਿਟਾਉਣਾ; ਰਾਊਟਰ 'ਤੇ, ਸੁਰੰਗ ਤੋਂ ਪਹਿਲਾਂ ਕ੍ਰਿਪਟੋ ਨਕਸ਼ਾ ਜਾਂ ਪਰੋਫ਼ਾਈਲ ਐਂਟਰੀ ਹਟਾਉਣਾ।
ਮੁੜ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ, ਮਨਜ਼ੂਰੀ ਦੇ ਚਾਰ ਨਿਰੀਖਣ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਦੁਹਰਾਓ: ਬਾਹਰੀ ਪਹੁੰਚ, ਸਥਾਪਿਤ IPsec ਸੰਘ, ਜਿੱਥੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ ਉੱਥੇ ਸਥਾਪਿਤ PPP ਸੈਸ਼ਨ, ਅਤੇ ਅਸਲ ਮੰਜ਼ਿਲ ਪਤੇ ਤੱਕ ਅੰਦਰੂਨੀ ਅੱਗੇ ਭੇਜਣਾ। ਇੱਕ ਹਰੀ ਬੱਤੀ ਬਾਕੀ ਤਿੰਨ ਲਈ ਸਬੂਤ ਨਹੀਂ, ਅਤੇ ਉਹੀ ਖੱਪਾ ਉਤਪਾਦਨ ਵਿੱਚ ਸਭ ਤੋਂ ਲੰਮਾ ਟਿਕਣ ਵਾਲੀ ਅਸਫਲਤਾ ਹੈ — ਸੁਰੰਗ ਚਾਲੂ, ਗੁਪਤਲੇਖਿਤ, ਅਤੇ ਕੁਝ ਵੀ ਅੱਗੇ ਨਾ ਭੇਜਣਾ, ਕਿਉਂਕਿ ਅੰਦਰੂਨੀ ਰਾਹ ਕਦੇ ਨਹੀਂ ਜੋੜਿਆ ਗਿਆ।
ਭਰੀ ਵਰਕਸ਼ੀਟ ਨੂੰ ਜੰਤਰ ਦੀ ਸੰਰਚਨਾ ਦੇ ਕੋਲ ਰੱਖੋ। ਤੁਸੀਂ ਨਾ ਭਰ ਸਕਣ ਵਾਲਾ ਕੋਈ ਵੀ ਕਾਲਮ ਕੰਮ ਨਾ ਦਿੱਤੀ ਪਰਤ ਹੈ, ਅਤੇ ਕੰਮ ਤੋਂ ਬਿਨਾਂ ਪਰਤ ਆਮ ਤੌਰ 'ਤੇ ਅਜਿਹੀ ਪਰਤ ਹੈ ਜੋ ਸਟੈਕ ਵਿੱਚ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।