ਲਾਈਵ ਟਨਲ 'ਤੇ AWS VPN ਟਨਲ ਲੌਗ ਸਮਰੱਥ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ?

Site-to-Site VPN ਲਈ ਟਨਲ ਗਤੀਵਿਧੀ ਲੌਗ ਚਾਲੂ ਕਰਨਾ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਹੈ ਜੋ ਉਸ ਟਨਲ ਨੂੰ ਡੇਗ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਇਹ ਮਾਪ ਰਿਹਾ ਹੈ। AWS ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਕਿ ਮੌਜੂਦਾ ਟਨਲ 'ਤੇ ਲੌਗਿੰਗ ਸਮਰੱਥ ਕਰਨ ਨਾਲ ਇਹ ਕੁਝ ਮਿੰਟਾਂ ਲਈ ਵਿਘਨ ਪੈ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਦਿਲਚਸਪ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਝੰਡਾ ਕਿਵੇਂ ਬਦਲਣਾ ਹੈ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਕਿਹੜੇ ਟਨਲ 'ਤੇ ਅਤੇ ਕਦੋਂ ਬਦਲਣਾ ਹੈ। ਤਿੰਨ ਸ਼ਰਤਾਂ ਕ੍ਰਮ ਤੈਅ ਕਰਦੀਆਂ ਹਨ: ਕੀ ਦੂਜਾ ਟਨਲ ਸੱਚਮੁੱਚ ਰੂਟ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਸੇਵਾ ਘਟਨਾਵਾਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜਾਂ BGP ਘਟਨਾਵਾਂ, ਅਤੇ ਬਦਲਾਅ ਕੰਸੋਲ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ ਜਾਂ ਟਨਲ ਵਿਕਲਪ API ਰਾਹੀਂ। ਇਹਨਾਂ ਵਿੱਚ ਗਲਤੀ ਕੀਤੀ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਜਾਂ ਤਾਂ ਰੁਕਾਵਟ ਹੋਵੇਗੀ ਜਾਂ ਕੁਝ ਵੀ ਨਾ ਭਰਿਆ ਲੌਗ ਸਮੂਹ।

ਤਿੰਨ ਸ਼ਰਤਾਂ ਕ੍ਰਮ ਤੈਅ ਕਰਦੀਆਂ ਹਨ

ਜਿਸ ਚੀਜ਼ ਨੂੰ ਤੁਸੀਂ ਬਦਲ ਰਹੇ ਹੋ ਉਸ ਦੀ ਪਛਾਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਤੁਹਾਨੂੰ VPN ਕਨੈਕਸ਼ਨ ID, ਖੇਤਰ ਅਤੇ ਉਸ ਖਾਸ ਟਨਲ ਦਾ ਬਾਹਰੀ IP ਪਤਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿੱਚ ਹਰ ਲੌਗ ਸੈਟਿੰਗ ਕਨੈਕਸ਼ਨ ਅਨੁਸਾਰ ਨਹੀਂ ਸਗੋਂ ਟਨਲ ਅਨੁਸਾਰ ਹੈ। ਗਲਤ ਬਾਹਰੀ ਪਤੇ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਬਦਲਾਅ ਉਸ ਟਨਲ ਵਿੱਚ ਬਦਲਾਅ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਡੀਬੱਗ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ।

ਮੰਜ਼ਿਲ ਉਸੇ ਖੇਤਰ ਵਿੱਚ CloudWatch ਲੌਗ ਸਮੂਹ ਹੈ, ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਚਾਹੁੰਦੇ ਰਿਟੈਂਸ਼ਨ ਅਤੇ ਪਹੁੰਚ ਨੀਤੀ ਹੈ। ਸਧਾਰਨ ਨਾਮਾਂ ਨੂੰ ਮਿਲ ਸਕਣ ਵਾਲੀਆਂ ਸਰੋਤ-ਨੀਤੀ ਆਕਾਰ ਸੀਮਾਵਾਂ ਤੋਂ ਬਚਦਾ ਹੈ ਇਸ ਲਈ AWS ਇਹਨਾਂ ਸਮੂਹਾਂ ਲਈ /aws/vendedlogs/ ਅਗੇਤਰ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ। /aws/vendedlogs/vpn/branch-a-activity ਵਰਗਾ ਨਾਮ ਸਿਰਫ਼ ਉਦਾਹਰਨ ਹੈ; ਮਹੱਤਵਪੂਰਨ ਇਹ ਹੈ ਕਿ ਸਮੂਹ ਮੌਜੂਦ ਹੈ, ਡਿਲੀਵਰੀ ਭੂਮਿਕਾ ਉਸ ਵਿੱਚ ਲਿਖ ਸਕਦੀ ਹੈ, ਅਤੇ ਦੋਵੇਂ VPN ਸੰਰਚਨਾ ਦੇ ਮਾਲਕ ਵੱਲੋਂ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ। ਨਾਮ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ, ਅਤੇ ਡਿਲੀਵਰੀ ਨੀਤੀ ਤੋਂ ਬਿਨਾਂ ਬਣਾਇਆ ਸਮੂਹ ਗਲਤੀ ਦੀ ਥਾਂ ਖ਼ਾਮੋਸ਼ੀ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਪਹਿਲੀ ਸ਼ਰਤ: ਸੱਚਮੁੱਚ ਟ੍ਰੈਫਿਕ ਲੈ ਕੇ ਜਾਣ ਵਾਲਾ ਵਾਧੂ ਟਨਲ

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

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

ਦੂਜੀ ਸ਼ਰਤ: ਗਤੀਵਿਧੀ ਲੌਗ ਜਾਂ BGP ਲੌਗ

ਇਹ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਕੀ ਪੜ੍ਹ ਸਕੋਗੇ। ਗਤੀਵਿਧੀ ਰਿਕਾਰਡ IKE ਅਤੇ IPsec ਸਥਿਤੀ ਤਬਦੀਲੀਆਂ ਅਤੇ DPD ਸੁਨੇਹਿਆਂ ਵਰਗੀਆਂ ਸੇਵਾ ਘਟਨਾਵਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ, ਜੋ ਤੁਸੀਂ ਤਦ ਚਾਹੁੰਦੇ ਹੋ ਜਦੋਂ ਟਨਲ ਉੱਪਰ ਨਹੀਂ ਆਉਂਦਾ ਜਾਂ ਲਗਾਤਾਰ ਚਾਬੀਆਂ ਨਵੀਆਂ ਕਰਦਾ ਹੈ। BGP ਰਿਕਾਰਡ ਆਪਣੇ ਨਿਯੰਤਰਣਾਂ ਵਾਲਾ ਵੱਖਰਾ ਪ੍ਰਵਾਹ ਹਨ, ਅਤੇ ਉਹ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਰੂਟ ਉਮੀਦ ਅਨੁਸਾਰ ਬਦਲੇ ਅਤੇ ਵਾਪਸ ਲਏ ਗਏ ਜਾਂ ਨਹੀਂ।

ਗਤੀਵਿਧੀ ਝੰਡਾ ਸਮਰੱਥ ਕਰਨਾ ਸੇਵਾ ਵੱਲੋਂ ਭੇਜੇ ਜਾ ਸਕਣ ਵਾਲੇ ਹਰ ਪ੍ਰਵਾਹ ਲਈ ਬੇਨਤੀ ਨਹੀਂ ਹੈ। ਜੇ ਸ਼ੱਕ ਰਾਊਟਿੰਗ ਦਾ ਹੈ ਤਾਂ ਦੋਵੇਂ ਸਮਰੱਥ ਕਰੋ; ਜੇ ਸ਼ੱਕ ਪੜਾਅ 1 ਜਾਂ ਪੜਾਅ 2 ਗੱਲਬਾਤ ਦਾ ਹੈ ਤਾਂ ਗਤੀਵਿਧੀ ਪ੍ਰਵਾਹ ਹੀ ਉਹ ਦਿਖਾਏਗਾ।

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

ਤੀਜੀ ਸ਼ਰਤ: ਕੰਸੋਲ ਬਦਲਾਅ ਜਾਂ ਟਨਲ ਵਿਕਲਪ API

ਜੇ ਕੋਈ ਮਨੁੱਖ ਇੱਕ ਵਾਰ ਦਾ ਬਦਲਾਅ ਕਰ ਰਿਹਾ ਹੈ ਤਾਂ ਕੰਸੋਲ ਰਸਤਾ ਠੀਕ ਹੈ: VPC console, Site-to-Site VPN connections, ਕਨੈਕਸ਼ਨ ਚੁਣੋ, Actions, Modify VPN tunnel options, ਬਾਹਰੀ IP ਚੁਣੋ, Tunnel activity log ਸਮਰੱਥ ਕਰੋ, ਸਮੂਹ ਅਤੇ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ ਚੁਣੋ, ਵਿੰਡੋ ਦੇ ਅੰਦਰ ਸੰਭਾਲੋ। ਜੇ VPN ਨੂੰ ਕੋਡ ਵਜੋਂ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਉਹੀ ਕਲਿੱਕ ਉਹ ਡ੍ਰਿਫਟ ਹੈ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਮਿਲਾਓਗੇ।

ਆਟੋਮੇਸ਼ਨ ਲਈ, ਟਨਲ ਵਿਕਲਪਾਂ ਦੇ ਗਤੀਵਿਧੀ-ਲੌਗ ਹਿੱਸੇ ਦਾ ਨਿਸ਼ਚਿਤ ਆਕਾਰ ਹੈ: LogOptions ਜਿਸ ਵਿੱਚ CloudWatchLogOptions ਹੈ, ਨਾਲ LogEnabled, LogGroupArn ਅਤੇ LogOutputFormat। ਉਹ ਬਲਾਕ ਟੁਕੜਾ ਹੈ, ਬੇਨਤੀ ਨਹੀਂ; modify-vpn-tunnel-options ਨੂੰ ਅਜੇ ਵੀ ਕਨੈਕਸ਼ਨ ID ਅਤੇ ਟਨਲ ਦਾ ਬਾਹਰੀ IP ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਟਨਲ ਸੈਟਿੰਗਾਂ ਟੈਂਪਲੇਟ ਦੇ ਮਾਲਕ ਨੂੰ ਸੰਭਾਲਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। BGP ਲੌਗਿੰਗ ਉਸੇ ਢਾਂਚੇ ਵਿੱਚ ਆਪਣੀਆਂ BgpLogEnabled, BgpLogGroupArn ਅਤੇ BgpLogOutputFormat ਚਾਬੀਆਂ ਵਰਤਦੀ ਹੈ। ਕਾਲ ਲਾਗੂ ਹੋਣ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ describe-vpn-connections ਨਾਲ ਬਦਲਾਅ ਮੁੜ ਪੜ੍ਹੋ।

ਰਿਕਾਰਡ ਤੁਹਾਨੂੰ ਕੀ ਦੱਸ ਸਕਦੇ ਹਨ ਅਤੇ ਕੀ ਨਹੀਂ

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

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

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