ਰਾਊਟਡ ਜਾਂ ਬ੍ਰਿਜਡ VPN: ਕਲਾਇੰਟ ਨੂੰ ਕੀ ਪਹੁੰਚਣਾ ਹੈ ਦੇ ਆਧਾਰ ਉੱਤੇ ਚੁਣੋ

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

ਟਿਕਟ ਡੈਸਕ ਉੱਤੇ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਦੋ ਬੇਨਤੀਆਂ

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

ਇਹ ਵੱਖਰੇ ਸਵਾਲ ਹਨ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਪੁਲ ਨਾਲ ਜਵਾਬ ਦੇਣਾ ਕਰਮਚਾਰੀ ਦੀ ਪਹੁੰਚ ਨੂੰ ਬਿਨਾਂ ਕਾਰਨ ਪੂਰੇ ਦਫ਼ਤਰ LAN ਤੱਕ ਵਧਾ ਦਿੰਦਾ ਹੈ।

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

ਰਾਊਟ LAN ਮੈਂਬਰਸ਼ਿਪ ਨਾਲੋਂ ਤੰਗ ਹੈ

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

ਰਾਊਟ ਨੂੰ ਇਜਾਜ਼ਤ ਨਾਲ ਨਾ ਮਿਲਾਓ। ਕਲਾਇੰਟ ਨੂੰ ਸਬਨੈੱਟ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਤਰੀਕਾ ਦੱਸਣਾ ਉਸਨੂੰ ਹੋਰ ਮੰਜ਼ਿਲ ਅਜ਼ਮਾਉਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ।

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

ਪੁਲ ਦਾਖਲੇ ਦਾ ਸਵਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ

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

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

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

ਫਿਲਟਰਿੰਗ ਦੋਵਾਂ ਟੋਪੋਲੋਜੀਆਂ ਵਿੱਚ ਹੈ

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

ਹੱਦ ਦਾ ਵਾਅਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਪਲੇਟਫਾਰਮ ਅਸਲ ਵਿੱਚ ਕੀ ਸਮਰਥਨ ਕਰਦਾ ਹੈ:

bridge link show
nft list ruleset

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

ਤਿੰਨ ਕੋਸ਼ਿਸ਼ਾਂ ਨਾਲ ਹੱਦ ਸਾਬਤ ਕਰੋ

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

ਇੱਕੋ ਕਲਾਇੰਟ ਤੋਂ ਮਨਜ਼ੂਰ ਅਤੇ ਰੱਦ ਕੀਤਾ ਰਾਹ ਚਲਾਓ, ਅਤੇ ਦੋਵੇਂ ਦਰਜ ਕਰੋ:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

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