Miksi GCP-virtuaalikoneesi ei voi vastata OpenVPN:n IPv6-pooliin

IPv6 VPN -asiakkaasi tavoittaa työkuorman, työkuorma vastaa tunneliin, eikä vastaus koskaan saavu. Ensimmäinen vaisto on syyttää palomuuria tai tunnelia, eikä kumpikaan yleensä ole syyllinen. Osoite, jonka OpenVPN jakaa, on sisäinen verkko, joka on olemassa vain tunnelin sisällä; Google Cloudilla ei ole aavistustakaan, että fd42:90::/64:n pitäisi olla yhden tietyn virtuaalikoneen takana, ennen kuin kerrot sille.

Kahden erillisen järjestelmän on opittava tämä tosiasia, ja vain toinen niistä on OpenVPN. VPC tarvitsee reitin ennen kuin se voi lähettää mitään takaisin, ja virtuaalikoneelle on annettava lupa välittää saapuva liikenne. Jos jompikumpi puolisko menee pieleen, oire näyttää samalta.

Pooli on sisäinen verkko, ei aliverkko

OpenVPN voi jakaa IPv6-osoitteita valitsemastasi vaihteluvälistä, ja tämä vaihteluväli on fiktio, josta tunnelin kaksi päätä sopivat. Se ei ole Google Cloudin aliverkko, se ei näy VPC:n aliverkkoluettelossa, eikä virtuaalikoneen verkkoliitäntä saa näitä osoitteita. Siksi asiakkaalle vastaava työkuorma lähettää paketin osoitteeseen, jota verkko pitää reitittämättömänä.

Pidä pooli poissa jokaisesta vaihteluvälistä, jota VPC jo käyttää. Pidä se poissa myös muiden tunneliesi takana olevista vaihteluväleistä. Päällekkäisyys muuttaa puhtaan reititysvirheen ajoittaiseksi, joka näkyy vain kuormituksen alla.

Yksilöllinen paikallinen osoitteistus, kuten fd42:90::/64, on järkevä valinta tälle sisäiselle verkolle. Etuliite muistuttaa myös siitä, että suunnittelu on luonteeltaan yksityinen. Mikään ULA-poolissa ei tee siitä laillista lähdettä julkisessa internetissä.

Anna VPC:lle kohde ja seuraava hyppy

Vastaus tarvitsee VPC-reitin, jonka kohde on pooli ja jonka seuraava hyppy on VPN-virtuaalikone. Nykyinen staattisten reittien dokumentaatio kattaa IPv6-kohdevaihteluvälit ja luettelee, mitkä seuraavan hypyn tyypit kelpaavat, joten varmista topologiaasi tuettu muoto sen sijaan että kopioisit vanhemman IPv4-esimerkin.

Seuraavan hypyn osoitteen on oltava sellainen, joka on todella osoitettu instanssin pilviliitännälle. Virtuaalikoneen sisäinen tunneliosoite ei ole tuo osoite. Sen käyttäminen silti tuottaa reitin, joka asentuu puhtaasti eikä koskaan osu pakettiin. Lue liitäntäluettelo ennen reitin kirjoittamista.

Reitin prioriteetti on yhtä tärkeä kuin itse merkintä. Aliverkkoreitit ovat täsmällisempiä kuin lisäämäsi mukautetut reitit, joten olemassa olevasta aliverkkovaihteluvälistä leikattu pooli häviää aliverkkoreitille riippumatta siitä, miten mukautettu reitti on kirjoitettu. Valitse erillinen pooli ja varmista sitten, että reitti näyttää instanssin seuraavana hyppynä ja oikean kohde-etuliitteen:

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

Edelleenlähetys on otettava käyttöön kahdesti

Reitti toimittaa paketin instanssille. Se ei tee instanssista halukasta välittämään jotain, jota ei ole osoitettu sille, ja tämä lupa on olemassa kahdella tasolla.

Pilvipuoli tarvitsee instanssin edelleenlähetyskyvyn käyttöön; se on asetus, joka sallii virtuaalikoneen vastaanottaa liikennettä osoitteille, joita se ei omista, ja välittää sen. Vieraspuoli tarvitsee oman IPv6-edelleenlähetyksensä, koska ydin tekee erillisen päätöksen paketin saavuttua. Molempien on oltava päällä ennen kuin yksikään vastaus ylittää tunnelin.

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

Sitten palomuurisääntöjen on sallittava sisäinen lähdevaihteluväli molempiin suuntiin. Google Cloud arvioi puretun paketin, joten sääntö, joka kattaa vain VPC:n aliverkon, pudottaa poolin liikenteen sen jälkeen, kun tunneli on jo onnistunut. Lisää pooli lähdevaihteluväliksi saapuvan liikenteen sääntöön ja varmista, ettei mikään mukautettu lähtevän liikenteen käytäntö estä vastausta. Implisiittinen sallintasääntö kattaa oletustapauksen, käsin kirjoitettu lähtevän liikenteen sääntö ei.

Kerro OpenVPN:lle, kuka omistaa mitä

OpenVPN välittää asiakkaalle, kun se tietää kyseisen asiakkaan omistavan kohteen. Poolin asiakasosoitteita hoitaa palvelindirektiivi, joka määrittelee poolin, mutta asiakkaan takana oleva aliverkko on eri järjestely ja vaatii nimenomaisen omistajuusmerkinnän kyseiselle asiakkaalle.

Näiden kahden sekoittaminen tuottaa tunnelin, jossa pingit palvelimelle toimivat eikä mikään sen takana toimi. Päätä, kumpaa tapausta rakennat, ja kirjoita sitten vastaava merkintä sen sijaan, että lisäisit toisen push-rivin ja toivoisit.

Pidä internet-liikenne poissa tästä suunnittelusta

Yksityinen pääsy ja internetpääsy ovat erillisiä suunnitelmia. ULA-pooli voi tavoittaa VPC-työkuormat tunnelin kautta, kun reititys ja edelleenlähetys ovat sopusoinnussa, eikä samalla poolilla ole reittiä julkiseen internetiin VPC:n kautta, koska pilviyhdyskäytävä ei hyväksy mielivaltaista tunnelilähdettä omakseen.

Jos asiakkaat tarvitsevat myös internet-liikennettä, suunnittele sille tuettu osoitteistus- ja reititysratkaisu, pidä se yksityisestä poolista riippumattomana ja testaa kaksi polkua erikseen. Yksi toimiva polku ei kerro toisesta mitään, ja suunnittelu, joka sekoittaa ne, epäonnistuu tavalla, joka näyttää rikkinäiseltä tunnelilta.