Miks teie GCP VM ei saa OpenVPN IPv6 poolele vastata

Teie IPv6 VPN klient jõuab töökoormuseni, töökoormus vastab tunnelisse ja vastus ei jõua kunagi kohale. Esimene instinkt on süüdistada tulemüüri või tunnelit ning tavaliselt ei ole kumbki süüdi. Aadress, mille annab OpenVPN, on sisemine võrk, mis eksisteerib ainult tunneli sees; Google Cloudil pole aimugi, et fd42:90::/64 peaks asuma ühe kindla VMi taga, kuni te seda talle ütlete.

Kaks eraldi süsteemi peavad selle fakti selgeks õppima ja ainult üks neist on OpenVPN. VPC vajab marsruuti enne, kui saab midagi tagasi saata, ja VMil peab olema luba edastada seda, mis saabub. Eksige kummalgi poolel ja sümptom näeb välja identne.

Pool on sisemine võrk, mitte alamvõrk

OpenVPN saab jagada IPv6 aadresse teie valitud vahemikust ja see vahemik on fiktsioon, mille suhtes tunneli kaks otspunkti kokku lepivad. See ei ole Google Cloudi alamvõrk, see ei ilmu VPC alamvõrkude loendis ja VMi võrguliides ei omanda neid aadresse. Seetõttu saadab kliendile vastav töökoormus paketi aadressile, mida võrk peab mitte-marsruuditavaks.

Hoidke pool väljaspool iga vahemikku, mida VPC juba kasutab. Hoidke see väljaspool ka teie teiste tunnelite taga olevaid vahemikke. Kattumine muudab puhta marsruutimisvea aeg-ajalt esinevaks, mis ilmneb ainult koormuse all.

Unikaalne lokaalne adresseerimine nagu fd42:90::/64 on selle sisemise võrgu jaoks mõistlik valik. Prefiks tuletab ka meelde, et disain on oma olemuselt privaatne. Miski ULA poole juures ei tee sellest avalikus internetis seaduslikku allikat.

Andke VPC-le sihtkoht ja järgmine hüpe

Vastus vajab VPC marsruuti, mille sihtkoht on pool ja mille järgmine hüpe on VPN VM. Praegune staatiliste marsruutide dokumentatsioon hõlmab IPv6 sihtvahemikke ja loetleb, millised järgmise hüppe tüübid on sobilikud, seega kontrollige oma topoloogia jaoks toetatud vormi, selle asemel et kopeerida vanemat IPv4 näidet.

Järgmise hüppe aadress peab olema see, mis on tegelikult määratud eksemplari pilveliidesele. VMi sisemine tunneli aadress ei ole see aadress. Selle kasutamine tekitab marsruudi, mis paigaldub puhtalt ja ei vasta kunagi ühelegi paketile. Lugege liideste loendit enne marsruudi kirjutamist.

Marsruudi prioriteet on sama oluline kui kirje ise. Alamvõrgu marsruudid on spetsiifilisemad kui teie lisatud kohandatud marsruudid, seega olemasolevast alamvõrgu vahemikust lõigatud pool kaotab alamvõrgu marsruudile, olenemata sellest, kuidas kohandatud marsruut on kirjutatud. Valige eraldi pool ja kinnitage seejärel, et marsruut näitab eksemplari järgmise hüppena ja õiget sihtprefiksi:

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

Edastamine tuleb lubada kaks korda

Marsruut toimetab paketi eksemplarile. See ei tee eksemplari nõus edastama midagi, mis ei ole talle adresseeritud, ja see luba eksisteerib kahel tasandil.

Pilvepool vajab eksemplari edastamisvõimekust lubatud; see on säte, mis lubab VMil vastu võtta liiklust aadressidele, mida ta ei oma, ja selle edasi anda. Külalisepool vajab oma IPv6 edastamist, sest tuum teeb eraldi otsuse pärast paketi saabumist. Mõlemad peavad olema sisse lülitatud, enne kui üksainus vastus tunnelit läbib.

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

Seejärel peavad tulemüürireeglid lubama sisemist lähtevahemikku mõlemas suunas. Google Cloud hindab dekapsuleeritud paketti, seega ainult VPC alamvõrku kattev reegel viskab poole liikluse kõrvale pärast seda, kui tunnel on juba õnnestunud. Lisage pool sissetuleva reegli lähtevahemikku ja kontrollige, et ükski kohandatud väljundpoliitika ei blokeeri vastust. Kaudne lubamisreegel katab vaikejuhtumi, käsitsi kirjutatud väljundreegel mitte.

Öelge OpenVPN-ile, kes mida omab

OpenVPN edastab kliendile, kui teab, et see klient omab sihtkohta. Poole kliendiaadresse haldab serveri direktiiv, mis poole määratleb, kuid kliendi taga olev alamvõrk on teistsugune paigutus ja vajab selle kliendi jaoks selgesõnalist omandi kirjet.

Nende kahe segamine annab tunneli, kus pingid serverile töötavad ja mitte miski selle taga. Otsustage, millist juhtumit ehitate, ja kirjutage siis vastav kirje, selle asemel et lisada teine push-rida ja loota.

Hoidke interneti väljund sellest disainist väljas

Privaatne juurdepääs ja internetijuurdepääs on eraldi plaanid. ULA pool saab tunneli kaudu VPC töökoormusteni jõuda, kui marsruutimine ja edastamine on kooskõlas, ja samal poolel pole VPC kaudu avalikku internetti viivat teed, sest pilveelüüs ei võta suvalist tunneli allikat enda omaks.

Kui kliendid vajavad ka interneti väljundit, planeerige selle jaoks toetatud adresseerimis- ja marsruutimislahendus, hoidke see privaatsest poolet sõltumatu ja testige kahte teed eraldi. Üks toimiv tee ei ütle teise kohta midagi ja disain, mis need segi ajab, ebaõnnestub viisil, mis näeb välja nagu katkine tunnel.