PPP ਦਾ peer ਪਤਾ ਜਾਂ VPN ਐਂਡਪੁਆਇੰਟ: via ਵਿੱਚ ਕਿਹੜਾ ਜਾਂਦਾ ਹੈ

PPP ਇੰਟਰਫੇਸ ਉੱਤੇ ਇੱਕ ਲਾਈਨ VPN ਬਾਕਸ ਉੱਤੇ ਦੀ ਬਹੁਤੀ ਰਾਊਟਿੰਗ ਬਹਿਸ ਨਿਪਟਾ ਦਿੰਦੀ ਹੈ: ਅੰਦਰਲਾ ਪਤਾ ਅਤੇ ਇਸ ਦੇ ਕੋਲ ਛਾਪਿਆ peer। ਉਸ ਜੋੜੀ ਨੂੰ ਛੋਟੇ ਸਬਨੈੱਟ ਵਜੋਂ ਪੜ੍ਹੋ ਅਤੇ ਤੁਸੀਂ ਅਜਿਹਾ ਗੇਟਵੇ ਲੱਭੋਗੇ ਜੋ ਹੈ ਹੀ ਨਹੀਂ। ਇਸ ਨੂੰ ਇੱਕ ਲਿੰਕ ਦੇ ਦੋ ਸਿਰਿਆਂ ਵਜੋਂ ਪੜ੍ਹੋ ਅਤੇ ਅਗਲਾ ਹੌਪ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਥੇ ਤੁਲਨਾ ਇਹਨਾਂ ਦੋ ਪੜ੍ਹਤਾਂ ਵਿਚਕਾਰ ਹੈ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਿੱਚ ਬਣੀ ਹਰ ਸਾਰਣੀ ਤੁਹਾਡੇ ਚੁਣੇ ਹੋਏ ਨੂੰ ਹੀ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦੀ ਹੈ। ਬਾਹਰਲੇ VPN ਐਂਡਪੁਆਇੰਟ ਬਾਰੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਕੁਝ ਤੈਅ ਨਹੀਂ ਕਰਦਾ।

ਇੱਕ ਇੰਟਰਫੇਸ ਲਾਈਨ ਦੀਆਂ ਦੋ ਪੜ੍ਹਤਾਂ

ਇੱਕ ਸੈਸ਼ਨ ਲਓ ਜਿਸ ਵਿੱਚ ਇੰਟਰਫੇਸ inet 10.64.3.9 peer 10.64.3.1/32 ਦੱਸਦਾ ਹੈ। ਸਬਨੈੱਟ ਪੜ੍ਹਤ 10.64.3.9 ਨੂੰ /32 ਟਾਪੂ ਉੱਤੇ ਇਕੱਲਾ ਹੋਸਟ ਮੰਨਦੀ ਹੈ ਅਤੇ ਫਿਰ ਇਸ ਤੋਂ ਬਾਹਰ ਕੁਝ ਵੀ ਪਹੁੰਚਣ ਲਈ ਰਾਊਟਰ ਲੱਭਦੀ ਹੈ। ਲਿੰਕ ਉੱਤੇ ਦੂਜਾ ਇਕਲੌਤਾ ਪਤਾ peer ਹੋਣ ਕਰਕੇ, ਉਹ ਪੜ੍ਹਤ ਅੰਤ ਵਿੱਚ 10.64.3.9 ਨੂੰ ਹੀ ਗੇਟਵੇ ਵਜੋਂ ਸੁਝਾਉਂਦੀ ਹੈ, ਜੋ ਚੱਕਰੀ ਹੈ।

ਐਂਡਪੁਆਇੰਟ ਪੜ੍ਹਤ ਹੀ ਦਸਤਾਵੇਜ਼ੀ ਹੈ। ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ ਇੰਟਰਫੇਸ ਉੱਤੇ peer ਉਸ ਇੱਕ ਲਿੰਕ ਦੇ ਦੂਰਲੇ ਸਿਰੇ ਦਾ ਨਾਂ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ 10.64.3.1 ਹੀ ਵਰਤੋਂਯੋਗ ਅਗਲਾ ਹੌਪ ਹੈ ਅਤੇ 10.64.3.9 ਸਦਾ ਸਿਰਫ਼ ਸਰੋਤ ਪਤਾ ਹੁੰਦਾ ਹੈ।

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

ਸੈਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਕੀ ਸਥਾਪਿਤ ਕਰ ਚੁੱਕਾ ਹੈ

ਆਪਣੀ ਸਾਰਣੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਛਾਪੋ ਕਿ ਲਿੰਕ ਨਾਲ ਕੀ ਆਇਆ। ਸਮਰਥਿਤ PPP ਏਕੀਕਰਣ ਆਮ ਤੌਰ ਉੱਤੇ ਸੈਸ਼ਨ ਸਥਾਪਿਤ ਕਰਦਿਆਂ ਡਿਵਾਈਸ ਰਾਹ ਅਤੇ peer ਰਾਹ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਦੋਵੇਂ ਐਂਟਰੀਆਂ ਪਹਿਲਾਂ ਹੀ ਸਹੀ ਪੜ੍ਹਤ ਸੰਕੇਤ ਕਰਦੀਆਂ ਹਨ।

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 ਵਰਗਾ ਡਿਵਾਈਸ ਰਾਹ ਗੇਟਵੇ ਨਹੀਂ ਰੱਖਦਾ ਕਿਉਂਕਿ ਇੰਟਰਫੇਸ ਆਪ ਹੀ ਰਾਹ ਹੈ। via ਨਾਲ peer ਦਾ ਨਾਂ ਲੈਣ ਵਾਲਾ ਰਾਹ ਵੱਖਰੀ ਉਮਰ ਦੀ ਵੱਖਰੀ ਵਸਤੂ ਹੈ, ਅਤੇ ਸੈਸ਼ਨ ਡਿੱਗਣ ਉੱਤੇ ਉਹ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਰੂਪ ਦੁਬਾਰਾ ਕਿਵੇਂ ਸਥਾਪਿਤ ਹੁੰਦਾ ਹੈ ਇਹ ਜਾਂਚੇ ਬਿਨਾਂ ਟਿਕਾਊ ਸਾਰਣੀ ਵਿੱਚ ਨਕਲ ਕਰਨਾ ਹੀ ਚੱਲ ਰਹੀ ਸੁਰੰਗ ਦਾ ਦੁਬਾਰਾ ਜੁੜਨ ਮਗਰੋਂ ਆਪਣਾ ਰਾਹ ਗੁਆਉਣ ਦਾ ਆਮ ਕਾਰਨ ਹੈ।

ਯਾਦਦਾਸ਼ਤ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਦੋਵੇਂ ਸੂਚੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। peer ਰਾਹ main ਵਿੱਚ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਤੁਹਾਡੀ ਵਾਧੂ ਸਾਰਣੀ ਖਾਲੀ ਹੋਵੇ, ਤਾਂ ਪਤੇ ਦੀ ਲਾਈਨ ਨੇ ਕਦੇ ਨਾ ਦੱਸੀ ਗੱਲ ਤੁਸੀਂ ਸਿੱਖੀ।

ਨਿਯਮ ਅਤੇ ਸਾਰਣੀ ਵੱਖਰੇ ਫ਼ੈਸਲੇ ਹਨ

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

ਅੱਧਾ ਡਿਫਾਲਟ ਰਾਹ ਡਿਫਾਲਟ ਰਾਹ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ 0.0.0.0/1 IPv4 ਥਾਂ ਦਾ ਹੇਠਲਾ ਅੱਧਾ ਹਿੱਸਾ ਢਕਦਾ ਹੈ, ਇਸ ਲਈ ਸਭ ਕੁਝ ਫੜਨ ਦਾ ਇਰਾਦਾ ਰੱਖਣ ਵਾਲੀ ਨੀਤੀ ਨੂੰ ਮਿਲਦਾ 128.0.0.0/1 ਜਾਂ ਸੱਚਾ default ਵੀ ਚਾਹੀਦਾ ਹੈ। ਚੱਲ ਰਹੀ ਕਨਫਿਗ ਪੜ੍ਹ ਕੇ ਦੋ ਅੱਧਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਨਕਲ ਕਰਨਾ ਹੀ ਲੋਕਾਂ ਦੇ ਕੁਝ ਖ਼ਾਸ ਮੰਜ਼ਿਲਾਂ ਉੱਤੇ ਹੀ ਟੁੱਟਣ ਵਾਲੇ ਰਾਊਟਿੰਗ ਲੂਪ ਵਿੱਚ ਫਸਣ ਦਾ ਰਾਹ ਹੈ।

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

ਖੋਜ ਨੂੰ ਉਹੀ ਸਵਾਲ ਪੁੱਛੋ ਜੋ ਤੁਹਾਡੀ ਐਪ ਪੁੱਛਦੀ ਹੈ

ip route get ਰਾਹ ਦਾ ਹੱਲ ਕਰਦਾ ਹੈ; ip route show ਸੰਭਾਲੀਆਂ ਐਂਟਰੀਆਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਕੋਈ ਵੀ ਗ਼ਲਤ ਨਾ ਹੁੰਦਿਆਂ ਵੀ ਅਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ। ਸਰੋਤ ਸੰਦਰਭ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ ਸਰੋਤ-ਆਧਾਰਿਤ ਨਿਯਮ ਤਾਂ ਹੀ ਮਿਲਦੇ ਹਨ ਜਦੋਂ ਖੋਜ ਸਰੋਤ ਲੈ ਕੇ ਚੱਲੇ।

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

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

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

ਤੁਲਨਾ ਕਿੱਥੇ ਪਲਟਦੀ ਹੈ

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

ਜੇ ਬਾਹਰ ਜਾਂਦੀ ਰਾਊਟਿੰਗ ਸਹੀ ਦਿਸਦਿਆਂ ਵੀ ਜਵਾਬ ਗਾਇਬ ਹੋਣ, ਤਾਂ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਭਾਵੀ ਮੁੱਲ ਪੜ੍ਹੋ, ਅਤੇ ਬਿਆਨ ਕੀਤੇ ਨੀਤੀ ਕਾਰਨ ਤੋਂ ਬਿਨਾਂ ਉਹਨਾਂ ਨੂੰ ਨਾ ਬਦਲੋ।

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

ਦੋਵੇਂ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚੋਂ ਸਬੂਤ ਦੇ ਆਧਾਰ ਉੱਤੇ ਚੁਣੋ: ਐਪ PPP ਪਤੇ ਨਾਲ ਬੱਝੀ ਹੋਵੇ ਤਾਂ ਸਰੋਤ ਨਿਯਮ ਅਤੇ peer ਰਾਹ ਵਾਲੀ ਸਾਰਣੀ ਕਾਫ਼ੀ ਹੈ। ਬਾਕਸ ਪਿੱਛਲੇ LAN ਲਈ ਅੱਗੇ ਭੇਜਦਾ ਹੋਵੇ ਤਾਂ ਐਂਟਰੀ ਸੰਦਰਭ ਅਤੇ ਵਾਪਸੀ ਰਾਹ ਵੀ ਮੇਲ ਖਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਨਾ ਮਿਲਣ ਉੱਤੇ ਪੂਰੀ ਮਸ਼ੀਨ ਲਈ ਜਾਂਚ ਢਿੱਲੀ ਕਰਨ ਦੀ ਥਾਂ ਰਾਹ ਦੀ ਮਾਲਕੀ ਠੀਕ ਕਰੋ।