VPN ਰੂਟ ਜਾਂ ਫਾਇਰਵਾਲ ਨਿਯਮ: ਪੈਕੇਟ ਕਿਹੜਾ ਡਿੱਗ ਰਿਹਾ ਹੈ?

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

ਦੋ ਫੈਸਲੇ, ਇੱਕ ਪੈਕੇਟ, ਦੋ ਮਾਲਕ

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

ਫਿਲਟਰਿੰਗ ਵੱਖਰੀ ਹੈ। Linux ਹੋਸਟ ਉੱਤੇ netfilter ਹੁੱਕ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇਸ ਆਧਾਰ ਉੱਤੇ ਵੰਡਦੇ ਹਨ ਕਿ ਪੈਕੇਟ ਕਿਸ ਲਈ ਹੈ: ਆਉਟਪੁੱਟ ਮਸ਼ੀਨ ਛੱਡਦਾ ਹੈ, ਇਨਪੁੱਟ ਉਸ ਉੱਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਫਾਰਵਰਡ ਉਸ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ। ਜੋ ਗੇਟਵੇ VPN ਕਲਾਇੰਟ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ LAN ਵੱਲ ਰੂਟ ਕਰਦਾ ਹੈ ਉਸਨੂੰ ਫਾਰਵਰਡ ਮਾਰਗ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਚੇਨ ਹੈ ਜਿਸਨੂੰ ਜ਼ਿਆਦਾਤਰ ਡਿਫਾਲਟ ਸੰਰਚਨਾਵਾਂ ਖਾਲੀ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ।

ਸਰੋਤ ਚੋਣ ਉਸੇ ਫੈਸਲੇ ਦਾ ਹਿੱਸਾ ਹੈ, ਅਤੇ ਇੱਥੇ ਹੀ ਜ਼ਿਆਦਾਤਰ ਅਸੰਗਤੀਆਂ ਲੁਕੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਕਰਨਲ ਆਉਟਗੋਇੰਗ ਇੰਟਰਫੇਸ ਤੋਂ ਸਰੋਤ ਪਤਾ ਚੁਣਦਾ ਹੈ ਜਦ ਤੱਕ ਰੂਟ ਇੱਕ ਨਾ ਦੱਸੇ, ਇਸ ਲਈ LAN ਸਬਨੈੱਟ ਲਈ ਲਿਖਿਆ ਫਿਲਟਰ ਨਿਯਮ ਟਨਲ ਪਤੇ ਨਾਲ ਨਿਕਲਦੇ ਪੈਕੇਟ ਨਾਲ ਕਦੇ ਨਹੀਂ ਮਿਲਦਾ।

ਪੜ੍ਹੋ ਕਿ ਖੋਜ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਚੁਣਿਆ

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

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

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

ਨੀਤੀ-ਆਧਾਰਿਤ IPsec ਇੱਕ ਤੀਜਾ ਮੇਲ ਪੜਾਅ ਜੋੜਦਾ ਹੈ ਜੋ ਰੂਟਿੰਗ ਕਵਰ ਨਹੀਂ ਕਰਦੀ, ਜਿਵੇਂ strongSwan ਦੇ ਫਾਰਵਰਡਿੰਗ ਨੋਟ ਟਨਲ ਅਤੇ ਆਵਾਜਾਈ ਸੈਟਅਪ ਲਈ ਦੱਸਦੇ ਹਨ। ਸੁਰੱਖਿਆ ਨੀਤੀ ਟ੍ਰੈਫਿਕ ਨੂੰ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ ਚੁਣਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਰੂਟ ਸਿਰਫ਼ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਅਸੁਰੱਖਿਅਤ ਪੈਕੇਟ ਕਿੱਥੇ ਜਾਵੇਗਾ। ਜੋ ਸਬਨੈੱਟ ਰੂਟ ਹੁੰਦਾ ਹੈ ਪਰ ਮੇਲ ਖਾਂਦਾ ਚੋਣਕਰਤਾ ਨਹੀਂ ਰੱਖਦਾ ਉਹ ਜਾਂ ਤਾਂ ਅਸੁਰੱਖਿਅਤ ਰਹਿੰਦਾ ਹੈ ਜਾਂ ਸੰਰਚਨਾ ਅਨੁਸਾਰ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਤੀਜਾ ਫਾਇਰਵਾਲ ਸਮੱਸਿਆ ਵਰਗਾ ਨਹੀਂ ਲੱਗਦਾ। ਨੀਤੀ ਛਾਪੋ ਅਤੇ ਇਸਦੇ ਚੋਣਕਰਤਾਵਾਂ ਦੀ ਤੁਲਨਾ ਉਹਨਾਂ ਪ੍ਰੀਫਿਕਸਾਂ ਨਾਲ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਉਮੀਦ ਕੀਤੀ ਸੀ ਕਿ ਟਨਲ ਉਹਨਾਂ ਨੂੰ ਲੈ ਕੇ ਜਾਵੇਗਾ।

ਫਿਲਟਰਿੰਗ ਹੁੱਕ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਰੂਟ ਉੱਤੇ ਨਹੀਂ

ਜੋ ਨਿਯਮ VPN ਸਰੋਤੇ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ ਉਹ ਗੇਟਵੇ ਆਪਣੇ ਆਪ ਨੂੰ ਸੰਬੋਧਿਤ ਟ੍ਰੈਫਿਕ ਬਾਰੇ ਨਿਯਮ ਹੈ। ਇਹ ਉਸ ਗੇਟਵੇ ਪਿੱਛੇ ਦੇ ਹੋਸਟਾਂ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਕਿਉਂਕਿ ਫਾਰਵਰਡ ਕੀਤਾ ਟ੍ਰੈਫਿਕ ਵੱਖਰੀ ਚੇਨ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ। ਨਿਯਮ ਸਮੂਹ ਨੂੰ ਇੱਕ ਸਮਤਲ ਸੂਚੀ ਵਜੋਂ ਪੜ੍ਹਨਾ ਹੀ ਉਹ ਆਮ ਕਾਰਨ ਹੈ ਕਿ ਸਹੀ ਲੱਗਦਾ ਨਿਯਮ ਕਦੇ ਸਰਗਰਮ ਨਹੀਂ ਹੁੰਦਾ।

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

ਕਲਾਇੰਟ ਜੋ ਰਾਹ ਵਰਤਦਾ ਹੈ ਉਸ ਰਾਹੀਂ ਪ੍ਰੋਬ ਭੇਜੋ

ਗੇਟਵੇ ਉੱਤੇ ਹੀ ਚਲਾਏ ਗਏ ਟੈਸਟ ਗੇਟਵੇ ਦੇ ਆਪਣੇ ਸਰੋਤ ਪਤੇ ਨਾਲ ਆਉਟਪੁੱਟ ਅਤੇ ਇਨਪੁੱਟ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ। ਇਹ ਕਲਾਇੰਟ ਦੀ ਫਾਰਵਰਡ ਕੀਤੀ ਬੇਨਤੀ ਤੋਂ ਵੱਖਰਾ ਰਾਹ ਹੈ, ਇਸ ਲਈ ਸਫਲ ਸਥਾਨਕ curl ਦਿਖਣ ਨਾਲੋਂ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਜਿਸ ਮਸ਼ੀਨ ਉੱਤੇ ਅਸਫਲਤਾ ਹੋਵੇ ਉਸ ਤੋਂ ਟੈਸਟ ਕਰੋ, ਜਾਂ ਇੰਟਰਫੇਸ ਅਤੇ ਸਰੋਤ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਪਿੰਨ ਕਰੋ।

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

ਲੌਗਿੰਗ ਪਹਿਲਾ ਕਦਮ ਨਹੀਂ, ਦੂਜੀ ਰਾਏ ਵਜੋਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਫਾਰਵਰਡ ਚੇਨ ਉੱਤੇ ਇੱਕ ਅਸਥਾਈ ਲੌਗ ਬਿਆਨ ਉਸ ਇੰਟਰਫੇਸ ਅਤੇ ਪਤਿਆਂ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ ਉਸਨੂੰ ਮਾਰਿਆ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਹਟਾਉਣਾ ਆਸਾਨ ਹੈ। ਇਸਨੂੰ ਸਥਾਈ ਛੱਡ ਦਿਓ ਅਤੇ ਤੁਸੀਂ ਜਵਾਬ ਦੀ ਬਜਾਏ ਲੌਗ ਵਾਲੀਅਮ ਦੀ ਸਮੱਸਿਆ ਬਣਾ ਲਈ ਹੈ।

ਹਰ ਬਦਲਾਅ ਨੂੰ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਉਹ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਟਿਕਦਾ ਹੈ

ip route add ਨਾਲ ਜੋੜਿਆ ਰੂਟ ਉਦੋਂ ਤੱਕ ਜੀਵਿਤ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇੰਟਰਫੇਸ ਹੇਠਾਂ ਨਹੀਂ ਜਾਂਦਾ। ਇਸਨੂੰ ਇਸਦੀ ਬਜਾਏ ਕਨੈਕਸ਼ਨ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਸੰਭਾਲੋ: NetworkManager ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਵਾਧੂ ਰੂਟ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ netplan ਉਹਨਾਂ ਨੂੰ ਬੂਟਾਂ ਵਿਚਕਾਰ ਰੱਖਦਾ ਹੈ। ਇਹੀ ਨਿਯਮ ਕਲਾਇੰਟ-ਸਾਈਡ ਫਾਇਰਵਾਲ ਅਪਵਾਦ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਜੋ ਅਗਲੇ ਰੀਲੋਡ ਤੋਂ ਬਾਅਦ ਚਲਾ ਜਾਂਦਾ ਹੈ।

ਸਰਵਰ-ਸਾਈਡ ਨਿਯਮ ਉਸ ਸੰਰਚਨਾ ਫਾਈਲ ਵਿੱਚ ਹੁੰਦੇ ਹਨ ਜੋ ਸੇਵਾ ਸ਼ੁਰੂ ਹੋਣ ਸਮੇਂ ਲੋਡ ਕਰਦੀ ਹੈ, ਨਾ ਕਿ ਉਸ ਇੰਟਰਐਕਟਿਵ ਸੈਸ਼ਨ ਵਿੱਚ ਜੋ ਤੁਹਾਡੇ ਬੰਦ ਕਰਨ ਉੱਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ। ਨਿਯਮ ਲਿਖੋ, ਰੀਲੋਡ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਾਊਂਟਰ ਹਿਲਿਆ, ਕਿਉਂਕਿ ਸਿੰਟੈਕਸ ਨੂੰ ਰੱਦ ਕਰਨ ਵਾਲਾ ਰੀਲੋਡ ਪੁਰਾਣਾ ਨਿਯਮ ਸਮੂਹ ਚੁੱਪਚਾਪ ਉਸਦੀ ਥਾਂ ਉੱਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ।

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