OpenVPN a GCE-n: adj hozzá alias IP-t, mielőtt útvonalakat pusholsz

A pusholt útvonal nem teszi a VM-et next hoppá. Add hozzá az alias IP-tartományt, igazítsd a szerver pooljához, és hozd létre a VPC visszaútvonalát, mielőtt klienseket tesztelsz.

Egy kliens tárcsázza a OpenVPN szervert egy Compute Engine VM-en, az állapotablak azt írja, hogy csatlakozva, és a VPC-n belüli hoszt felé küldött ping mégsem ér el sehová. Az ösztön az, hogy hozzáadjunk még egy push sort, és ez soha nem javítja meg. A Compute Engine a saját útvonaltáblája és a VM-interfész által ténylegesen birtokolt címek alapján dönti el, hová mennek a csomagok, tehát egy olyan tunnel pool, amely nem a VM tulajdona, olyan pool, ahová senki nem szállít.

A meghibásodó csomagot kövesd a konfigurációs fájl helyett, és a hiányzó darabok sorrendben előkerülnek.

Kezdd a haldokló csomaggal

A SYN elhagyja a klienst, bekerül az alagútba, és kapszulázott csomagként érkezik a VM-hez egy VPC-n belüli célállomás felé. Az OpenVPN kicsomagolja, és megpróbálja továbbítani az eth0 felé, ahol a fabric minden más előtt egyetlen kérdést tesz fel: birtokolja-e ez az instance a célcímet. Egy másvalaki alhálózatából kivágott tunnel pool elbukik ezen a kérdésen, és a csomag eldobódik, mielőtt bármilyen útvonalat vagy tűzfalszabályt megnéznének.

A kliens és a VPC irányának tehát két külön követelménye van, és egyik sem push direktíva. A VM-nek olyan alias tartományra van szüksége, amely lefedi a tunnel poolt, és ez teszi a címek jogos birtokosává. A VPC-nek olyan útvonalra van szüksége, amely minden védett prefixhez next hopként nevezi meg a VM-et. Ha bármelyik hiányzik, a csomag máshol hal meg, miközben a kliens ugyanazt a csendet látja.

Ebben a sorrendben olvasd a hibát, mert a kliens oldaláról a két feltétel azonosnak látszik. Az az alagút, amely csatlakozott állapotot jelent, miközben semmi sem válaszol, topológiai probléma jele, nem rossz titkosításé.

Birtokolja-e az instance a tunnel poolt

Adj a VM-nek egy másodlagos tartományt a saját alhálózatán belül, majd az OpenVPN pontosan abból a tartományból ossza ki a címeket. Egy olyan instance-en, amelynek elsődleges címe 10.156.0.10/20, a /28 alias elkülöníti a poolt a többi instance által már birtokolt címektől:

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

A server direktívának ekkor ugyanazt a blokkot kell leírnia. Az első címe lesz az alagút átjárója, a többi cím pedig a kliensekhez kerül. Itt két szám ír le egy blokkot, egy hálózat és egy netmask, és ez az a pool szintaxis, amelyet az OpenVPN még mindig vár.

server 10.156.1.0 255.255.255.240

Erősítsd meg, hogy a cím valóban felkerült az interfészre, és nem csak az OpenVPN konfigurációjában van. A fabric azt továbbítja, amit a NIC jelent, nem azt, amit a daemon hisz. Egyetlen parancs eldönti:

ip -4 addr show dev eth0

Egy másodlagos cím, amely soha nem éri el az eth0-t, vagy egy pool, amely átfed egy másik alhálózattal, később szakaszos csomagvesztésként jelenik meg, nem indítási hibaként. A daemon elindul, a kliensek csatlakoznak, és csak bizonyos célok viselkednek rosszul. Tartsd kicsin az alias tartományt, hogy a pool könnyen felismerhető legyen az útvonaltáblában. Soha ne vágd ki olyan alhálózatból, amelyet egy másik instance már használ.

Adj next hopot a visszaforgalomnak

A VPC-beli hoszt válasza a tunnel poolban lévő klienscímre van címezve, amely nem tartozik egyetlen VPC által ismert alhálózathoz sem. Ha nincs útvonal ehhez a poolhoz, a válasz az első egyezés nélküli hopnál megáll, a kérés pedig simán sikerülhetett a túlsó végén.

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

Ugyanez az útvonal kell minden olyan prefixhez, amely egy kliens mögött van, nem a VPC-n belül. Ezeknek a prefixeknek iroute bejegyzésre is szükségük van az adott kliens ccd fájljában. Az a bejegyzés szerveroldali könyvelés: megmondja a szervernek, melyik kliens birtokolja a prefixet, és semmit nem telepít magára a kliensre.

Tartsd a push listát a beszélgetés kliens oldalának, mert csak útvonalakat ad hozzá a csatlakozó géphez. Egy VPC-alhálózathoz tartozó push sor és egy VPC-útvonal vissza a poolhoz ugyanazon ösvény két fele, és bármelyik fél egyedül olyan alagutat ad, amely kéréseket szállít, de válaszokat nem.

Tűzfalak, továbbítás és a köztes hopok

A VPC tűzfala a kicsomagolt csomagot értékeli, ezért az ingress szabálynak át kell engednie a tunnel poolt és minden olyan site prefixet, amely így éri el a VM-et. A default-deny hozzáállás itt csendben elbukik: a csomag a kicsomagolás után eldobódik, az OpenVPN naplója pedig egészséges munkamenetet mutat.

Minden olyan Linux hoszton, amely továbbít, nem pedig végpont, ellenőrizd, hogy a net.ipv4.ip_forward engedélyezve van-e. A birtoklási szabály ott is érvényes: egy gép, amely olyan alhálózatért továbbít, amellyel nem rendelkezik, éppúgy eldobja a csomagot, mint a VM. Olvasd el az értéket, mielőtt az alagutat okolnád.

Amikor pontosan egy prefix hibás

A részleges hiba a legkönnyebben olvasható eset, mert az ösvény minden más eleme már bizonyított. Kezdd az útvonallistával, olvasd el a prefixet lefedni hivatott bejegyzés cél-tartományát és next hopját, majd olvasd el az instance leírását, és hasonlítsd össze az alias tartományát a szerver által osztott poollal.

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

A hiányzó útvonal úgy jelenik meg, hogy nincs next hop a prefixhez, míg a hiányzó alias úgy, hogy a csomag az interfésznél eldobódik; a kliens felől a kettő hasonlónak látszik, abban a két kimenetben viszont teljesen különbözik. Ha mindkettő megvan, a maradék gyanúsított annak a kliensnek a ccd-iroute-ja, amelyik a prefixet igényli.

Írd fel a négy értéket az alagút mellé: alias tartomány, szerver pool, pusholt prefixek, VPC útvonalak. Az elavult alias minden pool-címet elront, az elavult útvonal egy irányt ront el, a hiányzó push elrejti a prefixet a kliens elől, a rossz iroute pedig a rossz peerhez küldi a prefixet. A következő embernek, aki alhálózatot ad hozzá, mind a négyre szüksége van egy helyen, és a jegyzet olcsóbb, mint az este.

Kapcsolódó cikkek