ਡਿਫ਼ਾਲਟ ਤੌਰ 'ਤੇ, AWS Site-to-Site VPN ਉਦੋਂ ਤੱਕ ਉਡੀਕ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ customer gateway ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਨਾ ਕਰੇ। ਉਹ ਡਿਫ਼ਾਲਟ ਇੱਕ ਸੈਟਿੰਗ ਹੈ, ਕਾਨੂੰਨ ਨਹੀਂ, ਅਤੇ ਸੈਟਿੰਗ ਦਾ ਨਾਮ Startup action ਹੈ। ਇਸ ਵੱਲ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ, ਦੋ ਸਵਾਲ ਵੱਖ ਕਰੋ ਜੋ ਹਮੇਸ਼ਾ ਮਿਲ ਜਾਂਦੇ ਹਨ: ਟਨਲ ਕੌਣ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਜਿਨ੍ਹਾਂ ਪੈਕਟਾਂ ਦੀ ਤੁਹਾਨੂੰ ਪਰਵਾਹ ਹੈ ਉਨ੍ਹਾਂ ਦਾ ਇਸ ਵਿੱਚੋਂ ਕੋਈ ਰੂਟ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਿਰਫ਼ ਪਹਿਲਾ ਹੀ ਟਨਲ ਦੇ ਵਿਕਲਪਾਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।

ਸ਼ੁਰੂਆਤੀ ਕਾਰਵਾਈ ਨੂੰ DPD ਟਾਈਮਆਊਟ ਕਾਰਵਾਈ ਤੋਂ ਵੱਖ ਕਰੋ

ਹਰ ਟਨਲ ਲਈ ਦੋ ਵਿਕਲਪ ਦੋ ਵੱਖਰੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਸੈੱਟ ਕਰਨ ਨਾਲ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਿਹਾ ਜਾਂਦਾ।

EventOptionUseful values
A new or modified VPN connection needs a tunnelStartup actionadd waits for the peer; start asks AWS to initiate
Dead peer detection times outDPD timeout actionclear ends the session, restart reinitiates, none does nothing

ਜੇ AWS ਨੂੰ ਨਵੀਂ ਜਾਂ ਬਦਲੀ ਟਨਲ ਬਣਾਉਣੀ ਹੈ, ਤਾਂ ਚੁਣੋ start. ਜੇ AWS ਨੂੰ DPD ਟਾਈਮਆਊਟ ਤੋਂ ਬਾਅਦ ਗੱਲਬਾਤ ਵੀ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨੀ ਹੈ, ਤਾਂ ਉਸ ਘਟਨਾ ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ restart ਕਨਫ਼ਿਗਰ ਕਰੋ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਵਿਕਲਪ ਐਪ ਦੀ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਨੀਤੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਕੀ ਬਦਲਣ ਦਾ ਅੰਤਰਾਲ ਨਹੀਂ ਹੈ: DPD ਜਾਂਚਦਾ ਹੈ ਕਿ ਪੀਅਰ ਜੀਵਤ ਹੈ ਜਾਂ ਨਹੀਂ, ਜਦੋਂ ਕਿ ਕੀ ਬਦਲਣਾ ਸਰਗਰਮ ਟਨਲ ਉੱਤੇ security associations ਬਦਲਦਾ ਹੈ।

ਜਿਹੜੀ ਐਪ ਟਾਈਮਆਊਟ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਕਿ ਟਨਲ ਅਜੇ ਵੀ up ਦੱਸਦੀ ਹੈ, ਉਸਦੀ ਸਮੱਸਿਆ ਡੇਟਾ-ਪਾਥ ਵਿੱਚ ਹੈ। DPD ਟਾਈਮਰ ਛੋਟਾ ਕਰਨ ਨਾਲ ਇਹ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਇਹ ਬਾਅਦ ਵਿੱਚ ਸਮਝਾਉਣ ਵਾਲੀ ਹਲਚਲ ਜੋੜ ਸਕਦਾ ਹੈ।

ਜਾਂਚੋ ਕਿ AWS ਕੋਲ ਗੱਲਬਾਤ ਭੇਜਣ ਦੀ ਥਾਂ ਹੈ

AWS ਵੱਲੋਂ ਸ਼ੁਰੂਆਤ ਸਿਰਫ਼ IKEv2 ਨਾਲ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਪ੍ਰਸਤਾਵ ਕਿੱਥੇ ਭੇਜਣਾ ਹੈ ਇਹ ਜਾਣਨ ਲਈ AWS ਨੂੰ customer gateway ਦਾ ਜਨਤਕ ਪਤਾ ਚਾਹੀਦਾ ਹੈ। ਸਭ ਤੋਂ ਵੱਧ ਦੁਖਦਾ ਮਾਮਲਾ ਬਿਨਾਂ ਪਤੇ ਦੇ ਬਣਾਇਆ ਸਰਟੀਫ਼ਿਕੇਟ-ਪ੍ਰਮਾਣਿਤ customer gateway ਸਰੋਤ ਹੈ: AWS ਦੇ ਦਸਤਾਵੇਜ਼ ਪਤੇ ਨਾਲ ਨਵਾਂ customer gateway ਸਰੋਤ ਬਣਾਉਣ ਅਤੇ ਫਿਰ VPN ਕਨੈਕਸ਼ਨ ਨੂੰ ਉਸ ਵੱਲ ਮੋੜਨ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ।

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

ਜੇ customer gateway NAT ਦੇ ਪਿੱਛੇ ਹੈ, ਤਾਂ AWS ਨੂੰ ਕਨਫ਼ਿਗਰ ਕੀਤਾ responder identity ਵੀ ਚਾਹੀਦਾ ਹੈ, IDr, ਤਾਂ ਜੋ ਪੀਅਰ ਦੀ ਪਛਾਣ ਡਿਵਾਈਸ ਦੀ ਉਮੀਦ ਨਾਲ ਮੇਲ ਖਾਵੇ। ਜਿਸ ਵਿਕਲਪ ਨੂੰ ਤੁਸੀਂ ਹੁਣੇ ਬਦਲਿਆ ਹੈ ਉਸਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਮੁੱਲ ਅਤੇ IKE ਟ੍ਰੈਫ਼ਿਕ ਲੰਘਣ ਦੇਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਰਾਹ ਜਾਂਚੋ। start ਚੁਣਨ ਨਾਲ ਕਿਸੇ ਅਪਹੁੰਚ ਜਾਂ ਗਲਤ ਪਛਾਣੇ ਪੀਅਰ ਨੂੰ ਪ੍ਰਸਤਾਵ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।

ਬਦਲਾਅ ਇੱਕ ਟਨਲ ਉੱਤੇ ਲਾਗੂ ਕਰੋ ਅਤੇ ਰੁਕਾਵਟ ਦੀ ਉਮੀਦ ਰੱਖੋ

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

  1. Site-to-Site VPN ਕਨੈਕਸ਼ਨ ਚੁਣੋ ਅਤੇ Modify VPN tunnel options ਖੋਲ੍ਹੋ।
  2. ਬਾਹਰੀ IP ਪਤੇ ਨਾਲ ਟਨਲ ਚੁਣੋ ਅਤੇ ਇਸਦਾ IKE ਸੰਸਕਰਣ ਤੇ customer gateway ਸਰੋਤ ਪੱਕਾ ਕਰੋ।
  3. ਉਹ ਸ਼ੁਰੂਆਤ ਅਤੇ DPD ਕਾਰਵਾਈਆਂ ਸੈੱਟ ਕਰੋ ਜੋ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਚਾਹੁੰਦੇ ਹੋ, ਫਿਰ ਆਪਣੇ ਨਿਯੰਤਰਣ ਵਾਲੇ ਸਮੇਂ ਵਿੱਚ ਸੰਭਾਲੋ।
  4. ਪੱਕਾ ਕਰੋ ਕਿ ਬਦਲੀ ਟਨਲ ਸਥਾਪਿਤ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਅਗਲੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਦੂਜੀ ਟਨਲ ਅਤੇ ਰੂਟਿੰਗ ਜਾਂਚੋ।

ਰੱਖ-ਰਖਾਅ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਵਿਵਹਾਰ ਧਿਆਨ ਯੋਗ ਹੈ। AWS ਸ਼ੁਰੂਆਤ ਸਮਰੱਥ ਹੋਣ 'ਤੇ ਕੋਈ ਟਾਈਮਆਊਟ ਨਹੀਂ ਹੁੰਦਾ: ਟਨਲ ਉੱਠਣ ਤੱਕ AWS ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ customer gateway ਵੱਲੋਂ delete-SA ਸੁਨੇਹਾ ਭੇਜਣ 'ਤੇ ਮੁੜ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪੀਅਰ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਬੰਦ ਕਰਦੇ ਹੋ, ਤਾਂ AWS ਖੜਕਦਾ ਰਹੇਗਾ, ਅਤੇ ਪੀਅਰ ਦੇ ਲਾਗ ਇਹ ਦਿਖਾਉਣਗੇ।

ਸਿਰਫ਼ ਟਨਲ ਦੀ ਸਥਿਤੀ ਨਹੀਂ, ਐਪ ਦਾ ਰਾਹ ਜਾਂਚੋ

up ਦੱਸਣ ਵਾਲੀ ਟਨਲ ਕੰਮ ਕਰਦੀ ਬੇਨਤੀ ਦੇ ਬਰਾਬਰ ਨਹੀਂ। VPC ਨਾਲ ਜੁੜੇ Lambda ਫੰਕਸ਼ਨ ਨੂੰ ਅਜੇ ਵੀ ਗਾਹਕ ਦੇ ਪ੍ਰੀਫ਼ਿਕਸ ਤੱਕ subnet ਰੂਟ, ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੇ security group ਅਤੇ network ACL ਨਿਯਮ, ਸਹੀ ਪਤਾ ਮੋੜਨ ਵਾਲਾ ਨਾਮ-ਹੱਲ, ਅਤੇ ਗਾਹਕ ਵੱਲ ਵਾਪਸੀ ਦਾ ਰਾਹਚਾਹੀਦਾ ਹੈ।

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

ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਟਨਲ ਕੌਣ ਬਣਾਉਂਦਾ ਹੈ, ਫਿਰ ਬਾਕੀ ਨਾਕਾਮੀ ਦਾ ਨਿਦਾਨ ਉਸਦੀ ਆਪਣੀ ਪਰਤ 'ਤੇ ਕਰੋ। AWS ਸ਼ੁਰੂਆਤ ਬਾਰੇ ਦਸਤਾਵੇਜ਼ ਕੰਸੋਲ ਦੇ ਸੰਕੇਤਾਂ ਨਾਲੋਂ ਪਤਾ, ਪਛਾਣ ਅਤੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਦੀਆਂ ਲੋੜਾਂ ਵਧੇਰੇ ਵਿਸਥਾਰ ਨਾਲ ਕਵਰ ਕਰਦਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ