ਕਈ NIC ਵਾਲੀ GCP VM: ਜਵਾਬ ਗਲਤ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਕਿਉਂ ਨਿਕਲਦੇ ਹਨ

Compute Engine VM ਵਿੱਚ ਦੂਜਾ ਇੰਟਰਫ਼ੇਸ ਜੋੜਨ ਨਾਲ ਉਸ ਨੂੰ ਇੱਕ ਹੋਰ ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨ ਮਿਲਦਾ ਹੈ, ਸਮਮਿਤ ਪਰਤਣ ਦਾ ਰਾਹ ਨਹੀਂ। ਗੈਸਟ ਅਜੇ ਵੀ ਆਪਣੇ ਹੀ ਰੂਟ ਅਤੇ ਨਿਯਮਾਂ ਤੋਂ ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਸਰੋਤ ਪਤਾ ਚੁਣਦਾ ਹੈ। ਫਿਰ Google Cloud ਪੈਕੇਟ ਜਿਸ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਨਿਕਲਿਆ ਉਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ VPC ਰੂਟਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਨੀਤੀ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਦੋ ਫ਼ੈਸਲੇ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਬੇਨਤੀਆਂ ਇੱਕ NIC ਉੱਤੇ ਆਉਂਦੀਆਂ ਹਨ ਅਤੇ ਜਵਾਬ ਦੂਜੇ ਰਾਹੀਂ ਨਿਕਲਦੇ ਹਨ, ਅਤੇ ਸ਼ਾਖਾ ਅੱਧਾ ਖੁੱਲ੍ਹਾ ਸੰਵਾਦ ਦੇਖਦੀ ਹੈ।

ਪੰਜ ਕਦਮਾਂ ਵਿੱਚ ਰਾਹ ਚੱਲੋ ਅਤੇ ਨੀਤੀ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸੰਗਤੀ ਦਿਖੇਗੀ।

ਕਦਮ 1: ਕਲਾਊਡ NIC ਨੂੰ ਗੈਸਟ ਡਿਵਾਈਸਾਂ ਨਾਲ ਮਿਲਾਓ

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

ਪਤੇ, ਡਿਵਾਈਸ ਨਾਮ ਅਤੇ ਹਰ ਇੱਕ ਦਾ VPC ਲਿਖੋ। ਉਹ ਤਿੰਨ-ਕਾਲਮ ਨਕਸ਼ਾ ਹਰ ਅਗਲੇ ਕਦਮ ਦਾ ਇਨਪੁਟ ਹੈ।

ਕਦਮ 2: ਦੋ ਰੂਟਿੰਗ ਫ਼ੈਸਲਿਆਂ ਦੇ ਨਾਮ ਦਿਓ

ਪਹਿਲਾ ਫ਼ੈਸਲਾ ਗੈਸਟ ਦਾ ਹੈ: ਇਸ ਪੈਕੇਟ ਲਈ ਕਿਹੜਾ ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਕਿਹੜਾ ਸਰੋਤ ਪਤਾ। ਦੂਜਾ ਕਲਾਊਡ ਦਾ ਹੈ: VPC ਦੇ ਰੂਟ ਅਤੇ ਫਾਇਰਵਾਲ ਨੀਤੀ ਉਸ ਇੰਟਰਫ਼ੇਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦੇ ਹਨ।

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

ਕਦਮ 3: ਪਰਤਣ ਦੇ ਰਾਹ ਦੀ ਨੀਤੀ ਚੁਣੋ

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

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

ਕਦਮ 4: ਗੈਸਟ ਦੇ ਆਪਣੇ ਫਿਲਟਰ ਜਾਂਚੋ

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

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

ਕਦਮ 5: ਹਰ ਰਾਹ ਲਈ ਇੱਕ ਪ੍ਰਵਾਹ ਜਾਂਚੋ

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

ਦੋਵੇਂ ਪਰਖ ਆਪਣੀਆਂ ਨੋਟਾਂ ਵਿੱਚ ਵੱਖਰੀਆਂ ਰੱਖੋ, ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੇ ਰੂਟ ਅਤੇ ਵੱਖਰੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਵਰਤਦੀਆਂ ਹਨ।

ਦੂਜੀ NIC ਤੁਹਾਨੂੰ ਕੀ ਨਹੀਂ ਦਿੰਦੀ

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

ਜੇ VM ਨੂੰ ਹੋਰ ਮਸ਼ੀਨਾਂ ਦਾ ਟ੍ਰੈਫ਼ਿਕ ਅੱਗੇ ਭੇਜਣਾ ਹੈ, ਤਾਂ ਉਹ ਰਾਊਟਰ ਭੂਮਿਕਾ ਸਪਸ਼ਟ ਤੌਰ ਉੱਤੇ ਯੋਜਨਾ ਕਰੋ, ਜਿਸ ਵਿੱਚ ਫ਼ਾਰਵਰਡਿੰਗ ਦੀ ਮਨਜ਼ੂਰੀ ਦੇਣ ਵਾਲੀ ਕਲਾਊਡ ਸੈਟਿੰਗ ਅਤੇ ਉਸ ਨਾਲ ਜਾਣ ਵਾਲੇ ਗੈਸਟ ਫਿਲਟਰ ਸ਼ਾਮਲ ਹਨ।