OpenVPN v GCE: pridajte alias IP, skôr než začnete pushovať trasy

Pushovaná trasa neurobí z VM next hop. Pridajte rozsah alias IP, zlaďte ho s poolom servera a vytvorte návratovú trasu vo VPC, skôr než začnete testovať klientov.

Klient sa pripojí k serveru OpenVPN na VM Compute Engine, stavové okno hlási pripojené, a ping na hostiteľa vo VPC napriek tomu nikam nedorazí. Inštinkt je pridať ďalší push riadok, a to to nikdy neopraví. Compute Engine rozhoduje, kam pakety pôjdu, podľa svojej vlastnej smerovacej tabuľky a podľa adries, ktoré rozhranie VM skutočne má, takže pool tunela, ktorý VM nevlastní, je pool, kam nikto nedoručuje.

Sledujte umierajúci paket namiesto konfiguračného súboru a chýbajúce časti sa objavia v poradí.

Začnite pri pakete, ktorý umiera

SYN opustí klienta, vstúpi do tunela a dorazí k VM ako zapuzdrený paket pre cieľ vo VPC. OpenVPN ho rozbalí a pokúsi sa ho odovzdať cez eth0, kde fabric položí jednu otázku pred všetkým ostatným: vlastní táto inštancia cieľovú adresu. Pool tunela vyrezaný z podsiete niekoho iného na túto otázku odpovie nie, a paket je zahodený skôr, než sa skontroluje akákoľvek trasa alebo pravidlo firewallu.

Smer od klienta do VPC má teda dve oddelené požiadavky a ani jedna z nich nie je push direktíva. VM potrebuje rozsah alias, ktorý pokrýva pool tunela, a práve to z nej robí oprávneného vlastníka týchto adries. VPC potrebuje trasu, ktorá označí VM ako next hop pre každý chránený prefix. Ak chýba jedno, paket umrie na inom mieste, zatiaľ čo klient vidí to isté ticho.

Čítajte poruchu v tomto poradí, pretože z pohľadu klienta obe podmienky vyzerajú rovnako. Tunel, ktorý hlási pripojené, keď nič neodpovedá, je znakom problému topológie, nie zlej šifry.

Vlastní inštancia pool tunela

Dajte VM sekundárny rozsah v rámci jej vlastnej podsiete a potom nechajte OpenVPN rozdávať adresy presne z tohto rozsahu. Na inštancii, ktorej primárna adresa je 10.156.0.10/20, drží alias /28 pool oddelený od adries, ktoré už majú iné inštancie:

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

Direktíva server potom musí opísať ten istý blok. Jej prvá adresa sa stane bránou tunela a zvyšné adresy sa rozdelia klientom. Dve čísla tu opisujú jeden blok, sieť a masku siete, a to je syntax poolu, ktorú OpenVPN stále očakáva.

server 10.156.1.0 255.255.255.240

Overte, že adresa skutočne pristála na rozhraní a nie len v konfigurácii OpenVPN. Fabric odovzdáva to, čo hlási NIC, nie to, čomu verí démon. Jediný príkaz to rozhodne:

ip -4 addr show dev eth0

Sekundárna adresa, ktorá nikdy nedorazí na eth0, alebo pool, ktorý sa prekrýva s inou podsietou, sa neskôr prejaví ako občasné straty, nie ako chyba pri štarte. Démon naštartuje, klienti sa pripoja a len niektoré ciele sa správajú zle. Držte rozsah alias malý, aby bol pool v tabuľke trás ľahko rozpoznateľný. Nikdy ho nevyrezávajte z podsiete, ktorú už iná inštancia používa.

Dajte návratovej premávke next hop

Odpoveď z hostiteľa vo VPC je adresovaná adrese klienta v poole tunela, ktorá nepatrí žiadnej podsieti, ktorú VPC pozná. Bez trasy pre tento pool sa odpoveď zastaví na prvom hope bez zhody a požiadavka mohla na druhom konci pokojne uspieť.

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

Rovnaká trasa je potrebná pre každý prefix, ktorý leží za klientom, nie vo VPC. Tieto prefixy potrebujú aj záznam iroute v súbore ccd daného klienta. Ten záznam je účtovníctvo na strane servera: hovorí serveru, ktorý klient prefix vlastní, a neinštaluje nič na samotnom klientovi.

Ponechajte push zoznam pre klientsku stranu konverzácie, pretože pridáva trasy len na stroj, ktorý sa pripája. Push riadok pre podsieti VPC a trasa VPC späť do poolu sú dve polovice tej istej cesty a každá polovica sama vytvorí tunel, ktorý nesie požiadavky, ale nie odpovede.

Firewally, forwardovanie a hopy medzi nimi

Firewall VPC vyhodnocuje rozbalený paket, takže pravidlo ingress musí pustiť pool tunela a každý prefix webu, ktorý sa k VM dostane touto cestou. Postoj default-deny tu zlyháva ticho: paket je zahodený po rozbalení a log OpenVPN ukazuje zdravú reláciu.

Na každom hostiteľovi Linux, ktorý forwarduje a nekončí, skontrolujte, či je zapnuté net.ipv4.ip_forward. Pravidlo vlastníctva platí aj tam: stroj, ktorý forwarduje pre podsieti, ktorú nemá, paket zahodí rovnako ako VM. Prečítajte si hodnotu, skôr než obviníte tunel.

Keď zlyhá presne jeden prefix

Čiastočná porucha je najľahšie čitateľný prípad, pretože všetko ostatné na ceste už je preukázané. Začnite zoznamom trás a prečítajte cieľový rozsah a next hop záznamu, ktorý by mal prefix pokryť, potom prečítajte popis inštancie a porovnajte jej rozsah alias s poolom, ktorý server rozdáva.

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

Chýbajúca trasa sa prejaví ako žiadny next hop pre prefix, zatiaľ čo chýbajúci alias sa prejaví ako paket zahodený na rozhraní; z pohľadu klienta vyzerajú oba podobne a v týchto dvoch výstupoch sú úplne odlišné. Ak sú oba, zostávajúcim podozrivým je iroute ccd klienta, ktorý si prefix nárokuje.

Zapíšte si štyri hodnoty vedľa tunela: rozsah alias, pool servera, pushované prefixy, trasy VPC. Zastaraný alias rozbije každú adresu poolu, zastaraná trasa rozbije jeden smer, chýbajúci push skryje prefix pred klientom a zlý iroute pošle prefix nesprávnemu peerovi. Ďalší človek, ktorý pridá podsieti, potrebuje všetky štyri na jednom mieste, a tá poznámka je lacnejšia než večer.

Súvisiace články