OpenVPN GCE-l: lisa alias-IP enne marsruutide pushimist

Pushitud marsruut ei tee VM-ist next hopi. Lisa alias-IP vahemik, sobit see serveri pooliga ja loo VPC tagasimarsruut enne klientide testimist.

Klient helistab Compute Engine VM-il olevale OpenVPN-serverile, olekuaken näitab ühendatud, ja ping VPC-sisesesse hosti ei jõua ikkagi kuhugi. Instinkt on lisada veel üks push-rida, ja see ei paranda seda kunagi. Compute Engine otsustab, kuhu paketid lähevad, oma marsruutitabeli ja VM-i liidesel tegelikult olevate aadresside järgi, seega tunnelipool, mida VM ei oma, on pool, kuhu keegi ei toimeta.

Jälgi ebaõnnestuvat paketti, mitte konfiguratsioonifaili, ja puuduvad tükid ilmuvad õiges järjekorras.

Alusta surevast paketist

SYN lahkub kliendist, maandub tunnelis ja jõuab VM-ini kapseldatud paketina VPC-sisese sihtkoha jaoks. OpenVPN dekapseldab selle ja üritab selle eth0 kaudu edasi saata, kus fabric küsib enne kõike muud ühe küsimuse: kas see instants omab sihtaadressi. Teise inimese alavõrgust lõigatud tunnelipool kukub sellele küsimusele läbi ja pakett visatakse minema enne, kui ühtegi marsruuti või tulemüürireeglit vaadatakse.

Niisiis on kliendist VPC-sse suunal kaks eraldi nõuet ja kumbki ei ole push-direktiiv. VM vajab alias-vahemikku, mis katab tunnelipooli, ja just see teeb temast nende aadresside õiguspärase omaniku. VPC vajab marsruuti, mis nimetab VM-i iga kaitstud prefiksi jaoks next hopiks. Kui üks kahest puudub, sureb pakett teises kohas, samal ajal kui klient näeb sama vaikust.

Loe riket selles järjekorras, sest kliendi poolelt näevad mõlemad tingimused identsed välja. Tunnel, mis teatab ühendatud olekust, kui miski ei vasta, on topoloogiaprobleemi tunnus, mitte halva šifri oma.

Kas instants omab tunnelipooli

Anna VM-ile teisene vahemik tema enda alavõrgus ja lase seejärel OpenVPN-il jagada aadresse täpselt sellest vahemikust. Instantsil, mille primaarne aadress on 10.156.0.10/20, hoiab /28 alias pooli eraldi aadressidest, mis teistel instantsidel juba on:

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

Serveri direktiiv peab siis kirjeldama sama plokki. Selle esimene aadress saab tunnelilüüsiks ja ülejäänud aadressid jagatakse klientidele. Siin kirjeldavad kaks numbrit ühte plokki, võrk ja netmask, ja see on pooli süntaks, mida OpenVPN veel ootab.

server 10.156.1.0 255.255.255.240

Kinnita, et aadress jõudis tõesti liidesele, mitte ainult OpenVPN-i konfiguratsiooni. Fabric edastab seda, mida NIC teatab, mitte seda, mida deemon usub. Üks käsk selgitab:

ip -4 addr show dev eth0

Teisene aadress, mis ei jõua kunagi eth0-ni, või pool, mis kattub teise alavõrguga, ilmub hiljem katkendliku kadudena, mitte käivitusveana. Deemon käivitub, kliendid ühenduvad ja ainult mõned sihtkohad käituvad valesti. Hoia alias-vahemik väike, et pooli oleks marsruutitabelis lihtne ära tunda. Ära lõika seda kunagi alavõrgust, mida teine instants juba kasutab.

Anna tagasiliiklusele next hop

VPC-hostist tulev vastus on adresseeritud tunnelipoolis olevale kliendiaadressile, mis ei kuulu ühessegi alavõrku, mida VPC teab. Ilma selle pooli marsruudita peatub vastus esimesel hopil, millel pole vastet, ja päring võis kaugemas otsas hoopis õnnestuda.

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 marsruuti on vaja iga prefiksi jaoks, mis asub kliendi taga, mitte VPC sees. Need prefiksid vajavad ka iroute-kirjet selle kliendi ccd-failis. See kirje on serveripoolne arvepidamine: see ütleb serverile, milline klient prefiksi omab, ja see ei paigalda kliendile endale midagi.

Hoia push-nimekiri vestluse kliendipoole jaoks, sest see lisab marsruute ainult ühenduvale masinale. VPC alavõrgu push-rida ja VPC marsruut tagasi pooli juurde on sama tee kaks poolt, ja kumbki pool üksi annab tunneli, mis kannab päringuid, aga mitte vastuseid.

Tulemüürid, edastamine ja nendevahelised hüpped

VPC tulemüür hindab dekapseldatud paketti, seega peab ingress-reegel lubama tunnelipooli ja iga saidi prefiksi, mis jõuab VM-ini sellel teel. Default-deny hoiak ebaõnnestub siin vaikselt: pakett visatakse pärast dekapseldamist minema ja OpenVPN-i logi näitab tervet seanssi.

Igal Linux-hostil, mis edastab, mitte ei lõpeta, kontrolli, kas net.ipv4.ip_forward on lubatud. Omandireegel kehtib ka seal: masin, mis edastab alavõrgu jaoks, mida tal pole, viskab paketi minema täpselt nagu VM. Loe väärtust enne, kui tunnelit süüdistad.

Kui ebaõnnestub täpselt üks prefiks

Osaline rike on kõige lihtsamini loetav juhtum, sest kõik muu teel on juba tõestatud. Alusta marsruutide loendist ja loe selle kirje sihtvahemik ja next hop, mis peaks prefiksi katma, seejärel loe instantsi kirjeldust ja võrdle selle alias-vahemikku pooliga, mida server jagab.

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

Puuduv marsruut näitab end prefiksi jaoks next hopi puudumisena, samas kui puuduv alias näitab end liidesel minema visatud paketina; kliendi juurest näevad need kaks sarnased välja ja neis kahes väljundis on nad täiesti erinevad. Kui mõlemad on olemas, on järelejäänud kahtlusalune selle kliendi ccd-iroute, kes prefiksile pretendeerib.

Kirjuta neli väärtust tunneli kõrvale: alias-vahemik, serveri pool, pushitud prefiksid, VPC marsruudid. Aegunud alias rikub iga pooli aadressi, aegunud marsruut rikub ühe suuna, puuduv push peidab prefiksi kliendi eest ja vale iroute saadab prefiksi vale peeri juurde. Järgmine inimene, kes alavõrgu lisab, vajab kõiki nelja ühes kohas, ja see märge on odavam kui õhtu.

Seotud artiklid