OpenVPN på GCE: legg til ein alias-IP før du pushar ruter

Ei pusha rute gjer ikkje VM-en til next hop. Legg til alias-IP-området, få det til å samsvare med serverpoolen og lag den returnerande VPC-ruta før du testar klientar.

Ein klient ringjer opp OpenVPN-tenaren på ein Compute Engine-VM, statusvindauget seier tilkopla, og ein ping til ein vert i VPC-en endar framleis ingen stad. Instinktet er å leggje til endå ei push-linje, og det løyser det aldri. Compute Engine avgjer kvar pakkane går ut frå sin eigen rutetabell og ut frå adressene som eit VM-grensesnitt faktisk held, så ein tunnelpool som VM-en ikkje eig, er ein pool som ingen leverer til.

Følg den feilande pakken i staden for konfigurasjonsfila, så dukkar dei manglande delane opp i rekkjefølgje.

Start ved pakken som døyr

SYN-pakken forlèt klienten, landar i tunnelen og når VM-en som ein innkapsla pakke til ein destinasjon i VPC-en. OpenVPN avkapslar han og prøver å videresende han ut av eth0, der fabric stiller eitt spørsmål før alt anna: eig denne instansen destinasjonsadressa. Ein tunnelpool som er skoren ut av subnetet til ein annan, feilar på det spørsmålet, og pakken blir kasta før nokon rute eller brannmurregel blir konsultert.

Retninga frå klient til VPC har altså to skilde krav, og ingen av dei er eit push-direktiv. VM-en treng eit aliasområde som dekkjer tunnelpoolen, og det er nettopp det som gjer han til rettmessig eigar av desse adressene. VPC-en treng ei rute som peikar ut VM-en som next hop for kvart verna prefiks. Manglar eitt av dei, døyr pakken ein annan stad, medan klienten ser den same stilla.

Les feilen i den rekkjefølgja, for frå klientsida ser dei to vilkåra identiske ut. Ein tunnel som rapporterer tilkopla medan ingenting svarar, er signaturen på eit topologiproblem og ikkje på eit dårleg cipher.

Eig instansen tunnelpoolen

Gje VM-en eit sekundært område inne i sitt eige subnet, og la deretter OpenVPN dele ut adresser frå nøyaktig det området. På ein instans der primæradressa er 10.156.0.10/20, held eit /28-alias poolen skild frå adressene andre instansar allereie har:

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

Serverdirektivet må då skildre den same blokka. Den første adressa blir gatewayen til tunnelen, og dei resterande adressene blir delte ut til klientar. To tal skildrar éi blokk her, eit nett og ei nettmask, og det er den pool-syntaksen OpenVPN framleis ventar.

server 10.156.1.0 255.255.255.240

Stadfest at adressa verkeleg landa på grensesnittet og ikkje berre inne i OpenVPN-konfigurasjonen. Fabric videresender det NIC-en rapporterer, ikkje det daemonen trur. Éin kommando avgjer det:

ip -4 addr show dev eth0

Ei sekundær adresse som aldri når eth0, eller ein pool som overlappar eit anna subnet, viser seg seinare som periodisk tap i staden for som ein oppstartsfeil. Daemonen startar, klientar koplar til, og berre nokre destinasjonar oppfører seg feil. Hald aliasområdet lite slik at poolen er lett å kjenne att i ein rutetabell. Skjer han aldri ut av eit subnet som ein annan instans allereie brukar.

Gje returtrafikken ein next hop

Eit svar frå ein vert i VPC-en er adressert til ei klientadresse i tunnelpoolen, som ikkje høyrer til noko subnet VPC-en kjenner. Utan ei rute for den poolen stoppar svaret ved det første hoppet utan treff, og førespurnaden kan godt ha lukkast i den andre enden.

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

Den same ruta trengst for kvart prefiks som ligg bak ein klient i staden for inne i VPC-en. Dei prefiksa treng òg ein iroute-oppføring i ccd-fila til den klienten. Den oppføringa er bokføring på serversida: ho fortel tenaren kva klient som eig prefikset, og ho installerar ingenting på sjølve klienten.

Hald push-lista for klientsida av samtalen, for ho legg berre til ruter på maskina som koplar til. Ei push-linje for eit VPC-subnet og ei VPC-rute tilbake til poolen er to halvdelar av same veg, og kvar halvdel åleine gjev ein tunnel som ber førespurnader men ikkje svar.

Brannmurar, videresending og hoppa imellom

VPC-brannmuren vurderer den avkapsla pakken, så ein ingress-regel må sleppe til tunnelpoolen og kvart site-prefiks som når VM-en den vegen. Ei default-deny-haldning feilar stille her: pakken blir kasta etter avkapslinga, og OpenVPN-loggen viser ei frisk økt.

Kontroller på kvar Linux-vert som videresender i staden for å terminere at net.ipv4.ip_forward er slått på. Eigarregelen gjeld der òg: ei maskin som videresender for eit subnet ho ikkje har, kastar pakken like eins som VM-en ville gjort. Les verdien før du gjev tunnelen skulda.

Når nøyaktig eitt prefiks feilar

Delvis feil er det lettaste tilfellet å lese, fordi alt anna på vegen allereie er prova. Start med rutelista og les destinasjonsområdet og next hop for oppføringa som skulle dekkje prefikset, les deretter instansskildringa og samanlikn aliasområdet hennar med poolen tenaren deler ut.

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

Ei manglande rute viser seg som ingen next hop for prefikset, medan eit manglande alias viser seg som ein pakke som blir kasta ved grensesnittet; frå klienten ser dei to like ut og i dei to utskriftene er dei heilt ulike. Om begge finst, er den gjenverande mistenkte ccd-irouten for klienten som krev prefikset.

Skriv ned dei fire verdiane ved sida av tunnelen: aliasområde, serverpool, pusha prefiks, VPC-ruter. Eit utdatert alias øydelegg kvar pooladresse, ei utdatert rute øydelegg éi retning, ein manglande push gøymer prefikset for klienten, og ein feil iroute sender prefikset til feil peer. Den neste som legg til eit subnet treng alle fire på éin stad, og notatet er billegare enn kvelden.

Relaterte artiklar