Pam na all eich VM GCP ateb pwll IPv6 OpenVPN
Nid yw cyfeiriad y tu mewn i OpenVPN yn is-rwydwaith Google Cloud. Ychwanegwch lwybr VPC at y pwll, galluogwch anfon ymlaen a chadwch y traffig allan i'r rhyngrwyd ar wahân.
Mae eich cleient VPN IPv6 yn cyrraedd y llwyth gwaith, mae'r llwyth gwaith yn ateb i mewn i'r tiwnel, ac nid yw'r ateb byth yn cyrraedd. Y reddf yw beio'r wal dân neu'r tiwnel, ac fel arfer nid yw'r naill na'r llall ar fai. Mae cyfeiriad a roddir gan OpenVPN yn rwydwaith mewnol sy'n bodoli dim ond y tu mewn i'r tiwnel; nid oes gan Google Cloud syniad bod fd42:90::/64 i fod y tu ôl i un VM penodol nes i chi ddweud wrthi.
Mae'n rhaid i ddau system ar wahân ddysgu'r ffaith hon, a dim ond un ohonynt yw OpenVPN. Mae angen llwybr ar y VPC cyn y gall anfon unrhyw beth yn ôl, a rhaid caniatáu i'r VM anfon ymlaen yr hyn sy'n dod i mewn. Caewch y naill hanner neu'r llall yn anghywir ac mae'r symptom yn edrych yr un fath.
Rhwydwaith mewnol yw'r pwll, nid is-rwydwaith
Gall OpenVPN roi cyfeiriadau IPv6 o ystod a ddewiswch, ac mae'r ystod honno'n ffuglen y mae dau ben y tiwnel yn cytuno arni. Nid yw'n is-rwydwaith Google Cloud, nid yw'n ymddangos yn rhestr is-rwydweithiau'r VPC, ac nid yw rhyngwyneb rhwydwaith y VM yn cael y cyfeiriadau hynny. Felly mae llwyth gwaith sy'n ateb cleient yn anfon pecyn at gyfeiriad y mae'r ffabrig yn ei ystyried yn anroutadwy.
Cadwch y pwll allan o bob ystod y mae'r VPC eisoes yn ei defnyddio. Cadwch ef allan o'r ystodau y tu ôl i'ch tiwneli eraill hefyd. Mae gorgyffwrdd yn troi methiant llwybro glân yn un ysbeidiol sy'n ymddangos dim ond o dan lwyth.
Mae cyfeiriadu lleol unigryw fel fd42:90::/64 yn ddewis rhesymol ar gyfer y rhwydwaith mewnol hwn. Mae'r rhagddodiad hefyd yn atgoffa bod y dyluniad yn breifat o'i hanfod. Nid oes dim am bwll ULA yn ei wneud yn ffynhonnell gyfreithlon ar y rhyngrwyd cyhoeddus.
Rhowch gyrchfan a naid nesaf i'r VPC
Mae angen llwybr VPC ar yr ateb y mae'r pwll yn gyrchfan iddo a'r VM VPN yn naid nesaf iddo. Mae dogfennaeth llwybrau statig gyfredol yn ymdrin ag ystodau cyrchfan IPv6 ac yn rhestru pa fathau o naid nesaf sy'n gymwys, felly gwiriwch y ffurf a gefnogir ar gyfer eich topoleg yn hytrach na chopïo enghraifft IPv4 hŷn.
Rhaid i gyfeiriad naid nesaf fod yn un sydd wedi'i neilltuo mewn gwirionedd i ryngwyneb cwmwl y gwasanaeth. Nid cyfeiriad mewnol y tiwnel ar y VM yw'r cyfeiriad hwnnw. Mae ei ddefnyddio beth bynnag yn cynhyrchu llwybr sy'n gosod yn lân ac nad yw byth yn cyfateb i becyn. Darllenwch y rhestr ryngwynebau cyn i chi ysgrifennu'r llwybr.
Mae blaenoriaeth llwybr yr un mor bwysig â'r cofnod ei hun. Mae llwybrau is-rwydwaith yn fwy penodol na'r llwybrau personol a ychwanegwch, felly bydd pwll a dorrwyd allan o ystod is-rwydwaith bresennol yn colli i lwybr yr is-rwydwaith, waeth sut y mae'r llwybr personol wedi'i ysgrifennu. Dewiswch bwll ar wahân, yna cadarnhewch fod y llwybr yn dangos y gwasanaeth fel naid nesaf a'r rhagddodiad cyrchfan cywir:
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-bRhaid galluogi anfon ymlaen ddwywaith
Mae llwybr yn danfon y pecyn i'r gwasanaeth. Nid yw'n gwneud y gwasanaeth yn fodlon anfon ymlaen rywbeth nad yw wedi'i gyfeirio ato, ac mae'r caniatâd hwnnw'n bodoli ar ddau haen.
Mae angen i'r ochr cwmwl alluogi gallu anfon ymlaen y gwasanaeth; dyma'r gosodiad sy'n gadael i VM dderbyn traffig ar gyfer cyfeiriadau nad yw'n berchen arnynt a'i basio ymlaen. Mae angen i'r ochr westai ei anfon ymlaen IPv6 ei hun, oherwydd mae'r cnewyllyn yn gwneud penderfyniad ar wahân ar ôl i'r pecyn gyrraedd. Rhaid i'r ddau fod ymlaen cyn i un ateb groesi'r tiwnel.
sysctl -w net.ipv6.conf.all.forwarding=1Yna rhaid i reolau'r wal dân addef yr ystod ffynhonnell fewnol yn y ddau gyfeiriad. Mae Google Cloud yn gwerthuso'r pecyn datgapsiwleiddiedig, felly mae rheol sy'n cwmpasu is-rwydwaith y VPC yn unig yn gollwng traffig y pwll ar ôl i'r tiwnel eisoes lwyddo. Ychwanegwch y pwll fel ystod ffynhonnell yn y rheol fewnbwn a gwiriwch nad oes polisi allbwn personol yn rhwystro'r ateb. Mae'r rheol caniatâd ymhlyg yn cwmpasu'r achos diofyn, nid yw rheol allbwn a ysgrifennwyd â llaw.
Dywedwch wrth OpenVPN pwy sy'n berchen ar beth
Mae OpenVPN yn anfon ymlaen at gleient pan fydd yn gwybod bod y cleient hwnnw'n berchen ar y gyrchfan. Cyfeiriadau cleient o'r pwll yn cael eu trin gan y gyfarwyddeb gweinydd sy'n diffinio'r pwll, ond mae is-rwydwaith y tu ôl i gleient yn drefniant gwahanol ac mae angen cofnod perchnogaeth penodol ar gyfer y cleient hwnnw.
Mae cymysgu'r ddau yn cynhyrchu tiwnel lle mae pingiadau i'r gweinydd yn gweithio ac nid oes dim y tu ôl iddo. Penderfynwch pa achos rydych yn ei adeiladu, yna ysgrifennwch y cofnod cyfatebol yn hytrach nag ychwanegu ail linell push a gobeithio.
Cadwch allbwn y rhyngrwyd allan o'r dyluniad hwn
Mae mynediad preifat a mynediad i'r rhyngrwyd yn gynlluniau ar wahân. Gall pwll ULA gyrraedd llwythi gwaith VPC dros y tiwnel unwaith y bydd llwybro ac anfon ymlaen yn cytuno, ac nid oes gan yr un pwll hwnnw lwybr i'r rhyngrwyd cyhoeddus trwy'r VPC, oherwydd ni fydd y porth cwmwl yn derbyn ffynhonnell tiwnel fympwyol fel ei un ei hun.
Os oes angen allbwn rhyngrwyd ar gleientiaid hefyd, cynlluniwch ddyluniad cyfeiriadu a llwybro a gefnogir ar ei gyfer, cadwch ef yn annibynnol o'r pwll preifat, a phrofwch y ddau lwybr ar wahân. Nid yw un llwybr sy'n gweithio yn dweud unrhyw beth am y llall, ac mae dyluniad sy'n cymysgu'r ddau yn methu mewn ffordd sy'n edrych fel tiwnel wedi torri.