OpenVPN sa GCE: magdagdag ng alias IP bago mag-push ng mga ruta

Kumokonekta ang kliyente sa server na OpenVPN sa isang VM ng Compute Engine, sinasabi ng status window na konektado, ngunit ang ping sa isang host sa loob ng VPC ay hindi pa rin umaabot kahit saan. Ang likas na reaksyon ay magdagdag ng isa pang push line, at hindi iyon kailanman nag-aayos. Ang Compute Engine ang nagpapasya kung saan pupunta ang mga packet batay sa sarili nitong talahanayan ng ruta at sa mga address na talagang hawak ng interface ng VM, kaya ang tunnel pool na hindi pag-aari ng VM ay pool na walang naghahatid.

Sundan ang packet na nabigo sa halip na ang configuration file, at lalabas ang mga kulang na bahagi sa tamang pagkakasunod-sunod.

Simulan sa packet na namamatay

Lumabas ang SYN mula sa kliyente, pumasok sa tunnel at umabot sa VM bilang naka-encapsulate na packet patungo sa destinasyon sa loob ng VPC. Dinidecapsulate ito ng OpenVPN at sinusubukang ipasa sa eth0, kung saan nagtatanong muna ang fabric ng isang bagay bago ang lahat: pag-aari ba ng instance na ito ang destinasyong address. Ang tunnel pool na hiwa mula sa subnet ng iba ay bigo sa tanong na iyon, at itinatapon ang packet bago tingnan ang anumang ruta o firewall rule.

Kaya ang direksyon mula kliyente patungo sa VPC ay may dalawang magkahiwalay na pangangailangan, at wala sa kanila ang push directive. Kailangan ng VM ng alias range na sumasaklaw sa tunnel pool, at iyon ang gumagawa ritong lehitimong may-ari ng mga address na iyon. Kailangan ng VPC ng rutang nagngangalan sa VM bilang next hop para sa bawat protektadong prefix. Kapag kulang ang isa, namamatay ang packet sa ibang lugar, habang nakikita ng kliyente ang parehong katahimikan.

Basahin ang pagkabigo sa ganoong pagkakasunod-sunod, dahil mula sa panig ng kliyente ay magkapareho ang dalawang kondisyon. Ang tunnel na nagsasabing konektado habang walang sumasagot ay tanda ng problema sa topolohiya, hindi ng masamang cipher.

Pag-aari ba ng instance ang tunnel pool

Bigyan ang VM ng pangalawang hanay sa loob ng sarili nitong subnet, pagkatapos ay hayaang mamahagi ang OpenVPN ng mga address mula mismo sa hanay na iyon. Sa isang instance na ang pangunahing address ay 10.156.0.10/20, ang /28 alias ay naghihiwalay sa pool mula sa mga address na hawak na ng ibang instance:

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

Kailangan ng server directive na ilarawan ang parehong bloke. Ang unang address nito ang nagiging gateway ng tunnel, at ang natitirang mga address ay ibinabahagi sa mga kliyente. Dalawang numero ang naglalarawan ng isang bloke dito, isang network at isang netmask, at iyon ang syntax ng pool na inaasahan pa rin ng OpenVPN.

server 10.156.1.0 255.255.255.240

Tiyakin na talagang nakarating ang address sa interface at hindi lamang sa configuration ng OpenVPN. Ipinapasa ng fabric ang iniuulat ng NIC, hindi ang pinaniniwalaan ng daemon. Isang utos ang magpapasya:

ip -4 addr show dev eth0

Ang pangalawang address na hindi kailanman umabot sa eth0, o pool na nagsasapawan sa ibang subnet, ay lumilitaw mamaya bilang paminsan-minsang pagkawala at hindi bilang error sa pagsisimula. Nagsisimula ang daemon, kumokonekta ang mga kliyente, at ilang destinasyon lang ang mali ang kilos. Panatilihing maliit ang alias range para madaling makilala ang pool sa talahanayan ng ruta. Huwag kailanman hiwain ito mula sa subnet na ginagamit na ng ibang instance.

Bigyan ng next hop ang pabalik na trapiko

Ang sagot mula sa host sa VPC ay nakaindirekta sa address ng kliyente sa tunnel pool, na hindi kabilang sa alinmang subnet na kilala ng VPC. Kung walang ruta para sa pool na iyon, hihinto ang sagot sa unang hop na walang tugma, at maaaring nagtagumpay na ang kahilingan sa kabilang dulo.

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

Kailangan din ng parehong ruta para sa anumang prefix na nasa likod ng kliyente at hindi sa loob ng VPC. Kailangan din ng mga prefix na iyon ng iroute entry sa ccd file ng kliyenteng iyon. Ang entry na iyon ay accounting sa panig ng server: sinasabi nito sa server kung aling kliyente ang may-ari ng prefix, at wala itong iniinstall sa kliyente mismo.

Itabi ang push list para sa panig ng kliyente ng usapan, dahil nagdadagdag lang ito ng ruta sa makinang kumokonekta. Ang push line para sa subnet ng VPC at ang rutang pabalik sa pool ay dalawang kalahati ng parehong landas, at ang alinmang kalahati lang ay gumagawa ng tunnel na nagdadala ng kahilingan ngunit walang sagot.

Firewall, forwarding at ang mga hop sa gitna

Sinusuri ng firewall ng VPC ang na-decapsulate na packet, kaya dapat payagan ng ingress rule ang tunnel pool at anumang site prefix na umaabot sa VM sa ganoong paraan. Ang default-deny na saloobin ay tahimik na nabibigo dito: itinatapon ang packet pagkatapos ng decapsulation, at ang OpenVPN log ay nagpapakita ng malusog na session.

Sa anumang Linux host na nagpapasa at hindi nagtatapos, tiyakin na naka-enable ang net.ipv4.ip_forward. Naaangkop din doon ang tuntunin ng pagmamay-ari: ang makina na nagpapasa para sa subnet na hindi niya hawak ay nagtatapon ng packet tulad ng gagawin ng VM. Basahin ang halaga bago sisihin ang tunnel.

Kapag eksaktong isang prefix ang nabigo

Ang bahagyang pagkabigo ang pinakamadaling basahin, dahil napatunayan na ang lahat ng iba sa landas. Magsimula sa listahan ng ruta at basahin ang destinasyong hanay at next hop ng entry na dapat sumasaklaw sa prefix, pagkatapos basahin ang paglalarawan ng instance at ihambing ang alias range nito sa pool na ibinabahagi ng server.

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

Ang kulang na ruta ay nagpapakita bilang walang next hop para sa prefix, habang ang kulang na alias ay nagpapakita bilang packet na itinapon sa interface; mula sa kliyente ay magkatulad ang dalawa at sa dalawang output na iyon ay lubos na magkaiba. Kung mayroon ang dalawa, ang natitirang suspetsa ay ang iroute sa ccd ng kliyenteng nag-aangkin ng prefix.

Isulat ang apat na halaga sa tabi ng tunnel: alias range, pool ng server, mga na-push na prefix, mga ruta ng VPC. Ang lumang alias ay sumisira sa bawat address ng pool, ang lumang ruta ay sumisira sa isang direksyon, ang kulang na push ay nagtatago ng prefix sa kliyente, at ang maling iroute ay nagpapadala ng prefix sa maling peer. Ang susunod na taong magdadagdag ng subnet ay kailangan ang apat sa isang lugar, at mas mura ang tala kaysa sa gabi.