OpenVPN á GCE: bættu við alias-IP áður en þú pushar leiðum

Biðlari hringir í OpenVPN-þjóninn á Compute Engine VM, stöðugluggin segir tengt, og ping á hýsil inni í VPC kemst samt hvergi. Eðlishvötin er að bæta við einni push-línu í viðbót, og það lagar það aldrei. Compute Engine ákveður hvert pakkar fara út frá eigin leiðatöflu og út frá þeim heimilisföngum sem VM-tengi hefur í raun, svo tunnel pool sem VM-ið á ekki er pool sem enginn skilar í.

Fylgdu pakkanum sem mistekst í stað stillingaskrárinnar, og þá birtast hlutar sem vantar í réttri röð.

Byrjaðu á pakkanum sem deyr

SYN fer frá biðlaranum, lendir í tunnelnum og nær VM-inu sem umvafinn pakki fyrir áfangastað inni í VPC. OpenVPN afumbýr hann og reynir að senda hann út um eth0, þar sem fabric spyr einnar spurningar fyrir allt annað: á þessi instans áfangastaðinn. Tunnel pool sem skorinn er úr subneti einhvers annars fellur á þeirri spurningu, og pakkanum er hent áður en nokkur leið eða eldveggsregla er skoðuð.

Stefnan frá biðlara að VPC hefur því tvær aðskildar kröfur, og hvorug er push-fyrirmæli. VM-ið þarf alias-bil sem nær yfir tunnel poolið, og það er einmitt það sem gerir það að lögmætum eiganda þessara heimilisfanga. VPC-ið þarf leið sem nefnir VM-ið sem next hop fyrir hvert varið forskeyti. Vanti annað hvort deyr pakkinn á öðrum stað, á meðan biðlarinn sér sömu þögn.

Lestu bilunina í þeirri röð, því frá biðlarahlið líta bæði skilyrðin eins út. Tunnel sem segist tengdur á meðan ekkert svarar er einkenni topologíuvandamáls en ekki slæmrar dulritunar.

Á instansið tunnel poolið

Gefðu VM-inu annað bil inni í eigin subneti og láttu OpenVPN úthluta heimilisföngum nákvæmlega úr því bili. Á instansi þar sem aðalheimilisfangið er 10.156.0.10/20 heldur /28-alias poolinu aðskildu frá heimilisföngunum sem aðrar instansir hafa þegar:

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

server-fyrirmælin verða þá að lýsa sama blokk. Fyrsta heimilisfang þess verður tunnel-gateway, og hinum heimilisföngunum er úthlutað til biðlara. Tvær tölur lýsa einni blokk hér, net og netgrímu, og það er pool-málfræðin sem OpenVPN býst enn við.

server 10.156.1.0 255.255.255.240

Staðfestu að heimilisfangið hafi raunverulega lent á tenginu en ekki bara í OpenVPN-stillingunni. Fabric sendir áfram það sem NIC greinir frá, ekki það sem daemoninn trúir. Ein skipun ræður því:

ip -4 addr show dev eth0

Annað heimilisfang sem nær aldrei eth0, eða pool sem skarast við annað subnet, birtist síðar sem slitrótt tap en ekki sem upphafsvilla. Daemoninn startar, biðlarar tengjast, og aðeins sumir áfangastaðir hegða sér illa. Haltu alias-bilinu litlu svo poolið sé auðþekkjanlegt í leiðatöflu. Skerðu það aldrei úr subneti sem önnur instans notar þegar.

Gefðu afturumferðinni next hop

Svar frá hýsli í VPC er stílað á biðlaraheimilisfang í tunnel poolinu, sem tilheyrir engu subneti sem VPC-ið þekkir. Án leiðar fyrir það pool stöðvast svarið á fyrsta hoppi sem finnur ekkert, og beiðnin getur vel hafa tekist hinum megin.

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 leið þarf fyrir hvert forskeyti sem liggur bak við biðlara í stað inni í VPC. Þau forskeyti þurfa líka iroute-færslu í ccd-skrá þess biðlara. Sú færsla er bókhald á þjónshlið: hún segir þjóninum hvaða biðlari á forskeytið, og hún setur ekkert upp á biðlaranum sjálfum.

Haltu push-listann fyrir biðlarahlið samtalsins, því hann bætir aðeins leiðum við vélina sem tengist. Push-lína fyrir VPC-subnet og VPC-leið til baka í poolið eru tveir helmingar sömu slóðar, og hvor helmingur einn um sig gefur tunnel sem ber beiðnir en engin svör.

Eldveggir, áframsending og hoppin á milli

VPC-eldveggurinn metur afumbýtta pakkann, svo ingress-regla verður að hleypa tunnel poolinu og hverju site-forskekti sem nær VM-inu þá leið. Sjálfgefin synjunarstaða mistekst hljóðlaust hér: pakkanum er hent eftir afumbýðingu, og OpenVPN-loggurinn sýnir heilbrigða lotu.

Athugaðu á hverjum Linux-hýsli sem sendir áfram í stað þess að enda hvort net.ipv4.ip_forward sé virkt. Eignarreglan gildir þar líka: vél sem sendir áfram fyrir subnet sem hún hefur ekki hendir pakkanum alveg eins og VM-ið myndi gera. Lestu gildið áður en þú kennir tunnelnum um.

Þegar nákvæmlega eitt forskeyti mistekst

Hluta-bilun er auðveldasta tilfellið til að lesa, því allt annað á slóðinni er þegar sannað. Byrjaðu á leiðalistanum og lestu áfangabil og next hop færslunnar sem ætti að ná yfir forskeytið, lestu svo instanslýsinguna og berðu alias-bil hennar saman við poolið sem þjónninn úthlutar.

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

Leið sem vantar sýnir sig sem ekkert next hop fyrir forskeytið, á meðan alias sem vantar sýnir sig sem pakka sem er hent við tengið; frá biðlaranum líta þau tvö eins út og í þessum tveimur úttökum eru þau gjörólík. Ef bæði eru til staðar er grunaði sem eftir er ccd-iroute fyrir biðlarann sem gerir tilkall til forskeytisins.

Skrifaðu fjögur gildi niður við tunnelinn: alias-bil, server pool, pushuð forskeyti, VPC-leiðir. Úrelt alias brýtur hvert pool-heimilisfang, úrelt leið brýtur eina stefnu, push sem vantar felur forskeytið fyrir biðlaranum, og rangt iroute sendir forskeytið á rangan peer. Næsta manneskja sem bætir við subneti þarf öll fjögur á einum stað, og minnispunkturinn er ódýrari en kvöldið.