OpenVPN na GCE-u: dodajte alias IP prije nego pushate rute

Pushana ruta ne čini VM next hopom. Dodajte raspon alias IP-a, uskladite ga s poolom poslužitelja i stvorite povratnu rutu u VPC-u prije testiranja klijenata.

Klijent se spaja na poslužitelj OpenVPN na VM-u Compute Engine, statusni prozor kaže povezano, a ping na host unutar VPC-a ipak ne stiže nikamo. Instinkt je dodati još jedan push redak, i to to nikada ne popravlja. Compute Engine odlučuje kamo paketi idu na temelju vlastite tablice ruta i adresa koje VM sučelje stvarno ima, pa je pool tunela koji VM ne posjeduje pool u koji nitko ne dostavlja.

Slijedite paket koji umire umjesto konfiguracijske datoteke i dijelovi koji nedostaju pojavit će se redom.

Počnite od paketa koji umire

SYN napušta klijenta, ulazi u tunel i dolazi do VM-a kao zapakirani paket za odredište unutar VPC-a. OpenVPN ga raspakira i pokuša proslijediti kroz eth0, gdje fabric postavlja jedno pitanje prije svega ostalog: posjeduje li ova instanca odredišnu adresu. Pool tunela izrezan iz tuđe podmreže na to pitanje odgovara ne, i paket se odbacuje prije nego što se provjeri bilo koja ruta ili pravilo vatrozida.

Smjer od klijenta prema VPC-u ima dakle dva odvojena zahtjeva i nijedan od njih nije push direktiva. VM treba raspon aliasa koji pokriva pool tunela, i upravo to čini VM zakonitim vlasnikom tih adresa. VPC treba rutu koja VM navodi kao next hop za svaki zaštićeni prefiks. Nedostaje li jedno, paket umire na drugom mjestu, dok klijent vidi istu tišinu.

Čitajte kvar tim redom, jer sa strane klijenta oba uvjeta izgledaju jednako. Tunel koji javlja povezano dok ništa ne odgovara znak je problema s topologijom, a ne loše šifre.

Posjeduje li instanca pool tunela

Dajte VM-u sekundarni raspon unutar njegove vlastite podmreže, a zatim neka OpenVPN dodjeljuje adrese točno iz tog raspona. Na instanci čija je primarna adresa 10.156.0.10/20, alias /28 drži pool odvojenim od adresa koje druge instance već imaju:

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

Direktiva server tada mora opisati isti blok. Njezina prva adresa postaje gateway tunela, a preostale adrese dijele se klijentima. Ovdje dva broja opisuju jedan blok, mrežu i masku, i to je sintaksa poola koju OpenVPN još uvijek očekuje.

server 10.156.1.0 255.255.255.240

Potvrdite da je adresa doista stigla na sučelje, a ne samo u konfiguraciju OpenVPN-a. Fabric prosljeđuje ono što NIC prijavljuje, ne ono što daemon vjeruje. Jedna naredba to rješava:

ip -4 addr show dev eth0

Sekundarna adresa koja nikada ne stigne na eth0, ili pool koji se preklapa s drugom podmrežom, kasnije se pokazuje kao povremeni gubici, a ne kao pogreška pri pokretanju. Daemon se pokreće, klijenti se spajaju i samo se neka odredišta ponašaju pogrešno. Držite raspon aliasa malen kako bi pool u tablici ruta bio lako prepoznatljiv. Nikada ga ne režite iz podmreže koju druga instanca već koristi.

Dajte povratnom prometu next hop

Odgovor s hosta u VPC-u adresiran je na adresu klijenta u poolu tunela, koja ne pripada nijednoj podmreži koju VPC poznaje. Bez rute za taj pool odgovor se zaustavlja na prvom hopu bez podudaranja, a zahtjev je na drugom kraju mogao sasvim dobro uspjeti.

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 ruta potrebna je za svaki prefiks koji se nalazi iza klijenta, a ne unutar VPC-a. Ti prefiksi trebaju i iroute zapis u ccd datoteci tog klijenta. Taj zapis je knjigovodstvo na strani poslužitelja: govori poslužitelju koji klijent posjeduje prefiks i ne instalira ništa na samom klijentu.

Zadržite push popis za klijentsku stranu razgovora jer dodaje rute samo na stroj koji se spaja. Push redak za podmrežu VPC-a i ruta VPC-a natrag u pool dvije su polovice istog puta, a svaka polovica sama stvara tunel koji nosi zahtjeve, ali ne odgovore.

Vatrozidi, prosljeđivanje i hopovi između

Vatrozid VPC-a procjenjuje raspakirani paket, pa ingress pravilo mora propustiti pool tunela i svaki prefiks web-mjesta koji na taj način stigne do VM-a. Stav default-deny ovdje tiho zataji: paket se odbacuje nakon raspakiravanja, a OpenVPN zapisnik pokazuje zdravu sesiju.

Na svakom Linux hostu koji prosljeđuje, a ne završava, provjerite je li uključen net.ipv4.ip_forward. Pravilo vlasništva vrijedi i tamo: stroj koji prosljeđuje za podmrežu koju ne posjeduje odbacuje paket jednako kao VM. Pročitajte vrijednost prije nego što okrivite tunel.

Kada zakaže točno jedan prefiks

Djelomični kvar najlakše je čitati jer je sve ostalo na putu već dokazano. Počnite s popisom ruta i pročitajte odredišni raspon i next hop zapisa koji bi trebao pokriti prefiks, zatim pročitajte opis instance i usporedite njezin raspon aliasa s poolom koji poslužitelj dijeli.

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

Ruta koja nedostaje pokazuje se kao nikakav next hop za prefiks, dok se alias koji nedostaje pokazuje kao paket odbačen na sučelju; sa strane klijenta to dvoje izgleda slično, a u tim dvama izlazima potpuno je različito. Ako su oba prisutna, preostali sumnjivac je ccd iroute klijenta koji polaže pravo na prefiks.

Zapišite četiri vrijednosti pokraj tunela: raspon aliasa, pool poslužitelja, pushani prefiksi, rute VPC-a. Zastario alias kvari svaku adresu poola, zastarjela ruta kvari jedan smjer, push koji nedostaje skriva prefiks od klijenta, a pogrešan iroute šalje prefiks pogrešnom peeru. Sljedeća osoba koja doda podmrežu treba sve četiri na jednom mjestu, a ta je bilješka jeftinija od večeri.

Povezani članci