OpenVPN GCE:ssä: lisää alias-IP ennen kuin pushat reittejä

Asiakas soittaa Compute Engine -VM:llä olevalle OpenVPN-palvelimelle, tilan ikkuna sanoo yhdistetty, ja ping VPC:n sisällä olevaan koneeseen ei silti mene mihinkään. Vaisto sanoo, että lisätään vielä yksi push-rivi, eikä se koskaan korjaa ongelmaa. Compute Engine päättää, minne paketit menevät oman reittitaulunsa ja VM:n liitännällä tosiasiassa olevien osoitteiden perusteella, joten tunnelipooli, jota VM ei omista, on pooli, johon kukaan ei toimita.

Seuraa epäonnistuvaa pakettia konfiguraatiotiedoston sijaan, niin puuttuvat palaset ilmestyvät järjestyksessä.

Aloita kuolevasta paketista

SYN lähtee asiakkaalta, saapuu tunneliin ja tavoittaa VM:n kapseloituna pakettina VPC:n sisäiseen kohteeseen. OpenVPN purkaa kapseloinnin ja yrittää välittää sen eth0:n kautta, missä fabric kysyy ennen kaikkea muuta yhden kysymyksen: omistaako tämä instanssi kohdeosoitteen. Toisen aliverkosta leikattu tunnelipooli epäonnistuu siinä kysymyksessä, ja paketti hylätään ennen kuin yhtäkään reittiä tai palomuurisääntöä tarkastellaan.

Asiakkaasta VPC:hen -suunnalla on siis kaksi erillistä vaatimusta, eikä kumpikaan ole push-direktiivi. VM tarvitsee aliasalueen, joka kattaa tunnelipoolin, ja juuri se tekee siitä näiden osoitteiden laillisen omistajan. VPC tarvitsee reitin, joka nimeää VM:n next hopiksi jokaiselle suojatulle etuliitteelle. Jos toinen puuttuu, paketti kuolee toisessa paikassa, kun taas asiakas näkee saman hiljaisuuden.

Lue vika siinä järjestyksessä, koska asiakkaan puolelta molemmat ehdot näyttävät identtisiltä. Tunneli, joka ilmoittaa olevansa yhdistetty, kun mikään ei vastaa, on topologiaongelman eikä huonon salauksen tunnusmerkki.

Omistaako instanssi tunnelipoolin

Anna VM:lle toissijainen alue sen oman aliverkon sisällä ja anna sitten OpenVPN:n jakaa osoitteita täsmälleen siitä alueesta. Instanssilla, jonka ensisijainen osoite on 10.156.0.10/20, /28-alias pitää poolin erillään osoitteista, jotka muilla instansseilla jo on:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

server-direktiivin on silloin kuvattava sama lohko. Sen ensimmäisestä osoitteesta tulee tunnelin yhdyskäytävä, ja loput osoitteet jaetaan asiakkaille. Tässä kaksi lukua kuvaa yhtä lohkoa, verkko ja aliverkon peite, ja se on poolin syntaksi, jota OpenVPN yhä odottaa.

server 10.156.1.0 255.255.255.240

Varmista, että osoite todella päätyi liitännälle eikä vain OpenVPN:n konfiguraatioon. Fabric välittää sen, mitä NIC raportoi, ei sitä, mitä daemon uskoo. Yksi komento ratkaisee sen:

ip -4 addr show dev eth0

Toissijainen osoite, joka ei koskaan saavuta eth0:aa, tai pooli, joka menee toisen aliverkon päälle, näkyy myöhemmin ajoittaisena hävikkinä eikä käynnistysvirheenä. Daemon käynnistyy, asiakkaat yhdistävät ja vain osa kohteista käyttäytyy väärin. Pidä aliasalue pienenä, jotta pooli on helppo tunnistaa reittitaulusta. Älä koskaan leikkaa sitä aliverkosta, jota toinen instanssi jo käyttää.

Anna paluuliikenteelle next hop

VPC:n koneen vastaus on osoitettu tunnelipoolissa olevalle asiakasosoitteelle, joka ei kuulu mihinkään VPC:n tuntemaan aliverkkoon. Ilman reittiä sille poolille vastaus pysähtyy ensimmäiselle hypylle, jolla ei ole osumaa, ja pyyntö on voinut hyvinkin onnistua toisessa päässä.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

Sama reitti tarvitaan jokaiselle etuliitteelle, joka on asiakkaan takana eikä VPC:n sisällä. Ne etuliitteet tarvitsevat myös iroute-merkinnän kyseisen asiakkaan ccd-tiedostoon. Se merkintä on palvelinpuolen kirjanpitoa: se kertoo palvelimelle, mikä asiakas omistaa etuliitteen, eikä se asenna mitään asiakkaaseen itseensä.

Pidä push-lista keskustelun asiakaspuolella, koska se vain lisää reittejä yhdistyvään koneeseen. Push-rivi VPC:n aliverkolle ja VPC-reitti takaisin pooliin ovat saman polun kaksi puoliskoa, ja kumpikin puolisko yksin tuottaa tunnelin, joka kuljettaa pyyntöjä mutta ei vastauksia.

Palomuurit, välitys ja niiden väliset hypyt

VPC:n palomuuri arvioi kapseloinnin puretun paketin, joten ingress-säännön on päästettävä läpi tunnelipooli ja jokainen sivuston etuliite, joka saapuu VM:lle sitä kautta. Default-deny-asenne epäonnistuu tässä hiljaa: paketti hylätään kapseloinnin purkamisen jälkeen ja OpenVPN:n loki näyttää terveen istunnon.

Tarkista jokaisella Linux-koneella, joka välittää eikä päätepiste, että net.ipv4.ip_forward on käytössä. Omistussääntö pätee sielläkin: kone, joka välittää aliverkolle, jota sillä ei ole, hylkää paketin aivan kuten VM tekisi. Lue arvo ennen kuin syytät tunnelia.

Kun täsmälleen yksi etuliite epäonnistuu

Osittainen vika on helpoin lukea, koska kaikki muu polulla on jo todistettu. Aloita reittilistasta ja lue sen merkinnän kohdealue ja next hop, jonka pitäisi kattaa etuliite, lue sitten instanssin kuvaus ja vertaa sen aliasaluetta pooliin, jonka palvelin jakaa.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

Puuttuva reitti näkyy siten, ettei etuliitteelle ole next hopia, kun taas puuttuva alias näkyy liitännällä hylättynä pakettina; asiakkaan puolelta ne kaksi näyttävät samalta ja noissa kahdessa tulosteessa ne ovat täysin erilaisia. Jos molemmat ovat olemassa, jäljellä oleva epäilty on sen asiakkaan ccd-iroute, joka vaatii etuliitteen itselleen.

Kirjoita neljä arvoa tunnelin viereen: aliasalue, palvelimen pooli, pushatut etuliitteet, VPC-reitit. Vanhentunut alias rikkoo jokaisen poolin osoitteen, vanhentunut reitti rikkoo yhden suunnan, puuttuva push kätkee etuliitteen asiakkaalta ja väärä iroute lähettää etuliitteen väärälle peerille. Seuraava aliverkon lisääjä tarvitsee kaikki neljä yhteen paikkaan, ja muistiinpano on halvempi kuin ilta.