OpenVPN sur GCE: aldonu alias-IP antaŭ ol pushi vojojn

Pushita vojo ne igas la VM next hop. Aldonu la alias-IP-gamuton, agordu ĝin kun la servila pool kaj kreu la returnan vojon en VPC antaŭ ol testi klientojn.

Kliento vokas la servilon OpenVPN sur Compute Engine VM, la statfenestro diras konektita, kaj ping al gastiganto ene de VPC ankoraŭ alvenas nenie. La instinkto estas aldoni ankoraŭ unu push-linion, kaj tio neniam riparas ĝin. Compute Engine decidas kien la pakaĵoj iras laŭ sia propra voja tabelo kaj laŭ la adresoj kiujn VM-interfaco efektive tenas, do tunnel-pool kiun la VM ne posedas estas pool al kiu neniu transdonas.

Sekvu la malsukcesantan pakaĵon anstataŭ la agordan dosieron, kaj la mankantaj partoj aperos laŭ ordo.

Komencu ĉe la mortanta pakaĵo

La SYN forlasas la klienton, eniras la tunnelon kaj atingas la VM kiel ĉirkaŭpakaĵo por celo ene de VPC. OpenVPN malĉirkaŭpakas ĝin kaj provas plusendi ĝin tra eth0, kie la fabric starigas unu demandon antaŭ ĉio alia: ĉu ĉi tiu instanco posedas la celadreson. Tunnel-pool tranĉita el la subnet de iu alia malsukcesas ĉe tiu demando, kaj la pakaĵo estas forĵetita antaŭ ol iu ajn vojo aŭ firewall-regulo estas konsultita.

Do la direkto de kliento al VPC havas du apartajn postulojn, kaj neniu el ili estas push-direktivo. La VM bezonas alias-gamuton kiu kovras la tunnel-pool, kaj ĝuste tio igas ĝin laŭleĝa posedanto de tiuj adresoj. La VPC bezonas vojon kiu nomas la VM kiel next hop por ĉiu protektita prefikso. Se mankas unu, la pakaĵo mortas aliloke, dum la kliento vidas la saman silenton.

Legu la fiaskon en tiu ordo, ĉar de la klienta flanko la du kondiĉoj aspektas identaj. Tunelo kiu raportas konektita dum nenio respondas estas la signo de topologia problemo, ne de malbona ĉifro.

Ĉu la instanco posedas la tunnel-pool

Donu al la VM duan gamuton ene de ĝia propra subnet, poste lasu OpenVPN disdoni adresojn ĝuste el tiu gamuto. Ĉe instanco kies ĉefa adreso estas 10.156.0.10/20, alias /28 tenas la pool aparte de la adresoj kiujn aliaj instancoj jam havas:

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

Tiam la server-direktivo devas priskribi la saman blokon. Ĝia unua adreso fariĝas la gateway de la tunelo, kaj la ceteraj adresoj estas disdonataj al klientoj. Ĉi tie du nombroj priskribas unu blokon, reton kaj netmask, kaj tio estas la pool-sintakso kiun OpenVPN ankoraŭ atendas.

server 10.156.1.0 255.255.255.240

Konfirmu ke la adreso vere alvenis sur la interfacon kaj ne nur en la OpenVPN-agordo. La fabric plusendas tion kion la NIC raportas, ne tion kion la daemon kredas. Unu komando decidas tion:

ip -4 addr show dev eth0

Dua adreso kiu neniam atingas eth0, aŭ pool kiu interkovras alian subnet, montriĝas poste kiel intermita perdo anstataŭ kiel starta eraro. La daemon startas, klientoj konektiĝas, kaj nur kelkaj celoj kondutas malĝuste. Tenu la alias-gamuton malgranda por ke la pool estu facile rekonebla en voja tabelo. Neniam tranĉu ĝin el subnet kiun alia instanco jam uzas.

Donu al la returna trafiko next hop

Respondo de gastiganto en VPC estas adresita al klienta adreso en la tunnel-pool, kiu apartenas al neniu subnet kiun la VPC konas. Sen vojo por tiu pool, la respondo haltas ĉe la unua hop sen trafo, kaj la peto povis tute bone sukcesi ĉe la malproksima fino.

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

La sama vojo necesas por ĉiu prefikso kiu situas malantaŭ kliento anstataŭ ene de la VPC. Tiuj prefiksoj bezonas ankaŭ iroute-enskribon en la ccd-dosiero de tiu kliento. Tiu enskribo estas librotenado ĉe la servila flanko: ĝi diras al la servilo kiu kliento posedas la prefikson, kaj ĝi instalas nenion sur la kliento mem.

Konservu la push-liston por la klienta flanko de la konversacio, ĉar ĝi nur aldonas vojojn al la maŝino kiu konektiĝas. Push-linio por VPC-subnet kaj VPC-vojo reen al la pool estas du duonoj de la sama vojo, kaj ĉiu duono sola produktas tunnelon kiu portas petojn sed ne respondojn.

Firewall-oj, plusendo kaj la hopoj inter ili

La VPC-firewallo taksas la malĉirkaŭpakaĵon, do ingress-regulo devas permesi la tunnel-pool kaj ĉiun site-prefikson kiu atingas la VM tiun vojon. Default-deny sinteno malsukcesas silente ĉi tie: la pakaĵo estas forĵetita post malĉirkaŭpakado, kaj la OpenVPN-protokolo montras sanan session.

Sur ĉiu Linux-gastiganto kiu plusendas anstataŭ fini, kontrolu ĉu net.ipv4.ip_forward estas ŝaltita. La posedregulo validas ankaŭ tie: maŝino kiu plusendas por subnet kiun ĝi ne havas forĵetas la pakaĵon same kiel la VM farus. Legu la valoron antaŭ ol kulpi la tunnelon.

Kiam ĝuste unu prefikso malsukcesas

Parta fiasko estas la plej facile legebla kazo, ĉar ĉio alia sur la vojo jam estas pruvita. Komencu per la voja listo kaj legu la celgamuton kaj next hop de la enskribo kiu devus kovri la prefikson, poste legu la priskribon de la instanco kaj komparu ĝian alias-gamuton kun la pool kiun la servilo disdonas.

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

Mankanta vojo montriĝas kiel neniu next hop por la prefikso, dum mankanta alias montriĝas kiel pakaĵo forĵetita ĉe la interfaco; de la kliento la du aspektas similaj kaj en tiuj du eligoj ili estas tute malsamaj. Se ambaŭ ĉeestas, la restanta suspektato estas la ccd-iroute de la kliento kiu postulas la prefikson.

Skribu la kvar valorojn apud la tunelo: alias-gamuto, servila pool, pushitaj prefiksoj, VPC-vojoj. Malnova alias rompas ĉiun pool-adreson, malnova vojo rompas unu direkton, mankanta push kaŝas la prefikson de la kliento, kaj malĝusta iroute sendas la prefikson al la malĝusta peer. La sekva persono kiu aldonos subnet bezonas ĉiujn kvar en unu loko, kaj la noto estas pli malmultekosta ol la vespero.

Rilataj artikoloj