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

ਹੱਦ ਉੱਥੇ ਹੀ ਹੈ ਜਿੱਥੇ SA ਖਤਮ ਹੁੰਦਾ ਹੈ

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

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

SPD ਸੁਰੱਖਿਆ ਦਾ ਅਤੇ ਰਾਹ ਦਿਸ਼ਾ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ

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

Linux ਵਿੱਚ, ip xfrm policy ਉਹ ਐਂਟਰੀਆਂ ਉਹਨਾਂ ਦੀ ਦਿਸ਼ਾ, ਤਰਜੀਹ, ਚੋਣਕਰਤਾ ਅਤੇ ਇਜਾਜ਼ਤ, ਰੋਕ ਜਾਂ ਜਾਲ ਦੀ ਕਿਰਿਆ ਸਮੇਤ ਛਾਪਦਾ ਹੈ, ਜਦਕਿ ip xfrm state ਨਤੀਜੇ ਵਜੋਂ ਬਣੇ ਸਹਿਯੋਗ ਅਤੇ ਉਹਨਾਂ ਦੇ ਗਿਣਕ ਦਿਖਾਉਂਦਾ ਹੈ। ਦੋਵੇਂ ਨੂੰ ਇਕੱਠਾ ਪੜ੍ਹਨਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਹਾਨੂੰ ਉਹ ਪ੍ਰਵਾਹ ਮਿਲਦਾ ਹੈ ਜਿਸ ਨੇ ਸੁਰੰਗ ਨੂੰ ਚੁੱਪਚਾਪ ਬਾਈਪਾਸ ਕੀਤਾ ਕਿਉਂਕਿ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਇਜਾਜ਼ਤ ਐਂਟਰੀ ਪਹਿਲਾਂ ਮੇਲ ਖਾ ਗਈ।

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

ਟ੍ਰਾਂਸਪੋਰਟ ਮੋਡ ਅਗਲੀ ਪਰਤ ਢਕਦਾ ਹੈ, IP ਸਿਰਲੇਖ ਨਹੀਂ

Transport modeTunnel mode
Original IP headerkept for routing the flowreplaced by an outer header
What ESP protectsthe carried next-layer payloadthe whole inner IP packet
Where it terminatescommonly the two hostsgateway pair, or a host pair

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

ਦੋਵੇਂ ਮੋਡ ਅਗਲੀ ਪਰਤ ਦੇ ਕਈ ਪ੍ਰੋਟੋਕੋਲ ਲੈ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ESP ਉਹੀ ਸੁਰੱਖਿਅਤ ਕਰੇਗਾ ਜੋ ਚੋਣਕਰਤਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਹਰ ਉਹ ਚੀਜ਼ ਜੋ ਹੋਸਟ ਭੇਜਦਾ ਹੈ।

ਚੋਣ ਜੋੜ ਨਾਲੋਂ ਤੰਗ ਹੈ

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

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

ਮਸ਼ੀਨ ਦੀ ਪਛਾਣ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ