OpenVPN v GCE: přidejte alias IP, než začnete pushovat trasy

Pushovaná trasa neudělá z VM next hop. Přidejte rozsah alias IP, sladěte ho s poolem serveru a vytvořte návratovou trasu ve VPC, než začnete testovat klienty.

Klient se připojí k serveru OpenVPN na VM Compute Engine, stavové okno hlásí připojeno, a ping na hostitele ve VPC přesto nikam nedorazí. Instinkt je přidat další push řádek, a to to nikdy neopraví. Compute Engine rozhoduje, kam pakety půjdou, podle své vlastní směrovací tabulky a podle adres, které rozhraní VM skutečně má, takže pool tunelu, který VM nevlastní, je pool, kam nikdo nedoručuje.

Sledujte umírající paket místo konfiguračního souboru a chybějící části se objeví v pořadí.

Začněte u paketu, který umírá

SYN opustí klienta, vstoupí do tunelu a dorazí k VM jako zapouzdřený paket pro cíl ve VPC. OpenVPN ho rozbalí a pokusí se ho předat přes eth0, kde fabric položí jednu otázku před vším ostatním: vlastní tato instance cílovou adresu. Pool tunelu vyříznutý z podsítě někoho jiného na tuto otázku odpoví ne, a paket je zahozen dřív, než se zkontroluje jakákoli trasa nebo pravidlo firewallu.

Směr od klienta do VPC má tedy dva oddělené požadavky a ani jeden z nich není push direktiva. VM potřebuje rozsah alias, který pokrývá pool tunelu, a právě to z ní činí oprávněného vlastníka těchto adres. VPC potřebuje trasu, která označí VM jako next hop pro každý chráněný prefix. Chybí-li jedno, paket umře na jiném místě, zatímco klient vidí stejné ticho.

Čtěte poruchu v tomto pořadí, protože z pohledu klienta obě podmínky vypadají stejně. Tunel, který hlásí připojeno, když nic neodpovídá, je známkou problému topologie, ne špatné šifry.

Vlastní instance pool tunelu

Dejte VM sekundární rozsah uvnitř její vlastní podsítě a pak nechte OpenVPN rozdávat adresy přesně z tohoto rozsahu. Na instanci, jejíž primární adresa je 10.156.0.10/20, drží alias /28 pool oddělený od adres, které už mají jiné instance:

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

Direktiva server pak musí popsat stejný blok. Její první adresa se stane bránou tunelu a zbývající adresy se rozdají klientům. Dvě čísla zde popisují jeden blok, síť a masku sítě, a to je syntaxe poolu, kterou OpenVPN stále očekává.

server 10.156.1.0 255.255.255.240

Ověřte, že adresa skutečně přistála na rozhraní a ne jen v konfiguraci OpenVPN. Fabric předává to, co hlásí NIC, ne to, čemu věří daemon. Jediný příkaz to rozhodne:

ip -4 addr show dev eth0

Sekundární adresa, která nikdy nedorazí na eth0, nebo pool, který se překrývá s jinou podsítí, se později projeví jako občasné ztráty, ne jako chyba při startu. Daemon nastartuje, klienti se připojí a jen některé cíle se chovají špatně. Držte rozsah alias malý, aby byl pool v tabulce tras snadno rozpoznatelný. Nikdy ho nevyřezávejte z podsítě, kterou už jiná instance používá.

Dejte návratovému provozu next hop

Odpověď z hostitele ve VPC je adresována adrese klienta v poolu tunelu, která nepatří žádné podsíti, kterou VPC zná. Bez trasy pro tento pool se odpověď zastaví na prvním hopu bez shody a požadavek mohl na druhém konci klidně uspět.

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

Stejná trasa je potřeba pro každý prefix, který leží za klientem, ne uvnitř VPC. Tyto prefixy potřebují také záznam iroute v souboru ccd daného klienta. Ten záznam je účtování na straně serveru: říká serveru, který klient prefix vlastní, a neinstaluje nic na samotném klientovi.

Ponechte push seznam pro klientskou stranu konverzace, protože přidává trasy jen na stroj, který se připojuje. Push řádek pro podsíť VPC a trasa VPC zpět do poolu jsou dvě poloviny stejné cesty a každá polovina sama vytvoří tunel, který nese požadavky, ale ne odpovědi.

Firewally, forwardování a hopy mezi nimi

Firewall VPC vyhodnocuje rozbalený paket, takže pravidlo ingress musí pustit pool tunelu a každý prefix webu, který se k VM dostane touto cestou. Postoj default-deny zde selhává tiše: paket je zahozen po rozbalení a log OpenVPN ukazuje zdravou relaci.

Na každém hostiteli Linux, který forwarduje, a ne končí, zkontrolujte, zda je zapnuté net.ipv4.ip_forward. Pravidlo vlastnictví platí i tam: stroj, který forwarduje pro podsíť, kterou nemá, paket zahodí stejně jako VM. Přečtěte si hodnotu, než obviníte tunel.

Když selže přesně jeden prefix

Částečná porucha je nejlépe čitelný případ, protože vše ostatní na cestě už je prokázané. Začněte seznamem tras a přečtěte cílový rozsah a next hop záznamu, který by měl prefix pokrýt, pak přečtěte popis instance a porovnejte její rozsah alias s poolem, který server rozdává.

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

Chybějící trasa se projeví jako žádný next hop pro prefix, zatímco chybějící alias se projeví jako paket zahozený na rozhraní; z pohledu klienta vypadají oba podobně a v těchto dvou výstupech jsou zcela odlišné. Pokud jsou oba, zbývajícím podezřelým je iroute ccd klienta, který si prefix nárokuje.

Zapište si čtyři hodnoty vedle tunelu: rozsah alias, pool serveru, pushované prefixy, trasy VPC. Zastaralý alias rozbije každou adresu poolu, zastaralá trasa rozbije jeden směr, chybějící push skryje prefix před klientem a špatný iroute pošle prefix špatnému peeru. Další člověk, který přidá podsíť, potřebuje všechny čtyři na jednom místě, a ta poznámka je levnější než večer.

Související články