OpenVPN op GCE: voeg 'n alias-IP by voordat jy roetes push

'n Kliënt skakel die OpenVPN-bediener op 'n Compute Engine-VM, die statusvenster sê verbind, en 'n ping na 'n gasheer in die VPC gaan steeds nêrens heen nie. Die instink is om nog 'n push-lyn by te voeg, en dit maak dit nooit reg nie. Compute Engine besluit waar pakkette gaan op grond van sy eie roetetabel en van die adresse wat 'n VM-koppelvlak werklik het, so 'n tonnelpoel wat die VM nie besit nie, is 'n poel waarheen niemand aflewer nie.

Volg die falende pakket eerder as die konfigurasielêer, en die ontbrekende stukke verskyn in volgorde.

Begin by die pakket wat sterf

Die SYN verlaat die kliënt, beland in die tonnel en bereik die VM as 'n ingekapselde pakket vir 'n bestemming in die VPC. OpenVPN dekapsuleer dit en probeer dit deur eth0 aanstuur, waar die fabric voor alles anders een vraag vra: besit hierdie instansie die bestemmingsadres. 'n Tonnelpoel wat uit iemand anders se subnet gesny is, faal daardie vraag, en die pakket word weggegooi voordat enige roete of firewallreël geraadpleeg word.

Die rigting van kliënt na VPC het dus twee afsonderlike vereistes, en nie een van hulle is 'n push-riglyn nie. Die VM het 'n aliasreeks nodig wat die tonnelpoel dek, en dit is wat dit 'n wettige eienaar van daardie adresse maak. Die VPC het 'n roete nodig wat die VM vir elke beskermde voorvoegsel as volgende hop noem. Mis enige een en die pakket sterf op 'n ander plek, terwyl die kliënt dieselfde stilte sien.

Lees die fout in daardie volgorde, want van die kliëntkant af lyk die twee voorwaardes identies. 'n Tonnel wat verbind rapporteer terwyl niks antwoord nie, is die kenmerk van 'n topologieprobleem en nie van 'n slegte cipher nie.

Besit die instansie die tonnelpoel

Gee die VM 'n sekondêre reeks binne sy eie subnet en laat OpenVPN adresse presies uit daardie reeks uitdeel. Op 'n instansie met primêre adres 10.156.0.10/20 hou 'n /28-alias die poel apart van die adresse wat ander instansies al het:

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

Die server-riglyn moet dan dieselfde blok beskryf. Sy eerste adres word die tonnelpoort en die oorblywende adresse word aan kliënte uitgedeel. Twee getalle beskryf hier een blok, 'n netwerk en 'n netmasker, en dit is die poelsintaksis wat OpenVPN nog verwag.

server 10.156.1.0 255.255.255.240

Bevestig dat die adres werklik op die koppelvlak beland het en nie net in die OpenVPN-konfigurasie nie. Die fabric stuur deur wat die NIC rapporteer, nie wat die daemon glo nie. Een opdrag beslis dit:

ip -4 addr show dev eth0

'n Sekondêre adres wat nooit eth0 bereik nie, of 'n poel wat 'n ander subnet oorvleuel, verskyn later as sporadiese verlies eerder as as 'n opstartfout. Die daemon begin, kliënte verbind, en net sommige bestemmings gedra hulle verkeerd. Hou die aliasreeks klein sodat die poel in 'n roetetabel maklik herkenbaar is. Sny dit nooit uit 'n subnet wat 'n ander instansie al gebruik nie.

Gee die terugverkeer 'n volgende hop

'n Antwoord van 'n gasheer in die VPC is geadresseer aan 'n kliëntadres in die tonnelpoel, wat aan geen subnet behoort wat die VPC ken nie. Sonder 'n roete vir daardie poel stop die antwoord by die eerste hop sonder 'n treffer, en die versoek het heel moontlik aan die ander kant geslaag.

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

Dieselfde roete is nodig vir elke voorvoegsel wat agter 'n kliënt lê eerder as in die VPC. Daardie voorvoegsels het ook 'n iroute-inskrywing nodig in daardie kliënt se ccd-lêer. Daardie inskrywing is boekhouding aan die bedienerkant: dit sê vir die bediener watter kliënt die voorvoegsel besit, en dit installeer niks op die kliënt self nie.

Hou die push-lys vir die kliëntkant van die gesprek, want dit voeg net roetes by die masjien wat verbind. 'n Push-lyn vir 'n VPC-subnet en 'n VPC-roete terug na die poel is twee helftes van dieselfde pad, en enige helfte alleen lewer 'n tonnel wat versoeke dra maar geen antwoorde nie.

Firewalls, aanstuur en die hope tussenin

Die VPC-firewall evalueer die gedekapsuleerde pakket, so 'n inkomende reël moet die tonnelpoel toelaat en enige terreinvoorvoegsel wat die VM op daardie manier bereik. 'n Verstek-weier-houding faal hier stil: die pakket word ná dekapsulering weggegooi, en die OpenVPN-log wys 'n gesonde sessie.

Kyk op enige Linux-gasheer wat aanstuur eerder as termineer of net.ipv4.ip_forward geaktiveer is. Die eienaarskapreël geld daar ook: 'n boks wat aanstuur vir 'n subnet wat hy nie het nie, gooi die pakket net so weg soos die VM. Lees die waarde voordat jy die tonnel blameer.

Wanneer presies een voorvoegsel faal

Gedeeltelike mislukking is die maklikste geval om te lees, want alles anders in die pad is al bewys. Begin by die roetelys en lees die bestemmingsreeks en volgende hop van die inskrywing wat die voorvoegsel behoort te dek, lees dan die instansiebeskrywing en vergelyk sy aliasreeks met die poel wat die bediener uitdeel.

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

'n Ontbrekende roete wys homself as geen volgende hop vir die voorvoegsel, terwyl 'n ontbrekende alias homself wys as 'n pakket wat by die koppelvlak weggegooi word; van die kliënt af lyk die twee eenders en in daardie twee uitsette heeltemal anders. As albei daar is, is die oorblywende verdagte die ccd-iroute vir die kliënt wat die voorvoegsel opeis.

Skryf die vier waardes langs die tonnel neer: aliasreeks, bedienerpoel, gepushte voorvoegsels, VPC-roetes. 'n Verouderde alias breek elke poeladres, 'n verouderde roete breek een rigting, 'n ontbrekende push verberg die voorvoegsel vir die kliënt, en 'n verkeerde iroute stuur die voorvoegsel na die verkeerde peer. Die volgende persoon wat 'n subnet byvoeg het al vier op een plek nodig, en die nota is goedkoper as die aand.