ਇੱਕ Pi 'ਤੇ ਦੋ VPN ਹੌਪ: ਕਿਹੜਾ ਰੂਟ ਕਿਹੜੇ ਪੀਅਰ ਨੂੰ ਢੋਂਦਾ ਹੈ
ਇੱਕ Pi 'ਤੇ ਦੋ ਟਨਲ ਪਤੇ ਕੋਈ ਖਰਾਬੀ ਨਹੀਂ। ਹਰ ਮੰਜ਼ਿਲ ਨੂੰ ਆਪਣਾ ਢੋਣ ਵਾਲਾ, ਆਪਣਾ ਸਬੂਤ ਅਤੇ ਬਾਹਰੀ ਹੌਪ ਮਰਨ 'ਤੇ ਘੋਸ਼ਿਤ ਬੈਕਅਪ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਛੋਟੇ ਬੋਰਡ 'ਤੇ ਦੋ ਟਨਲ ਪਤੇ ਗਲਤੀ ਵਾਂਗ ਲੱਗਦੇ ਹਨ, ਅਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਇੱਕ ਮਿਟਾਉਣ ਦੀ ਹੁੰਦੀ ਹੈ। ਉਹ ਪ੍ਰਤੀਕਿਰਿਆ ਉਸੇ ਚੀਜ਼ ਨੂੰ ਤੋੜਦੀ ਹੈ ਜਿਸਨੂੰ ਸੰਭਾਲਣਾ ਸੀ। ਦੋ ਹੌਪ ਢੋਣ ਵਾਲਾ ਹੋਸਟ ਹਰ ਜੁੜਾਅ ਲਈ ਇੱਕ ਪਤਾ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਹਰ ਪਤਾ ਵੱਖਰੇ ਰੂਟ ਨਾਲ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ। ਪੁੱਛਣ ਯੋਗ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕਿਹੜਾ ਰੂਟ ਕਿਹੜੀ ਮੰਜ਼ਿਲ ਲਈ ਕਿਹੜਾ ਢੋਣ ਵਾਲਾ ਚੁਣਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਕਿੰਨੇ ਪਤੇ ਹਨ।
ਵੱਖਰੇ ਢੋਣ ਵਾਲੇ ਚਾਹੁੰਦੀਆਂ ਤਿੰਨ ਮੰਜ਼ਿਲਾਂ
ਦੋ ਹੌਪ ਦੀ ਲੜੀ ਇੱਕ ਉੱਤੇ ਇੱਕ ਰੱਖੀਆਂ ਤਿੰਨ ਮੰਜ਼ਿਲ ਸ਼੍ਰੇਣੀਆਂ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਵੱਖਰਾ ਜੁੜਾਅ ਢੋਂਦਾ ਹੈ। ਬਾਹਰੀ ਪੀਅਰ ਤੱਕ ਭੌਤਿਕ ਲਿੰਕ ਰਾਹੀਂ ਪਹੁੰਚਣਾ ਪੈਂਦਾ ਹੈ। ਅੰਦਰਲੇ ਪੀਅਰ ਤੱਕ ਬਾਹਰੀ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਣਾ ਪੈਂਦਾ ਹੈ। ਢਕੀ ਹੋਈ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਮੰਜ਼ਿਲ ਤੱਕ ਅੰਦਰਲੇ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਣਾ ਪੈਂਦਾ ਹੈ, ਜਿਸਦੀ ਆਪਣੀ ਢੁਆਈ ਬਾਹਰੀ ਟਨਲ ਢੋਂਦਾ ਹੈ।
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
ਰੂਟ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਕਤਾਰਾਂ ਨੂੰ ਪਾਠਕ ਦੇ ਅਸਲੀ ਪਤਿਆਂ ਨਾਲ ਭਰੋ, ਕਿਉਂਕਿ ਸਾਰਣੀ ਉਦੋਂ ਹੀ ਲਾਭਦਾਇਕ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਉਹ ਠੋਸ ਹੋਵੇ। ਕੰਮ ਕਰਨ ਵਾਲੀ ਲੜੀ ਚਾਰੇ ਕਤਾਰਾਂ ਇੱਕੋ ਸਮੇਂ ਪੂਰੀਆਂ ਕਰਦੀ ਹੈ, ਅਤੇ ਅੱਧੀ ਕੰਮ ਕਰਨ ਵਾਲੀ ਲੜੀ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਗਲਤ ਢੋਣ ਵਾਲੇ ਨਾਲ ਪੂਰੀ ਕਰਦੀ ਹੈ। ਗਲਤ ਕਤਾਰ ਨੂੰ ਖਰਾਬੀ ਵਜੋਂ ਪੜ੍ਹਨਾ ਹੀ ਰੂਟਿੰਗ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਪੂਰੀ ਦੁਪਹਿਰ ਦੇ ਸੋਧਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
ਪਤਿਆਂ ਦੀ ਗਿਣਤੀ ਨਹੀਂ, ਭੂਮਿਕਾ ਹੁੰਦੀ ਹੈ
ਲਿਨਕਸ ਇੱਕ ਇੰਟਰਫੇਸ 'ਤੇ ਕਈ ਪਤੇ ਅਤੇ ਇੱਕ ਹੋਸਟ 'ਤੇ ਕਈ ਟਨਲ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਗਿਣਤੀ ਸ਼ੁੱਧਤਾ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ। ਮਹੱਤਵਪੂਰਨ ਇਹ ਹੈ ਕਿ ਕਿਹੜਾ ਪਤਾ ਕਿਹੜੇ ਜੁੜਾਅ ਦਾ ਹੈ, ਅਤੇ ਕੀ ਦਿੱਤੇ ਪੀਅਰ ਲਈ ਰੂਟ ਤੁਹਾਡੇ ਇਰਾਦੇ ਵਾਲਾ ਜੁੜਾਅ ਚੁਣਦਾ ਹੈ। ਤਿੰਨ ਦ੍ਰਿਸ਼ ਤਿੰਨ ਦਿਸ਼ਾਵਾਂ ਤੋਂ ਇਸਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਹਰ ਵਾਰ ਉਨ੍ਹਾਂ ਨੂੰ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ।
ਪਤਾ ਸੂਚੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕੀ ਹੈ ਅਤੇ ਕਿਹੜਾ ਜੁੜਾਅ ਇਸਦਾ ਮਾਲਕ ਹੈ। ਰੂਟ ਸਾਰਣੀ ਆਮ ਮੰਜ਼ਿਲ ਟ੍ਰੈਫਿਕ ਲਈ ਢੋਣ ਵਾਲੇ ਦਾ ਸਵਾਲ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਨੀਤੀ ਦ੍ਰਿਸ਼ ਸਰੋਤ ਜਾਂ ਨਿਸ਼ਾਨ ਨਾਲ ਚੁਣੇ ਟ੍ਰੈਫਿਕ ਲਈ ਦੁਬਾਰਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਦੋ ਕਲਾਇੰਟ ਇੱਕ ਹੋਸਟ ਸਾਂਝਾ ਕਰਦੇ ਹੋਣ ਤਾਂ ਇਹ ਆਮ ਪ੍ਰਬੰਧ ਹੈ।
ip -4 addr show
ip -4 route show table all
ip rule showਸੂਚੀ ਲੰਮੀ ਲੱਗਦੀ ਹੈ ਕਿਉਂਕਿ ਪਤਾ ਮਿਟਾਉਣਾ ਰਾਹ ਦਾ ਹਿੱਸਾ ਹਟਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਵਾਧੂ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਰੂਟ ਮਿਟਾਉਣਾ ਉਹੀ ਕੰਮ ਹੋਰ ਚੁੱਪ ਨਾਲ ਕਰਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਤਰੁੱਟੀ ਨਹੀਂ ਦਿੰਦਾ; ਪੀਅਰ ਬੱਸ ਤੁਹਾਡੇ ਇਰਾਦੇ ਵਾਲੇ ਰਾਹ 'ਤੇ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਦੂਜੇ ਰਾਹ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਰਹਿੰਦਾ ਹੈ। ਅੰਦਰਲੇ ਪੀਅਰ ਦਾ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪਤਾ ਦੱਸਣ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਟ੍ਰੈਫਿਕ ਬਾਹਰੀ ਟਨਲ ਵਿੱਚੋਂ ਲੰਘਿਆ, ਕਿਉਂਕਿ ਸਿੱਧੀ ਪਹੁੰਚ ਉਹੀ ਨਿਰੀਖਣ ਦਿੰਦੀ ਹੈ। ਨਿਰੀਖਣ ਅਤੇ ਸਬੂਤ ਵਿਚਕਾਰ ਇਹੀ ਖਾਲੀ ਥਾਂ ਰੂਟਿੰਗ ਪਰਤ 'ਤੇ ਢੋਣ ਵਾਲੇ ਦੀ ਜਾਂਚ ਦਾ ਕਾਰਨ ਹੈ।
ਸਰਗਰਮੀ ਦਾ ਕ੍ਰਮ ਨਿਸ਼ਚਤ ਉਡੀਕ ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ
ਜੇ ਅੰਦਰਲਾ ਕਲਾਇੰਟ ਬਾਹਰੀ ਕਲਾਇੰਟ ਵੱਲੋਂ ਦਿੱਤੇ ਪਤੇ ਜਾਂ ਰੂਟ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਸਰਗਰਮੀ ਨੂੰ ਦੇਰੀ ਦੀ ਬਜਾਏ ਉਸ ਸਰੋਤ ਦੀ ਉਡੀਕ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਉਡੀਕ ਉਸ ਦਿਨ ਤੱਕ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਬਾਹਰੀ ਟਨਲ ਹੌਲੀ ਹੋਵੇ, ਅਤੇ ਫਿਰ ਇਹ ਉਸ ਤਰੀਕੇ ਨਾਲ ਵਾਰ-ਵਾਰ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾ ਸਕਦਾ। ਨਿਰਭਰਤਾ-ਅਧਾਰਿਤ ਕ੍ਰਮ ਅੰਦਾਜ਼ਾ ਹਟਾਉਂਦਾ ਹੈ ਅਤੇ ਨਿਰਭਰਤਾ ਇੱਕ ਵਾਰ ਦੱਸਣ ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਖਰਚ ਨਹੀਂ ਕਰਦਾ। ਇੰਟਰਫੇਸ ਨਾਮ ਵੀ ਕ੍ਰਮ ਦਾ ਤੰਤਰ ਨਹੀਂ ਹਨ।
ਕਰਨਲ tun0 ਅਤੇ tun1 ਵਰਗੇ ਨਾਮ ਬਣਾਉਣ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਕ੍ਰਮ ਰੀਬੂਟ ਜਾਂ ਦੁਬਾਰਾ ਜੁੜਨ ਵਿਚਕਾਰ ਬਦਲ ਸਕਦਾ ਹੈ। ਸੰਰਚਨਾ ਨੂੰ ਟੂਲ ਵੱਲੋਂ ਦਿੱਤੀ ਪਛਾਣ ਜਾਂ ਤੁਹਾਡੇ ਵੱਲੋਂ ਜਾਣਬੁੱਝ ਕੇ ਦਿੱਤੇ ਨਾਮ ਨਾਲ ਬੰਨ੍ਹੋ। ਤੁਸੀਂ ਚੁਣਿਆ ਨਾਮ ਇਕਰਾਰ ਹੈ; ਕਰਨਲ ਚੁਣਿਆ ਨਾਮ ਸੰਜੋਗ ਹੈ।
ਹਰ ਕਲਾਇੰਟ ਦੀ ਢੁਆਈ ਨੂੰ ਦੂਜੇ ਦੇ ਐਪਲੀਕੇਸ਼ਨ ਰੂਟ ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਅਤੇ OpenVPN 2.6 ਰੂਟਿੰਗ ਵਿਕਲਪ ਅਸਲ ਵਿੱਚ ਕੀ ਵਾਅਦਾ ਕਰਦੇ ਹਨ ਇਸ ਬਾਰੇ ਸਟੀਕ ਰਹੋ। ਦਸਤਾਵੇਜ਼ੀ ਡਿਫਾਲਟ ਰੀਡਾਇਰੈਕਸ਼ਨ ਤੰਤਰ ਕਲਾਇੰਟ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਗੇਟਵੇ ਰਾਹੀਂ ਆਪਣੇ ਦੂਰਲੇ ਪੀਅਰ ਤੱਕ ਪਹੁੰਚਣ ਦੇ ਯੋਗ ਰੱਖਦਾ ਹੈ, ਜੋ ਇੱਕ ਖਾਸ ਦੁਹਰਾਉ ਲੂਪ ਕੱਟਦਾ ਹੈ। ਇਹ ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਦੂਜੇ ਦਾ ਢੋਣ ਵਾਲਾ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਇਸ ਲਈ ਲੜੀ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਤੁਹਾਡਾ ਡਿਜ਼ਾਈਨ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਜਿੱਥੇ ਲੜੀ ਨੂੰ ਰੂਟ ਦੀ ਬਜਾਏ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ, ਉੱਥੇ ਸਪਸ਼ਟ ਸਰੋਤ ਜਾਂ ਨਿਸ਼ਾਨ ਨਿਯਮ ਲਿਖੋ ਅਤੇ ਉਸ ਟ੍ਰੈਫਿਕ ਨਾਲ ਪਰਖੋ ਜਿਸ ਨਾਲ ਇਸਨੂੰ ਮੇਲ ਖਾਣਾ ਹੈ।
ਬਾਹਰੀ ਹੌਪ ਮਰਨ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ
ਲੜੀ ਨੂੰ ਪੂਰਾ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਬਾਹਰੀ ਹੌਪ ਗਾਇਬ ਹੋਣ 'ਤੇ ਕੀ ਹੋਵੇਗਾ। ਅੰਦਰਲੇ ਕਲਾਇੰਟ ਦੀ ਢੁਆਈ ਉਸ ਨਾਲ ਮਰ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਤਕਨੀਕੀ ਨਹੀਂ, ਨੀਤੀ ਦਾ ਸਵਾਲ ਹੈ: ਫੇਲ੍ਹ ਹੋਣਾ, ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ, ਜਾਂ ਭੌਤਿਕ ਲਿੰਕ ਰਾਹੀਂ ਸਿੱਧਾ ਦੁਬਾਰਾ ਜੁੜਨਾ। ਤੀਜਾ ਨਤੀਜਾ ਹੀ ਸੋਚਣ ਯੋਗ ਹੈ। ਜਿਸ ਪਲ ਵਰਤੋਂਕਾਰ ਮੰਨਦਾ ਹੈ ਕਿ ਕਵਰੇਜ ਅਜੇ ਵੀ ਅਟੁੱਟ ਹੈ, ਉਸੇ ਪਲ ਇਹ ਦੋ ਹੌਪ ਦੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਇੱਕ ਹੌਪ ਦੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਚੁੱਪ ਨਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਜੇ ਦੋ ਹੌਪ ਲਾਜ਼ਮੀ ਹਨ, ਤਾਂ ਬਾਹਰੀ ਦੇ ਜਾਣ 'ਤੇ ਅੰਦਰਲੇ ਕਲਾਇੰਟ ਨੂੰ ਸਿੱਧਾ ਰਾਹ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਅਤੇ ਇਹ ਜਾਣਨ ਦਾ ਤਰੀਕਾ ਬਾਹਰੀ ਹੌਪ ਤੋੜ ਕੇ ਅੰਦਰਲਾ ਕੀ ਕਰਦਾ ਹੈ ਵੇਖਣਾ ਹੈ। ਮਨਜ਼ੂਰ ਬੈਕਅਪ ਜਾਇਜ਼ ਜਵਾਬ ਹੈ, ਪਰ ਇਹ ਲਿਖਿਆ, ਪਰਖਿਆ ਅਤੇ ਦੱਸਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਿਸ ਬੈਕਅਪ ਨੂੰ ਕਿਸੇ ਨੇ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਕੀਤਾ, ਉਹ ਘਟਨਾ ਸਮੀਖਿਆ ਵਿੱਚ ਲੀਕ ਤੋਂ ਵੱਖ ਨਹੀਂ ਪਛਾਣਿਆ ਜਾ ਸਕਦਾ।
DNS ਅਤੇ ਦੂਜਾ ਪਤਾ ਪਰਿਵਾਰ ਉਸੇ ਫੈਸਲੇ ਦਾ ਹਿੱਸਾ ਹਨ। ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਬਣਾਈ ਖੋਜ ਹੋਸਟ ਦੀ ਆਪਣੀ ਨੀਤੀ ਦਾ ਪਾਲਣ ਕਰਦੀ ਹੈ, ਫਾਰਵਰਡ ਕੀਤੇ ਕਲਾਇੰਟ ਦੀ ਨਹੀਂ, ਇਸ ਲਈ ਫਾਰਵਰਡ ਟ੍ਰੈਫਿਕ ਲਈ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰਿਜ਼ੋਲਵਰ ਹੋਸਟ ਖੁਦ ਵਰਤਦਾ ਹੋਵੇ ਉਹ ਨਹੀਂ ਵੀ ਹੋ ਸਕਦਾ।
ਹਰ ਪਰਤ ਨੂੰ ਤੁਸੀਂ ਬਣਾਇਆ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਸਵੀਕਾਰ ਕਰੋ
ਲੜੀ ਜਿਸ ਕ੍ਰਮ ਵਿੱਚ ਬਣੀ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪਰਖੋ: ਪਹਿਲਾਂ ਇਕੱਲਾ ਬਾਹਰੀ ਟਨਲ, ਫਿਰ ਬਾਹਰੀ ਟਨਲ ਰਾਹੀਂ ਅੰਦਰਲੇ ਕਲਾਇੰਟ ਦੀ ਢੁਆਈ, ਫਿਰ ਅੰਦਰਲੇ ਟਨਲ ਰਾਹੀਂ ਐਪਲੀਕੇਸ਼ਨ। ਹਰ ਸਵੀਕ੍ਰਿਤੀ ਪਹਿਲਾਂ ਖੁੱਲ੍ਹਿਆ ਪੰਨਾ ਨਹੀਂ, ਨਵਾਂ ਜੁੜਾਅ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਹਰ ਪਰਤ ਨੂੰ ਵੱਖਰਾ ਤੋੜੋ ਅਤੇ ਬਹਾਲ ਕਰੋ ਅਤੇ ਵੇਖੋ ਅਗਲੀ ਕੀ ਕਰਦੀ ਹੈ।
ਬੈਕਅਪ ਦਾ ਨਤੀਜਾ ਇੱਥੇ ਸਭ ਤੋਂ ਕੀਮਤੀ ਨਿਰੀਖਣ ਹੈ, ਅਤੇ ਜੋ ਜਨਤਕ IP ਪੰਨਾ ਕਦੇ ਨਹੀਂ ਦਿਖਾਉਂਦਾ। ਪੀਅਰਾਂ ਦੇ ਰਾਹ, ਉਨ੍ਹਾਂ ਵੱਲੋਂ ਵਰਤੇ ਪਤੇ ਅਤੇ ਉਹ ਨਤੀਜਾ ਸੰਰਚਨਾ ਦੇ ਕੋਲ ਸੰਭਾਲੋ, ਕਿਉਂਕਿ ਸੁਖੀ ਰਾਹ ਉਹ ਹਿੱਸਾ ਨਹੀਂ ਜਿਸ 'ਤੇ ਬਾਅਦ ਵਿੱਚ ਸਵਾਲ ਉੱਠਦਾ ਹੈ।