GCE 'ਤੇ OpenVPN: ਰੂਟ push ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ alias IP ਸ਼ਾਮਲ ਕਰੋ

push ਕੀਤਾ ਰੂਟ VM ਨੂੰ next hop ਨਹੀਂ ਬਣਾਉਂਦਾ। alias IP ਰੇਂਜ ਸ਼ਾਮਲ ਕਰੋ, ਇਸ ਨੂੰ ਸਰਵਰ ਦੇ pool ਨਾਲ ਮਿਲਾਓ ਅਤੇ ਕਲਾਇੰਟ ਟੈਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ VPC ਵਿੱਚ ਵਾਪਸੀ ਰੂਟ ਬਣਾਓ।

ਇੱਕ ਕਲਾਇੰਟ Compute Engine VM 'ਤੇ OpenVPN ਸਰਵਰ ਨੂੰ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਸਟੇਟਸ ਵਿੰਡੋ ਕਹਿੰਦੀ ਹੈ ਜੁੜਿਆ, ਅਤੇ VPC ਦੇ ਅੰਦਰ ਇੱਕ ਹੋਸਟ ਨੂੰ ping ਅਜੇ ਵੀ ਕਿਤੇ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਸੁਭਾਵਕ ਰੁਝਾਨ ਕਹਿੰਦਾ ਹੈ ਇੱਕ ਹੋਰ push ਲਾਈਨ ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਇਹ ਕਦੇ ਵੀ ਠੀਕ ਨਹੀਂ ਕਰਦੀ। Compute Engine ਆਪਣੀ ਰੂਟ ਟੇਬਲ ਅਤੇ VM ਦੇ ਇੰਟਰਫੇਸ ਕੋਲ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਪਤਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਪੈਕਟ ਕਿੱਥੇ ਜਾਣਗੇ, ਇਸ ਲਈ ਜੋ tunnel pool VM ਦੀ ਮਲਕੀਅਤ ਵਿੱਚ ਨਹੀਂ ਹੈ ਉਹ pool ਹੈ ਜਿੱਥੇ ਕੋਈ ਨਹੀਂ ਪਹੁੰਚਾਉਂਦਾ।

ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਦੀ ਥਾਂ ਫੇਲ੍ਹ ਹੋ ਰਹੇ ਪੈਕਟ ਦਾ ਪਿੱਛਾ ਕਰੋ, ਅਤੇ ਗੁੰਮ ਹਿੱਸੇ ਕ੍ਰਮ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣਗੇ।

ਮਰ ਰਹੇ ਪੈਕਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

SYN ਕਲਾਇੰਟ ਛੱਡਦਾ ਹੈ, tunnel ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ ਅਤੇ VPC ਦੇ ਅੰਦਰ ਇੱਕ ਮੰਜ਼ਿਲ ਲਈ encapsulated ਪੈਕਟ ਵਜੋਂ VM ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। OpenVPN ਇਸਨੂੰ decapsulate ਕਰਦਾ ਹੈ ਅਤੇ eth0 ਰਾਹੀਂ ਭੇਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ fabric ਹਰ ਚੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ: ਕੀ ਇਹ ਇੰਸਟੈਂਸ ਮੰਜ਼ਿਲ ਪਤੇ ਦਾ ਮਾਲਕ ਹੈ। ਦੂਜੇ ਦੇ subnet ਵਿੱਚੋਂ ਕੱਟਿਆ tunnel pool ਉਸ ਸਵਾਲ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਰੂਟ ਜਾਂ firewall ਨਿਯਮ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕਟ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਇਸ ਲਈ ਕਲਾਇੰਟ ਤੋਂ VPC ਦਿਸ਼ਾ ਦੀਆਂ ਦੋ ਵੱਖਰੀਆਂ ਲੋੜਾਂ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ push ਨਿਰਦੇਸ਼ ਨਹੀਂ। VM ਨੂੰ tunnel pool ਢਕਣ ਵਾਲੀ alias ਰੇਂਜ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਇਸਨੂੰ ਉਨ੍ਹਾਂ ਪਤਿਆਂ ਦਾ ਜਾਇਜ਼ ਮਾਲਕ ਬਣਾਉਂਦੀ ਹੈ। VPC ਨੂੰ ਅਜਿਹਾ ਰੂਟ ਚਾਹੀਦਾ ਹੈ ਜੋ ਹਰ ਸੁਰੱਖਿਅਤ prefix ਲਈ VM ਨੂੰ next hop ਵਜੋਂ ਨਾਮ ਦੇਵੇ। ਇੱਕ ਵੀ ਗੁੰਮ ਹੋਵੇ ਤਾਂ ਪੈਕਟ ਕਿਤੇ ਹੋਰ ਮਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਕਲਾਇੰਟ ਨੂੰ ਉਹੀ ਖਾਮੋਸ਼ੀ ਦਿਖਦੀ ਹੈ।

ਨੁਕਸ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਪਾਸਿਓਂ ਦੋਵੇਂ ਸ਼ਰਤਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਲੱਗਦੀਆਂ ਹਨ। ਜੋ tunnel ਜੁੜਿਆ ਦੱਸਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਵੀ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ, ਉਹ ਟੋਪੋਲੋਜੀ ਸਮੱਸਿਆ ਦਾ ਨਿਸ਼ਾਨ ਹੈ, ਖਰਾਬ cipher ਦਾ ਨਹੀਂ।

ਕੀ ਇੰਸਟੈਂਸ tunnel pool ਦਾ ਮਾਲਕ ਹੈ

VM ਨੂੰ ਆਪਣੇ subnet ਦੇ ਅੰਦਰ ਗੌਣ ਰੇਂਜ ਦਿਓ, ਫਿਰ OpenVPN ਬਿਲਕੁਲ ਉਸੇ ਰੇਂਜ ਵਿੱਚੋਂ ਪਤੇ ਵੰਡੇ। ਜਿਸ ਇੰਸਟੈਂਸ ਦਾ ਪ੍ਰਾਇਮਰੀ ਪਤਾ 10.156.0.10/20 ਹੈ, ਉੱਥੇ /28 alias pool ਨੂੰ ਦੂਜੇ ਇੰਸਟੈਂਸਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਪਤਿਆਂ ਤੋਂ ਵੱਖ ਰੱਖਦੀ ਹੈ:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

ਫਿਰ server ਨਿਰਦੇਸ਼ ਨੂੰ ਉਹੀ ਬਲਾਕ ਬਿਆਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਦਾ ਪਹਿਲਾ ਪਤਾ tunnel ਦਾ gateway ਬਣਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਪਤੇ ਕਲਾਇੰਟਾਂ ਨੂੰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਇੱਥੇ ਦੋ ਸੰਖਿਆਵਾਂ ਇੱਕ ਬਲਾਕ ਬਿਆਨ ਕਰਦੀਆਂ ਹਨ, ਇੱਕ ਨੈੱਟਵਰਕ ਅਤੇ ਇੱਕ netmask, ਅਤੇ ਇਹੀ ਉਹ pool ਸੰਟੈਕਸ ਹੈ ਜਿਸਦੀ OpenVPN ਅਜੇ ਵੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।

server 10.156.1.0 255.255.255.240

ਪੱਕਾ ਕਰੋ ਕਿ ਪਤਾ ਸੱਚਮੁੱਚ ਇੰਟਰਫੇਸ 'ਤੇ ਪਹੁੰਚਿਆ ਹੈ, ਸਿਰਫ਼ OpenVPN ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ। fabric ਉਹੀ ਭੇਜਦਾ ਹੈ ਜੋ NIC ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ, ਉਹ ਨਹੀਂ ਜੋ daemon ਮੰਨਦਾ ਹੈ। ਇੱਕ ਹੁਕਮ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ:

ip -4 addr show dev eth0

ਗੌਣ ਪਤਾ ਜੋ ਕਦੇ eth0 ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਜਾਂ pool ਜੋ ਕਿਸੇ ਹੋਰ subnet ਨਾਲ ਓਵਰਲੈਪ ਕਰਦਾ ਹੈ, ਬਾਅਦ ਵਿੱਚ ਸ਼ੁਰੂਆਤੀ ਗਲਤੀ ਵਜੋਂ ਨਹੀਂ ਸਗੋਂ ਵਿਰਾਮ ਨਾਲ ਪੈਕਟ ਲੋਸ ਵਜੋਂ ਦਿਖਦਾ ਹੈ। daemon ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਕਲਾਇੰਟ ਜੁੜਦੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਕੁਝ ਮੰਜ਼ਿਲਾਂ ਗਲਤ ਵਿਵਹਾਰ ਕਰਦੀਆਂ ਹਨ। alias ਰੇਂਜ ਛੋਟੀ ਰੱਖੋ ਤਾਂ ਜੋ ਰੂਟ ਟੇਬਲ ਵਿੱਚ pool ਸੌਖਿਆਂ ਪਛਾਣਿਆ ਜਾਵੇ। ਇਸਨੂੰ ਕਦੇ ਵੀ ਉਸ subnet ਵਿੱਚੋਂ ਨਾ ਕੱਟੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਹੋਰ ਇੰਸਟੈਂਸ ਕੋਲ ਹੈ।

ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਨੂੰ next hop ਦਿਓ

VPC ਦੇ ਹੋਸਟ ਤੋਂ ਜਵਾਬ tunnel pool ਵਿੱਚ ਕਲਾਇੰਟ ਪਤੇ ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ VPC ਦੇ ਕਿਸੇ ਵੀ ਜਾਣੇ subnet ਦਾ ਹਿੱਸਾ ਨਹੀਂ। ਉਸ pool ਲਈ ਰੂਟ ਤੋਂ ਬਿਨਾਂ ਜਵਾਬ ਪਹਿਲੇ ਅਜਿਹੇ hop 'ਤੇ ਰੁਕਦਾ ਹੈ ਜਿੱਥੇ ਮੇਲ ਨਹੀਂ, ਅਤੇ ਬੇਨਤੀ ਦੂਜੇ ਸਿਰੇ 'ਤੇ ਕਾਮਯਾਬ ਵੀ ਹੋ ਸਕਦੀ ਹੈ।

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

ਉਹੀ ਰੂਟ ਹਰ ਉਸ prefix ਲਈ ਲੋੜੀਂਦਾ ਹੈ ਜੋ VPC ਦੇ ਅੰਦਰ ਨਹੀਂ ਸਗੋਂ ਕਲਾਇੰਟ ਦੇ ਪਿੱਛੇ ਹੈ। ਉਨ੍ਹਾਂ prefixਾਂ ਨੂੰ ਉਸ ਕਲਾਇੰਟ ਦੀ ccd ਫਾਈਲ ਵਿੱਚ iroute ਐਂਟਰੀ ਵੀ ਚਾਹੀਦੀ ਹੈ। ਉਹ ਐਂਟਰੀ ਸਰਵਰ ਪਾਸੇ ਦੀ ਹਿਸਾਬ-ਕਿਤਾਬ ਹੈ: ਇਹ ਸਰਵਰ ਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਕਲਾਇੰਟ prefix ਦਾ ਮਾਲਕ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਉੱਤੇ ਆਪ ਕੁਝ ਵੀ ਇੰਸਟਾਲ ਨਹੀਂ ਕਰਦੀ।

push ਸੂਚੀ ਗੱਲਬਾਤ ਦੇ ਕਲਾਇੰਟ ਪਾਸੇ ਲਈ ਰੱਖੋ, ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ਼ ਜੁੜ ਰਹੀ ਮਸ਼ੀਨ 'ਤੇ ਰੂਟ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ। VPC subnet ਲਈ push ਲਾਈਨ ਅਤੇ pool ਵੱਲ ਵਾਪਸ VPC ਰੂਟ ਇੱਕੋ ਰਾਹ ਦੇ ਦੋ ਅੱਧੇ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਅੱਧਾ ਇਕੱਲਾ ਅਜਿਹਾ tunnel ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਬੇਨਤੀਆਂ ਲੈ ਜਾਂਦਾ ਹੈ ਪਰ ਜਵਾਬ ਨਹੀਂ।

Firewall, forwarding ਅਤੇ ਵਿਚਕਾਰਲੇ hop

VPC ਦਾ firewall decapsulated ਪੈਕਟ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ingress ਨਿਯਮ ਨੂੰ tunnel pool ਅਤੇ ਹਰ ਉਸ site prefix ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਉਸ ਰਾਹੀਂ VM ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। default-deny ਰਵੱਈਆ ਇੱਥੇ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ: decapsulation ਤੋਂ ਬਾਅਦ ਪੈਕਟ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ OpenVPN ਲਾਗ ਸਿਹਤਮੰਦ ਸੈਸ਼ਨ ਦਿਖਾਉਂਦੀ ਹੈ।

ਹਰ ਉਸ Linux ਹੋਸਟ 'ਤੇ ਜੋ terminate ਕਰਨ ਦੀ ਥਾਂ forward ਕਰਦਾ ਹੈ, ਵੇਖੋ ਕਿ net.ipv4.ip_forward ਚਾਲੂ ਹੈ। ਮਾਲਕੀਅਤ ਦਾ ਨਿਯਮ ਉੱਥੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਜੋ ਮਸ਼ੀਨ ਆਪਣੇ ਕੋਲ ਨਾ ਹੋਣ ਵਾਲੇ subnet ਲਈ forward ਕਰਦੀ ਹੈ ਉਹ VM ਵਾਂਗ ਪੈਕਟ ਸੁੱਟਦੀ ਹੈ। tunnel ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਲ ਪੜ੍ਹੋ।

ਜਦੋਂ ਠੀਕ ਇੱਕ prefix ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ

ਅੰਸ਼ਕ ਫੇਲ੍ਹ ਹੋਣਾ ਪੜ੍ਹਨ ਲਈ ਸਭ ਤੋਂ ਸੌਖਾ ਮਾਮਲਾ ਹੈ, ਕਿਉਂਕਿ ਰਾਹ ਦੀ ਬਾਕੀ ਹਰ ਚੀਜ਼ ਪਹਿਲਾਂ ਹੀ ਸਾਬਤ ਹੋ ਚੁੱਕੀ ਹੈ। ਰੂਟ ਸੂਚੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਉਸ ਐਂਟਰੀ ਦੀ ਮੰਜ਼ਿਲ ਰੇਂਜ ਅਤੇ next hop ਪੜ੍ਹੋ ਜਿਸਨੂੰ prefix ਢਕਣਾ ਚਾਹੀਦਾ ਹੈ, ਫਿਰ ਇੰਸਟੈਂਸ ਦਾ ਵੇਰਵਾ ਪੜ੍ਹੋ ਅਤੇ ਇਸਦੀ alias ਰੇਂਜ ਦੀ ਸਰਵਰ ਵੱਲੋਂ ਵੰਡੇ pool ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

ਗੁੰਮ ਰੂਟ prefix ਲਈ next hop ਨਾ ਹੋਣ ਵਜੋਂ ਦਿਖਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਗੁੰਮ alias ਇੰਟਰਫੇਸ 'ਤੇ ਸੁੱਟੇ ਪੈਕਟ ਵਜੋਂ; ਕਲਾਇੰਟ ਤੋਂ ਦੋਵੇਂ ਇੱਕੋ ਜਿਹੇ ਲੱਗਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਦੋ ਆਉਟਪੁੱਟਾਂ ਵਿੱਚ ਬਿਲਕੁਲ ਵੱਖਰੇ ਹਨ। ਜੇ ਦੋਵੇਂ ਹਾਜ਼ਰ ਹੋਣ, ਬਾਕੀ ਸ਼ੱਕੀ ਉਸ ਕਲਾਇੰਟ ਦੀ ccd iroute ਹੈ ਜੋ prefix ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ।

ਚਾਰ ਮੁੱਲ tunnel ਦੇ ਕੋਲ ਲਿਖੋ: alias ਰੇਂਜ, ਸਰਵਰ ਦਾ pool, push ਕੀਤੇ prefix, VPC ਰੂਟ। ਪੁਰਾਣੀ alias pool ਦੇ ਹਰ ਪਤੇ ਨੂੰ ਤੋੜਦੀ ਹੈ, ਪੁਰਾਣਾ ਰੂਟ ਇੱਕ ਦਿਸ਼ਾ ਤੋੜਦਾ ਹੈ, ਗੁੰਮ push ਕਲਾਇੰਟ ਤੋਂ prefix ਲੁਕਾਉਂਦੀ ਹੈ, ਅਤੇ ਗਲਤ iroute prefix ਨੂੰ ਗਲਤ peer ਕੋਲ ਭੇਜਦੀ ਹੈ। ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਜੋ subnet ਸ਼ਾਮਲ ਕਰੇਗਾ ਚਾਰੇ ਇੱਕ ਥਾਂ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਇਹ ਨੋਟ ਸ਼ਾਮ ਤੋਂ ਸਸਤਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ