Miért nem tud válaszolni a GCP virtuális gép az OpenVPN IPv6-pooljára

Az IPv6 VPN-ügyfél eléri a munkaterhelést, a munkaterhelés válaszol a bújtatásba, a válasz mégsem érkezik meg. Az első ösztön a tűzfal vagy az alagút hibáztatása, és általában egyik sem hibás. Az OpenVPN által kiosztott cím olyan belső hálózat, amely csak az alagúton belül létezik; a Google Cloudnak fogalma sincs arról, hogy a fd42:90::/64-nek egy adott VM mögött kell lennie, amíg meg nem mondja neki.

Két különálló rendszernek kell megtanulnia ezt a tényt, és csak az egyikük az OpenVPN. A VPC-nek útvonalra van szüksége, mielőtt bármit visszaküldhetne, és a VM-nek engedélyezni kell a beérkező forgalom továbbítását. Ha bármelyik felében téved, a tünet ugyanúgy néz ki.

A pool belső hálózat, nem alhálózat

Az OpenVPN IPv6-címeket oszthat ki az Ön által választott tartományból, és ez a tartomány fikció, amelyben az alagút két vége megegyezik. Nem Google Cloud alhálózat, nem jelenik meg a VPC alhálózati listájában, és a VM hálózati interfésze nem kapja meg ezeket a címeket. Ezért az ügyfélnek válaszoló munkaterhelés olyan címre küld csomagot, amelyet a hálózat nem irányíthatónak tekint.

Tartsa a poolt minden olyan tartományon kívül, amelyet a VPC már használ. Tartsa a többi alagútja mögötti tartományokon kívül is. Az átfedés a tiszta útválasztási hibát időszakos hibává változtatja, amely csak terhelés alatt jelenik meg.

Az olyan egyedi helyi címzés, mint a fd42:90::/64, ésszerű választás ehhez a belső hálózathoz. Az előtag arra is emlékeztet, hogy a terv természeténél fogva privát. Semmi sem teszi a ULA-poolt jogszerű forrássá a nyilvános interneten.

Adjon a VPC-nek célt és következő ugrást

A válasznak olyan VPC-útvonalra van szüksége, amelynek célja a pool, következő ugrása pedig a VPN VM. A jelenlegi statikus útvonal dokumentáció lefedi az IPv6 célú tartományokat, és felsorolja, mely következő ugrás típusok elfogadhatók, ezért ellenőrizze a topológiájához támogatott formát ahelyett, hogy egy régebbi IPv4-példát másolna.

A következő ugrás címének olyannak kell lennie, amely ténylegesen az instance felhőinterfészéhez van rendelve. A VM belső alagútcíme nem ez a cím. Ha mégis használja, olyan útvonal jön létre, amely tisztán települ és soha nem illeszkedik egyetlen csomaghoz sem. Olvassa el az interfészek listáját, mielőtt megírja az útvonalat.

Az útvonal elsőbbsége ugyanolyan fontos, mint maga a bejegyzés. Az alhálózati útvonalak konkrétabbak, mint a hozzáadott egyéni útvonalak, ezért a meglévő alhálózati tartományból kivágott pool veszít az alhálózati útvonallal szemben, függetlenül attól, hogyan íródott az egyéni útvonal. Válasszon külön poolt, majd erősítse meg, hogy az útvonal az instance-t mutatja következő ugrásként és a helyes cél-előtagot:

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

A továbbítást kétszer kell engedélyezni

Az útvonal eljuttatja a csomagot az instance-hez. Nem teszi az instance-t hajlandóvá arra, hogy továbbítson valamit, ami nem neki van címezve, és ez az engedély két szinten létezik.

A felhőoldalnak engedélyezett instance-továbbítási képességre van szüksége; ez az a beállítás, amely lehetővé teszi, hogy a VM olyan címek forgalmát fogadja és adja tovább, amelyek nem a sajátjai. A vendégoldalnak saját IPv6-továbbításra van szüksége, mert a kernel a csomag megérkezése után külön döntést hoz. Mindkettőnek be kell lennie kapcsolva, mielőtt egyetlen válasz átkel az alagúton.

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

Ezután a tűzfalszabályoknak mindkét irányban át kell engedniük a belső forrástartományt. A Google Cloud a feloldott csomagot értékeli, ezért a csak a VPC-alhálózatot lefedő szabály eldobja a pool forgalmát, miután az alagút már sikeres volt. Adja hozzá a poolt forrástartományként a bejövő szabályhoz, és ellenőrizze, hogy egyetlen egyéni kimenő házirend sem blokkolja a választ. Az implicit engedélyező szabály lefedi az alapértelmezett esetet, a kézzel írt kimenő szabály nem.

Mondja meg az OpenVPN-nek, ki mit birtokol

Az OpenVPN továbbít az ügyfélnek, ha tudja, hogy az az ügyfél birtokolja a célt. A poolból származó ügyfélcímeket a poolt meghatározó kiszolgáló direktíva kezeli, de az ügyfél mögötti alhálózat más elrendezés, és kifejezett tulajdonosi bejegyzést igényel ahhoz az ügyfélhez.

A kettő összekeverése olyan alagutat eredményez, amelyben a kiszolgáló felé irányuló pingek működnek, és semmi sem mögötte. Döntse el, melyik esetet építi, majd írja meg a megfelelő bejegyzést ahelyett, hogy hozzáadna egy második push-sort, és reménykedne.

Tartsa az internetes kimenetet ezen a terven kívül

A privát hozzáférés és az internetes hozzáférés külön tervek. A ULA-pool elérheti a VPC munkaterheléseit az alagúton keresztül, ha az útválasztás és a továbbítás megegyezik, és ugyanennek a poolnak nincs útja a nyilvános internetre a VPC-n keresztül, mert a felhőátjáró nem fogad el tetszőleges alagútforrást sajátjaként.

Ha az ügyfeleknek internetes kimenetre is szükségük van, tervezzen ehhez támogatott címzési és útválasztási megoldást, tartsa függetlenül a privát pooltól, és tesztelje a két útvonalat külön. Egy működő útvonal semmit sem mond a másikról, és a kettőt összemosó terv olyan módon hibázik, amely törött alagútnak látszik.