Bakit hindi makakasagot ang iyong GCP VM sa OpenVPN IPv6 pool

Naabot ng iyong IPv6 VPN client ang workload, sumasagot ang workload pabalik sa tunnel, at hindi kailanman dumarating ang sagot. Ang unang instinct ay sisihin ang firewall o ang tunnel, at kadalasan wala sa dalawa ang may kasalanan. Ang address na ibinibigay ng OpenVPN ay isang panloob na network na umiiral lamang sa loob ng tunnel; walang kaalaman ang Google Cloud na ang fd42:90::/64 ay dapat nasa likod ng isang partikular na VM hanggang sabihin mo ito.

Dalawang magkahiwalay na sistema ang dapat matuto ng katotohanang ito, at isa lamang sa kanila ang OpenVPN. Kailangan ng VPC ng ruta bago ito makapagpadala ng anuman pabalik, at ang VM ay dapat pahintulutang i-forward ang dumarating. Magkamali sa alinman sa dalawang kalahati at magmumukhang pareho ang sintomas.

Ang pool ay panloob na network, hindi subnet

Maaaring magbigay ang OpenVPN ng mga IPv6 address mula sa saklaw na pipiliin mo, at ang saklaw na iyon ay isang kathang-isip na pinagkasunduan ng dalawang dulo ng tunnel. Hindi ito Google Cloud subnet, hindi ito lumilitaw sa listahan ng subnet ng VPC, at hindi nakukuha ng network interface ng VM ang mga address na iyon. Kaya nagpapadala ang workload na sumasagot sa client ng packet patungo sa address na itinuturing ng network na hindi maruruta.

Panatilihin ang pool sa labas ng bawat saklaw na ginagamit na ng VPC. Panatilihin din ito sa labas ng mga saklaw sa likod ng iyong iba pang tunnel. Ang overlap ay ginagawang pana-panahon ang malinis na pagkabigo sa routing, na lumilitaw lamang sa ilalim ng load.

Ang natatanging lokal na addressing tulad ng fd42:90::/64 ay makatwirang pagpipilian para sa panloob na network na ito. Ang prefix ay nagpapaalala rin na ang disenyo ay pribado sa simula. Walang anuman sa isang ULA pool ang gumagawa nitong lehitimong pinagmulan sa pampublikong internet.

Bigyan ang VPC ng destinasyon at susunod na hop

Kailangan ng sagot ang isang VPC route na ang destinasyon ay ang pool at ang susunod na hop ay ang VM ng VPN. Sinasaklaw ng kasalukuyang dokumentasyon ng static na ruta ang mga saklaw ng destinasyon ng IPv6 at inililista kung aling mga uri ng susunod na hop ang karapat-dapat, kaya i-verify ang sinusuportahang anyo para sa iyong topolohiya sa halip na kopyahin ang lumang halimbawa ng IPv4.

Ang address ng susunod na hop ay dapat isang aktwal na itinalaga sa cloud interface ng instance. Ang panloob na tunnel address ng VM ay hindi ang address na iyon. Ang paggamit nito gayunpaman ay gumagawa ng rutang malinis na naka-install at hindi kailanman tumutugma sa anumang packet. Basahin ang listahan ng interface bago isulat ang ruta.

Ang precedence ng ruta ay kasinghalaga ng entry mismo. Ang mga subnet route ay mas partikular kaysa sa mga custom na rutang idinagdag mo, kaya ang pool na hinango mula sa umiiral na saklaw ng subnet ay matatalo ng subnet route, gaano man isinulat ang custom na ruta. Pumili ng hiwalay na pool, pagkatapos ay kumpirmahin na ipinapakita ng ruta ang instance bilang susunod na hop at ang tamang prefix ng destinasyon:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

Dalawang beses dapat paganahin ang forwarding

Inihahatid ng ruta ang packet sa instance. Hindi nito ginagawang handa ang instance na i-forward ang isang bagay na hindi nakadirekta rito, at ang pahintulot na iyon ay umiiral sa dalawang antas.

Kailangan ng cloud side na paganahin ang kakayahan sa forwarding ng instance; ito ang setting na nagpapahintulot sa VM na tumanggap ng traffic para sa mga address na hindi pag-aari nito at ipasa ito. Kailangan ng guest side ang sarili nitong IPv6 forwarding, dahil gumagawa ang kernel ng hiwalay na desisyon pagkatapos dumating ang packet. Dapat nakabukas ang dalawa bago pa makatawid ang isang sagot sa tunnel.

sysctl -w net.ipv6.conf.all.forwarding=1

Pagkatapos, dapat payagan ng mga patakaran ng firewall ang panloob na saklaw ng pinagmulan sa dalawang direksyon. Sinusuri ng Google Cloud ang decapsulated na packet, kaya ang patakarang sumasaklaw lamang sa subnet ng VPC ay nagtatapon ng traffic ng pool pagkatapos ng matagumpay na tunnel. Idagdag ang pool bilang saklaw ng pinagmulan sa ingress rule, at tiyaking walang custom na egress policy ang humaharang sa sagot. Saklaw ng implied allow rule ang default na kaso, ang manu-manong isinulat na egress rule ay hindi.

Sabihin sa OpenVPN kung sino ang may-ari ng ano

Nagpapadala ang OpenVPN sa isang client kapag alam nitong pag-aari ng client na iyon ang destinasyon. Ang mga address ng client mula sa pool ay pinangangasiwaan ng server directive na tumutukoy sa pool, ngunit ang subnet sa likod ng client ay ibang kaayusan at nangangailangan ng tahasang entry ng pagmamay-ari para sa client na iyon.

Ang paghahalo ng dalawa ay gumagawa ng tunnel kung saan gumagana ang ping sa server at wala sa likod nito. Magpasya kung aling kaso ang itinatayo mo, pagkatapos ay isulat ang tugmang entry sa halip na magdagdag ng pangalawang push line at umasa.

Ihiwalay ang internet egress sa disenyong ito

Ang pribadong access at internet access ay magkahiwalay na plano. Maaaring maabot ng ULA pool ang mga workload ng VPC sa tunnel kapag nagkasundo ang routing at forwarding, at ang parehong pool ay walang daan patungo sa pampublikong internet sa pamamagitan ng VPC, dahil hindi tatanggapin ng cloud gateway ang isang arbitrary na pinagmulan ng tunnel bilang sarili nito.

Kung kailangan din ng mga client ang internet egress, magplano ng sinusuportahang disenyo ng addressing at routing para doon, panatilihin itong independiyente sa pribadong pool, at subukan ang dalawang landas nang hiwalay. Ang isang gumaganang landas ay walang sinasabi tungkol sa isa pa, at ang disenyong naghahalo sa kanila ay nabibigo sa paraang mukhang sirang tunnel.