peered VPC ਤੱਕ ਪਹੁੰਚਣ ਲਈ AWS Client VPN ਜਾਂ bastion

ਇੱਕ Client VPN endpoint ਆਪਣੇ ਸੰਬੰਧਿਤ VPC ਨਾਲ peered VPC ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਕਾਨੂੰਨੀ ਬਣਾਉਣ ਲਈ ਤੁਹਾਨੂੰ bastion ਦੀ ਲੋੜ ਨਹੀਂ। ਕਰਨ ਯੋਗ ਚੋਣ ਇਹ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਕਿੱਥੇ ਹੱਥ ਬਦਲਦਾ ਹੈ: endpoint ਰੂਟ ਜੋ association ਸਬਨੈੱਟ ਵਿੱਚ ਉਤਰਦਾ ਹੈ ਅਤੇ peering ਕਨੈਕਸ਼ਨ ਲੰਘਦਾ ਹੈ, ਜਾਂ peered VPC ਵਿੱਚ host ਜੋ ਸੈਸ਼ਨ ਖਤਮ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਰਾਹ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਵੱਖਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਫੈਸਲਾ ਮਾਲਕੀ ਅਤੇ ਆਡਿਟ ਬਾਰੇ ਹੈ, AWS ਕੀ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ ਇਸ ਬਾਰੇ ਨਹੀਂ। ਇੱਥੇ ਮੈਂ ਉਹਨਾਂ ਵਿਚਕਾਰ ਕਿਵੇਂ ਚੁਣਦਾ ਹਾਂ, ਅਤੇ routed ਰਾਹ ਨੂੰ ਕੰਮ ਕਰਾਉਣ ਵਾਲੀਆਂ ਚਾਰ ਐਂਟਰੀਆਂ ਹਨ।

ਦੋ ਰਾਹ, ਇੱਕ endpoint, ਵੱਖਰੇ ਮਾਲਕ

routed ਰਾਹ 'ਤੇ ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ endpoint ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, association ਸਬਨੈੱਟ ਵਿੱਚ Client VPN ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਦੇ ਪਤੇ ਵਿੱਚ ਤਬਦੀਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ A ਤੋਂ B ਤੱਕ peering ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਉਸ ਸਬਨੈੱਟ ਨੂੰ ਛੱਡਦਾ ਹੈ। VPC B ਕੋਈ VPN ਸੈਸ਼ਨ ਖਤਮ ਨਹੀਂ ਕਰਦਾ; ਇਹ VPC A ਤੋਂ ਆਮ ਟ੍ਰੈਫਿਕ ਦੇਖਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਦਾ ਰਿਟਰਨ ਰੂਟ ਕਲਾਇੰਟ ਪੂਲ ਵੱਲ ਨਹੀਂ, VPC A ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

bastion ਰਾਹ 'ਤੇ ਕਲਾਇੰਟ ਪਹਿਲਾਂ host ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। A ਵਿੱਚ bastion ਅਜੇ ਵੀ ਆਖਰੀ ਹੌਪ ਨੂੰ peering ਕਨੈਕਸ਼ਨ ਲੰਘਣ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ peering ਕੰਮ ਬਚਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸੈਸ਼ਨ ਵਧਦਾ ਹੈ। B ਵਿੱਚ bastion ਨੂੰ ਵੀ ਕਲਾਇੰਟ ਤੋਂ ਰਾਹ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਉਹ ਰਾਹ ਉਹੀ endpoint ਰੂਟ ਹੋਵੇ, routed ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਇੱਕ ਹੌਪ ਵਧ ਜਾਂਦਾ ਹੈ। bastion ਕੰਮ ਘਟਾਉਂਦਾ ਹੈ ਸਿਰਫ਼ ਤਦ ਜਦੋਂ ਇਹ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ, ਪਹਿਲਾਂ ਹੀ ਮਨਜ਼ੂਰ ਹੈ, ਅਤੇ ਇਸਦੇ ਪਿੱਛੇ ਦੀ ਚੀਜ਼ ਨੂੰ ਨੈੱਟਵਰਕ ਸੀਮਾ ਦੀ ਥਾਂ ਸੈਸ਼ਨ ਸੀਮਾ ਚਾਹੀਦੀ ਹੈ।

ਚਾਰ ਐਂਟਰੀਆਂ routed ਰਾਹ ਨੂੰ ਕੰਮ ਕਰਾਉਂਦੀਆਂ ਹਨ

AWS ਇਸ ਦ੍ਰਿਸ਼ ਨੂੰ Client VPN how-it-works ਪੰਨੇ 'ਤੇ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਮਲ ਵਿੱਚ ਇਹ ਦੋ ਜਾਂ ਤਿੰਨ ਟੀਮਾਂ ਦੀਆਂ ਚਾਰ ਐਂਟਰੀਆਂ 'ਤੇ ਆਉਂਦਾ ਹੈ। ਰੇਂਜਾਂ ਉਦਾਹਰਨ ਲਈ ਹਨ; peered ਰੇਂਜ ਵਿਲੱਖਣ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਰਿਟਰਨ ਰੇਂਜ ਤੁਹਾਡੀ ਯੋਜਨਾ ਨਾਲ ਮੇਲ ਖਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਰੂਟ ਅਤੇ ਇਜਾਜ਼ਤ ਵੱਖਰੇ ਕੰਟਰੋਲ ਹਨ। ਮੇਲ ਖਾਂਦੇ ਅਧਿਕਾਰ ਨਿਯਮ ਤੋਂ ਬਿਨਾਂ ਸਹੀ endpoint ਰੂਟ ਕਲਾਇੰਟ ਨੂੰ ਕੁਝ ਨਹੀਂ ਦਿੰਦਾ; endpoint ਰੂਟ ਨਾ ਕਰ ਸਕਣ ਵਾਲੀ ਮੰਜ਼ਿਲ ਲਈ ਅਧਿਕਾਰ ਨਿਯਮ ਉਸ ਨੂੰ ਕਾਲਾ ਟੋਆ ਦਿੰਦਾ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਇੱਕੋ ਰੇਂਜ ਦਾ ਨਾਮ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ।

endpoint ਰੂਟ endpoint ਦੇ ਆਪਣੇ VPC ਦੇ ਸਬਨੈੱਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਕਦੇ ਵੀ peering ਕਨੈਕਸ਼ਨ ਵੱਲ ਨਹੀਂ। VPC ਰੂਟ ਟੇਬਲ peering ਕਨੈਕਸ਼ਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਕਦੇ ਵੀ instance ਜਾਂ ਇੰਟਰਫੇਸ ਵੱਲ ਨਹੀਂ। ਦੋਵਾਂ ਵਿਚਕਾਰ ਮੁੱਲ ਕਾਪੀ ਕਰਨਾ ਬਿਨਾਂ ਸ਼ਿਕਾਇਤ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕੁਝ ਰੂਟ ਨਹੀਂ ਕਰਦਾ।

ਕਿਉਂਕਿ association ਸਬਨੈੱਟ ਕਲਾਇੰਟ ਦਾ ਸਰੋਤ ਤਬਦੀਲ ਕਰਦਾ ਹੈ, B ਨੂੰ ਕਲਾਇੰਟ ਪੂਲ ਵੱਲ ਨਹੀਂ, VPC A ਵੱਲ ਵਾਪਸ ਰੂਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। peering ਕਨੈਕਸ਼ਨ 'ਤੇ ਕਲਾਇੰਟ ਰੇਂਜ ਭੇਜਣਾ ਸਮਮਿਤ ਲੱਗਦਾ ਹੈ, ਸਮੀਖਿਆ ਪਾਸ ਕਰਦਾ ਹੈ ਅਤੇ ਚੁੱਪਚਾਪ ਫੇਲ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ B ਕਦੇ ਵੀ ਕਲਾਇੰਟ ਸਰੋਤ ਵਾਲਾ ਪੈਕਟ ਨਹੀਂ ਦੇਖਦਾ।

ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਅਤੇ ਇਜਾਜ਼ਤ ਦਾ ਆਖਰੀ ਮੀਟਰ

ਰੂਟਿੰਗ ਪੈਕਟ B ਵਿੱਚ ਲਿਆਉਂਦੀ ਹੈ; ਫੈਸਲਾ B ਅਜੇ ਵੀ ਲੈਂਦਾ ਹੈ। ਇੱਕੋ ਖੇਤਰ ਵਿੱਚ ਸਰਗਰਮ peering ਕਨੈਕਸ਼ਨ ਲਈ, B ਵਿੱਚ ਸੁਰੱਖਿਆ ਗਰੁੱਪ Client VPN association 'ਤੇ ਲਾਗੂ ਗਰੁੱਪ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦਾ ਹੈ, ਜੋ ਨਿਯਮ ਨੂੰ ਤੰਗ ਰੱਖਦਾ ਹੈ ਅਤੇ ਪਤੇ ਬਦਲਣ 'ਤੇ ਟਿਕਦਾ ਹੈ। ਜਿੱਥੇ ਗਰੁੱਪ ਹਵਾਲਾ ਸੰਭਵ ਨਹੀਂ, ਉੱਥੇ 0.0.0.0/0 ਤੱਕ ਚੌੜਾ ਕਰਨ ਦੀ ਥਾਂ association ਸਬਨੈੱਟ ਰੇਂਜ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਮਨਜ਼ੂਰ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਰੂਟਿੰਗ ਗਲਤੀ ਨੂੰ ਬਿਨਾਂ ਵਜ੍ਹਾ ਟਾਈਮਆਉਟ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਫਿਰ ਜਾਂਚੋ ਕਿ ਰੂਟਿੰਗ ਕਦੇ ਵੀ ਕਿਸ ਨੂੰ ਨਹੀਂ ਛੂਹੰਦੀ: ਦੋਵੇਂ ਸਬਨੈੱਟਾਂ 'ਤੇ ਨੈੱਟਵਰਕ ACL, ਐਪਲੀਕੇਸ਼ਨ ਦੀ allow-list ਜਾਂ ਟੋਕਨ ਦਰਸ਼ਕ, ਅਤੇ DNS। peering ਨਿੱਜੀ ਹੋਸਟਿਡ ਜ਼ੋਨ ਕਾਪੀ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਲੈਪਟਾਪ ਉਸ ਪਤੇ ਤੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰੂਟ ਰੱਖ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਉਹ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ peering ਕਨੈਕਸ਼ਨ ਸਰਟੀਫਿਕੇਟ ਵਿੱਚ ਭਰੋਸਾ ਨਹੀਂ ਜੋੜਦਾ। endpoint ਨੂੰ B ਲਈ ਜਵਾਬ ਦੇਣ ਵਾਲੇ resolver ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ, ਫਿਰ ਪੱਕਾ ਕਰੋ ਕਿ ਨਿੱਜੀ ਨਾਮ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਮੇਲ ਖਾਂਦੇ ਹਨ।

bastion ਕਦੋਂ ਇਮਾਨਦਾਰ ਜਵਾਬ ਹੈ

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

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ peering ਦੇ ਟ੍ਰਾਂਜ਼ਿਟਿਵ ਨਾ ਹੋਣ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਰਾਹ ਨਹੀਂ ਹੈ। ਗੈਰ-ਟ੍ਰਾਂਜ਼ਿਟਿਵਿਟੀ ਸੀਮਿਤ ਕਰਦੀ ਹੈ ਕਿ B ਦੇ ਸਰੋਤ ਕੀ ਕਰ ਸਕਦੇ ਹਨ: ਉਹ A ਨੂੰ A ਨਾਲ peered ਤੀਜੇ VPC ਵੱਲ ਟ੍ਰਾਂਜ਼ਿਟ ਵਜੋਂ ਨਹੀਂ ਵਰਤ ਸਕਦੇ। ਇਸਦਾ ਮਤਲਬ ਕਦੇ ਵੀ ਇਹ ਨਹੀਂ ਸੀ ਕਿ VPN ਵਰਤੋਂਕਾਰ ਸਿੱਧਾ peered VPC ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ, ਅਤੇ ਉਸ ਗਲਤ ਪੜ੍ਹਤ ਨੂੰ ਟਾਲਣ ਲਈ ਬਣਾਇਆ bastion ਬਿਨਾਂ ਕਾਰਨ ਪੈਚ ਕਰਨ ਵਾਲਾ host ਹੈ।

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

Transit Gateway ਅਤੇ ਕਈ association ਗਣਨਾ ਬਦਲਦੇ ਹਨ

ਜੇ endpoint ਸਬਨੈੱਟ ਦੀ ਥਾਂ ਸਿੱਧਾ Transit Gateway ਨਾਲ ਜੁੜਿਆ ਹੈ, ਤਾਂ ਮਾਡਲ ਬਦਲਦਾ ਹੈ: ਕਲਾਇੰਟ ਹੁਣ association ਸਬਨੈੱਟ ਦੇ ਇੰਟਰਫੇਸ ਪਤੇ ਵਿੱਚ ਤਬਦੀਲ ਨਹੀਂ ਹੁੰਦੇ, ਅਤੇ gateway ਰੂਟ ਟੇਬਲ ਨੂੰ ਕਲਾਇੰਟ ਰੇਂਜ ਅਤੇ peered VPC ਵੱਲ ਲੈ ਜਾਣ ਵਾਲੀ ਜੁੜਨ ਦੋਵੇਂ ਚੁੱਕਣੇ ਪੈਂਦੇ ਹਨ। ਇਹ ਪੈਮਾਨੇ 'ਤੇ ਸਾਫ਼ ਹੈ, ਪਰ ਕੰਮ ਚਾਰ ਐਂਟਰੀਆਂ ਤੋਂ gateway ਰੂਟ ਟੇਬਲਾਂ ਵੱਲ ਚਲਾ ਜਾਂਦਾ ਹੈ।

ਕਈ association ਜਾਂਚਾਂ ਨੂੰ ਗੁਣਾ ਕਰਦੇ ਹਨ। endpoint ਰੂਟ endpoint ਦਾ ਹੈ, ਫਿਰ ਵੀ ਹਰ association ਸਬਨੈੱਟ ਨੂੰ ਅਸਲ peering ਅਗਲੇ ਹੌਪ ਵਾਲਾ ਰੂਟ ਟੇਬਲ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ association ਰਾਹੀਂ ਸੈਸ਼ਨ ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦੂਜੇ ਕੋਲ ਰਿਟਰਨ ਰਾਹ ਨਹੀਂ, ਇਸ ਲਈ ਹਰ ਇੱਕ ਨੂੰ ਪਰਖੋ।

ਭੰਗ ਜਲਦੀ ਲੱਭਣ ਵਾਲਾ ਪ੍ਰਮਾਣਿਕਤਾ ਕ੍ਰਮ

ਇਹਨਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਚਲਾਓ; ਹਰ ਕਦਮ ਪਾਸ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਅਗਲਾ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਟਾਈਮਆਉਟ ਲਗਭਗ ਕਦੇ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜਾ ਟੁੱਟਾ।

1. ਕਲਾਇੰਟ ਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਨਾਮ ਹੱਲ ਕਰੋ ਅਤੇ ਜਾਂਚੋ ਕਿ ਪਤਾ peered ਰੇਂਜ ਦੇ ਅੰਦਰ ਹੈ।
2. ਕਨੈਕਟ ਕਰੋ, ਫਿਰ ਸੈਸ਼ਨ ਖਤਮ ਕਰਨ ਵਾਲੇ association ਲਈ endpoint ਕਨੈਕਸ਼ਨ ਲਾਗ ਪੜ੍ਹੋ।
3. ਉਸ association ਸਬਨੈੱਟ 'ਤੇ, ਪੱਕਾ ਕਰੋ ਕਿ ਰੂਟ ਟੇਬਲ peered ਰੇਂਜ ਨੂੰ ਸਰਗਰਮ peering ਕਨੈਕਸ਼ਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
4. B ਦੇ ਸਰੋਤ ਸਬਨੈੱਟ 'ਤੇ, ਇੰਟਰਫੇਸ ਰੇਂਜ ਲਈ ਰਿਟਰਨ ਐਂਟਰੀ ਅਤੇ ਮੇਲ ਖਾਂਦੇ ਗਰੁੱਪ ਨਿਯਮ ਪੱਕੇ ਕਰੋ।
5. ਇੱਕ ਮਨਜ਼ੂਰ ਕਾਰਵਾਈ ਅਤੇ ਇੱਕ ਅਜਿਹਾ ਸਰੋਤ ਪਰਖੋ ਜੋ ਨਾ ਪਹੁੰਚਣ ਯੋਗ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ; ਦੂਜਾ ਡੀਬੱਗਿੰਗ ਦੇ ਬਚੇ ਹੋਏ ਹਿੱਸੇ ਫੜਦਾ ਹੈ।
6. ਕਿਸੇ ਵੀ split-tunnel ਰੂਟ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰੋ, ਕਿਉਂਕਿ ਚੱਲ ਰਿਹਾ ਟਨਲ ਨਵਾਂ ਰੂਟ ਸੈੱਟ ਨਹੀਂ ਲਵੇਗਾ।

ਯਾਦ ਰੱਖਣ ਯੋਗ ਦੋ ਲੱਛਣ ਹਨ। ਜਵਾਬ ਤੋਂ ਬਿਨਾਂ B ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ SYN ਲਗਭਗ ਹਮੇਸ਼ਾ ਗੁੰਮ ਰਿਟਰਨ ਰੂਟ ਹੁੰਦਾ ਹੈ। ਪੂਰਾ ਹੋ ਕੇ ਫਿਰ ਰੀਸੈਟ ਹੋਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਗਰੁੱਪ, ACL ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਹੁੰਦਾ ਹੈ। ਦੋਵੇਂ endpoint ਲਾਗ ਵਿੱਚ ਕਾਰਨ ਵਜੋਂ ਨਹੀਂ ਦਿਖਦੇ, ਇਸ ਲਈ ਚਾਰ ਐਂਟਰੀਆਂ ਹਰ ਇੱਕ ਦੇ ਕੋਲ ਮਾਲਕ ਨਾਲ ਰੱਖੋ।

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