ਖਾਲੀ VPN ਟੇਬਲ ਆਪਣੇ ਆਪ ਕੁਝ ਨਹੀਂ ਰੋਕਦੀ

ਇੱਕ ਨੀਤੀ ਨਿਯਮ ਨਿਸ਼ਾਨਿਤ ਪੈਕੇਟਾਂ ਨੂੰ ਸਮਰਪਿਤ ਟੇਬਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਆਮ ਉਮੀਦ ਇਹ ਹੈ ਕਿ VPN ਰੂਟ ਗੁਆਉਣ ਨਾਲ ਉਹ ਰੁਕ ਜਾਣਗੇ। ਪਰ ਕਾਰਵਿਧੀ ਕੁਝ ਹੋਰ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਟੇਬਲ ਵਿੱਚ ਕੋਈ ਮੇਲ ਖਾਂਦਾ ਰੂਟ ਨਹੀਂ ਹੁੰਦਾ, ਖੋਜ ਅਗਲੇ ਨਿਯਮ ਵੱਲ ਜਾਰੀ ਰਹਿੰਦੀ ਹੈ ਰੁਕਣ ਦੀ ਬਜਾਏ, ਅਤੇ main ਟੇਬਲ ਵਿੱਚ ਅਜੇ ਵੀ uplink ਲਈ ਆਮ ਡਿਫ਼ਾਲਟ ਰੂਟ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਕਨਫਿਗਰੇਸ਼ਨ ਹੈ ਜੋ fail-closed ਦਿਸਦਾ ਹੈ ਪਰ fail-open ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ।

ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ ਹੈ; ਨੀਤੀ-ਆਧਾਰਿਤ ਰਾਊਟਿੰਗ ਇਸੇ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਹੈ।

ਟੇਬਲ ਵਿੱਚ ਕੁਝ ਨਾ ਹੋਣ ਵੇਲੇ ਖੋਜ ਜਾਰੀ ਰਹਿੰਦੀ ਹੈ

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

ਉਹ ਨਿਯਮ-ਸਮੂਹ ਲਓ: ਨਿਸ਼ਾਨਿਤ ਖੋਜ ਟੇਬਲ 42 ਵਿੱਚ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਾਲਾ ਨਿਯਮ ਉਹੀ ਨਿਸ਼ਾਨ default ਨਾਂ ਦੇ ਟੇਬਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਜਦੋਂ ਤੱਕ ਟੇਬਲ 42 ਵਿੱਚ ਵਰਤੋਂਯੋਗ ਡਿਫ਼ਾਲਟ ਰੂਟ ਹੈ, ਪਹਿਲੀ ਖੋਜ ਰਾਹ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ ਉਹ ਰੂਟ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਟੇਬਲ 42 ਵਿੱਚ ਹੋਰ ਕੁਝ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਤਾਂ ਖੋਜ ਰੱਦ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦੀ; ਪ੍ਰੋਸੈਸਿੰਗ ਅਗਲੇ ਨਿਯਮ ਵੱਲ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਉਹ ਵੀ ਕੁਝ ਨਾ ਲੱਭੇ ਤਾਂ main ਟੇਬਲ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ। ਉਸ ਕ੍ਰਮ ਵਿੱਚ ਕੁਝ ਵੀ ਕਿਹੜੇ ਨਿਯਮ ਨੇ ਅੰਤਿਮ ਜਵਾਬ ਦਿੱਤਾ ਦੱਸਦਾ ਨਹੀਂ, ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਕਨੈਕਸ਼ਨ ਕੰਮ ਕਰਦੀ ਨੀਤੀ ਵਾਂਗ ਦਿਸਦਾ ਹੈ।

ਪਰੰਪਰਕ ਤੌਰ ’ਤੇ default ਕਹੀ ਜਾਣ ਵਾਲੀ ਟੇਬਲ 253 ਇੱਕ ਆਮ ਰਾਊਟਿੰਗ ਟੇਬਲ ਹੈ ਅਤੇ ਆਮ ਤੌਰ ’ਤੇ ਖਾਲੀ ਹੁੰਦੀ ਹੈ। ਇਸ ਦਾ ਨਾਂ ਪੈਕੇਟ ਸੁੱਟਣ ਦਾ ਹੁਕਮ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਟੇਬਲ ਦੇ ਅੰਦਰ ਡਿਫ਼ਾਲਟ ਮੰਜ਼ਿਲ ਰੂਟ ਵਾਂਗ ਨਹੀਂ ਹੈ।

ਟਰਮੀਨਲ ਕਾਰਵਾਈਆਂ ਖੋਜ ਖਤਮ ਕਰਦੀਆਂ ਹਨ

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

ਖਾਲੀ ਟੇਬਲ ਦੀ ਖੋਜ ਦੀ ਬਜਾਏ VPN ਖੋਜ ਤੋਂ ਬਾਅਦ ਇੱਕ ਟਰਮੀਨਲ ਨਿਯਮ ਆ ਸਕਦਾ ਹੈ। ਉਸੇ ਨਿਸ਼ਾਨ ਨਾਲ, ਟੇਬਲ 42 ਦੇ ਨਿਯਮ ਤੋਂ ਬਾਅਦ ਰੱਖੀ ਗਈ prohibit ਕਾਰਵਾਈ ਉਸ ਟੇਬਲ ਤੋਂ ਕੁਝ ਨਾ ਮਿਲਣ ਵੇਲੇ ਖੋਜ ਖਤਮ ਕਰਦੀ ਹੈ ਅਤੇ main ਟੇਬਲ ਨੂੰ ਇੱਕ ਹੋਰ ਮੌਕਾ ਦੇਣ ਦੀ ਬਜਾਏ ਪ੍ਰਬੰਧਕੀ ਇਨਕਾਰ ਵਾਪਸ ਕਰਦੀ ਹੈ। Unreachable ਅਤੇ blackhole ਵੀ ਟਰਮੀਨਲ ਹਨ, ਭੇਜਣ ਵਾਲੇ ਲਈ ਵੱਖਰੇ ਗਲਤੀ ਵਿਵਹਾਰ ਨਾਲ।

throw ਕਿਸਮ ਦਾ ਰੂਟ ਵੱਖਰਾ ਹੈ: ਉਸ ਟੇਬਲ ਦੇ ਅੰਦਰ ਇਹ ਇੰਝ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕੁਝ ਮੇਲ ਨਹੀਂ ਖਾਧਾ, ਇਸ ਲਈ ਬਾਅਦ ਦੇ ਨਿਯਮਾਂ ਨੂੰ ਅਜੇ ਵੀ ਆਪਣੀ ਵਾਰੀ ਮਿਲਦੀ ਹੈ। ਇਹ throw ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਪਿੱਛੇ ਹਟਣ ਲਈ ਲਾਭਦਾਇਕ ਅਤੇ ਅੰਤਿਮ ਬਲਾਕ ਵਜੋਂ ਗਲਤ ਬਣਾਉਂਦਾ ਹੈ।

ਅਸਲੀ ਨਿਸ਼ਾਨ ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਤਸਦੀਕ ਕਰੋ

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

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

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

ਦੋ ਅਸਫਲਤਾ ਸਥਿਤੀਆਂ, ਇੱਕ ਨਹੀਂ

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

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

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