OpenVPN v GCE: dodajte alias IP, preden potisnete poti

Potisnjena pot ne naredi VM next hop. Dodajte obseg alias IP, uskladite ga s poolom strežnika in ustvarite povratno pot v VPC, preden preizkusite odjemalce.

Odjemalec pokliče strežnik OpenVPN na VM Compute Engine, statusno okno pravi povezano, ping na gostitelja v VPC pa vseeno ne prispe nikamor. Nagon je dodati še eno vrstico push in to tega nikoli ne popravi. Compute Engine odloča, kam gredo paketi, na podlagi lastne usmerjevalne tabele in naslovov, ki jih vmesnik VM dejansko ima, zato je pool tunela, ki ga VM ne poseduje, pool, kamor nihče ne dostavi.

Sledite paketu, ki umre, namesto konfiguracijske datoteke, in manjkajoči deli se pojavijo po vrsti.

Začnite pri paketu, ki umre

SYN zapusti odjemalca, pristane v tunelu in doseže VM kot zapakiran paket za cilj v VPC. OpenVPN ga razpakira in ga poskusi posredovati skozi eth0, kjer fabric pred vsem drugim postavi eno vprašanje: ali ta instanca poseduje ciljni naslov. Pool tunela, izrezan iz podsmeža nekoga drugega, na to vprašanje ne odgovori pritrdilno, in paket se zavrže, preden se preveri katera koli pot ali pravilo požarnega zidu.

Smer od odjemalca do VPC ima torej dve ločeni zahtevi in nobena od njiju ni direktiva push. VM potrebuje obseg alias, ki pokriva pool tunela, in prav to ga naredi zakonitega lastnika teh naslovov. VPC potrebuje pot, ki VM navede kot next hop za vsak zaščiteni prefiks. Če manjka eno, paket umre na drugem mestu, medtem ko odjemalec vidi isto tišino.

Berite napako v tem vrstnem redu, ker sta z vidika odjemalca oba pogoja videti enaka. Tunel, ki poroča povezano, ko se nič ne odziva, je znak težave s topologijo, ne slabe šifre.

Ali instanca poseduje pool tunela

Dajte VM sekundarni obseg znotraj njegovega lastnega podsmeža in nato pustite OpenVPN, da razdeljuje naslove natanko iz tega obsega. Na instanci, katere primarni naslov je 10.156.0.10/20, alias /28 drži pool ločen od naslovov, ki jih druge instance že imajo:

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

Direktiva server mora nato opisati isti blok. Njen prvi naslov postane prehod tunela, preostali naslovi pa se razdelijo odjemalcem. Tu dve števili opisujeta en blok, omrežje in masko, in to je sintaksa poola, ki jo OpenVPN še vedno pričakuje.

server 10.156.1.0 255.255.255.240

Potrdite, da je naslov res pristal na vmesniku in ne le v konfiguraciji OpenVPN. Fabric posreduje tisto, kar poroča NIC, ne tistega, kar verjame daemon. En ukaz to razreši:

ip -4 addr show dev eth0

Sekundarni naslov, ki nikoli ne doseže eth0, ali pool, ki se prekriva z drugim podsmežem, se pozneje pokaže kot občasne izgube, ne kot napaka ob zagonu. Daemon se zažene, odjemalci se povežejo in le nekatere destinacije se obnašajo narobe. Držite obseg alias majhen, da bo pool v usmerjevalni tabeli lahko prepoznaven. Nikoli ga ne izrežite iz podsmeža, ki ga druga instanca že uporablja.

Dajte povratnemu prometu next hop

Odgovor z gostitelja v VPC je naslovljen na naslov odjemalca v poolu tunela, ki ne pripada nobenemu podsmežu, ki ga VPC pozna. Brez poti za ta pool se odgovor ustavi na prvem skoku brez ujemanja, zahteva pa je na drugem koncu lahko povsem uspela.

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

Ista pot je potrebna za vsak prefiks, ki leži za odjemalcem in ne v VPC. Ti prefiksi potrebujejo tudi vnos iroute v datoteki ccd tega odjemalca. Ta vnos je knjigovodstvo na strani strežnika: pove strežniku, kateri odjemalec poseduje prefiks, in ne namesti ničesar na samem odjemalcu.

Obdržite seznam push za odjemalsko stran pogovora, ker doda poti le na stroj, ki se povezuje. Vrstica push za podsmež VPC in pot VPC nazaj v pool sta dve polovici iste poti in vsaka polovica sama ustvari tunel, ki nosi zahteve, ne pa odgovorov.

Požarni zidovi, posredovanje in skoki vmes

Požarni zid VPC ocenjuje razpakiran paket, zato mora pravilo ingress spustiti pool tunela in vsak prefiks spletnega mesta, ki doseže VM po tej poti. Drža default-deny tu tiho odpove: paket se zavrže po razpakiranju in dnevnik OpenVPN kaže zdravo sejo.

Na vsakem gostitelju Linux, ki posreduje in se ne konča, preverite, ali je omogočen net.ipv4.ip_forward. Pravilo lastništva velja tudi tam: stroj, ki posreduje za podsmež, ki ga nima, zavrže paket enako kot VM. Preberite vrednost, preden obtožite tunel.

Ko odpove natanko en prefiks

Delna napaka je najlažje berljiv primer, ker je vse drugo na poti že dokazano. Začnite s seznamom poti in preberite ciljni obseg in next hop vnosa, ki bi moral pokriti prefiks, nato preberite opis instance in primerjajte njen obseg alias s poolom, ki ga strežnik razdeljuje.

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

Manjkajoča pot se pokaže kot nič next hop za prefiks, medtem ko se manjkajoč alias pokaže kot paket, zavržen na vmesniku; z vidika odjemalca sta si podobna, v teh dveh izpisih pa sta popolnoma različna. Če sta prisotna oba, je preostali osumljenec iroute ccd odjemalca, ki si prefiks lasti.

Zapišite štiri vrednosti ob tunel: obseg alias, pool strežnika, potisnjeni prefiksi, poti VPC. Zastarel alias pokvari vsak naslov poola, zastarela pot pokvari eno smer, manjkajoči push skrije prefiks pred odjemalcem in napačen iroute pošlje prefiks napačnemu peeru. Naslednja oseba, ki doda podsmež, potrebuje vse štiri na enem mestu, in ta zapisek je cenejši od večera.

Sorodni članki