VPN-kliens IP a Kubernetesben: megőrizzük vagy SNAT-oljuk?

Valahol az alagút és a backend között az ügyfél címe vagy túléli, vagy helyettesítődik, és mindkét kimenet védhető. A választás a fogadó szolgáltatás tulajdonosáé, nem azé, aki a CNI-t telepítette. Ha az ügyfélenkénti jogosultság, a kvóták vagy az auditbejegyzések számítanak, a címnek minden ugrást túl kell élnie. Ha a megosztott hozzárendelés elfogadható, a forrás-NAT megszüntet egy útválasztási problémát, amelyet egyébként örökre gondozna.

Ahol az ügyfél címe valóban eltűnik

Egy távoli ügyfél csomagja belső forrással érkezik a VPN-podhoz az alagút tartományán belül, mondjuk 10.90.0.42-vel. Amikor a pod továbbítja ezt a csomagot egy ClusterIP vagy egy pod IP felé, három különböző mechanizmus írhatja át a forrást. A csomópont CNI-jének masquerade szabálya fedi a pod által a klaszter CIDR-jén kívülre küldött forgalmat. A kube-proxy conntrack bejegyzése a célcsomóponton magát a Service ugrást fedi. A kapcsolatot lezáró proxy egyáltalán nem továbbítja a csomagot, így a végén látott forrás a proxyhoz tartozik.

Mindegyik más rétegben él, ezért egyetlen Service-mező szinte soha nem javítja meg a teljes utat.

A VPN nyilvános Service-én a externalTrafficPolicy csak azt dönti el, mi történik a külső kapcsolattal: a Local a fogadó csomóponton tartja a távoli címet, míg a Cluster engedi, hogy a kube-proxy egy másik csomópontnak adja a csomagot, és ott maszkolja. Ez a beállítás szabályozza azt a listenert, amelyre az ügyfelei csatlakoznak. Semmit nem mond a visszafejtett csomagról, amelyet a VPN-folyamat ezután a klaszterbe irányít.

Három feltétel, amely eldönti a vitát

Ugyanazt a három kérdést teszem fel ugyanabban a sorrendben minden alkalommal, amikor ez felmerül, mert az első általában lezárja a vitát. A konkrét terhelésre válaszoljon, ne az egész klaszterre. Egy vállalaton belül két klaszter különböző válaszra juthat, és mindkettő helyes lehet.

Ha a backend igennel válaszol az első kérdésre és nemmel a másodikra, hálózati munkája van, nem manifestet kell szerkesztenie. Ha a harmadik sor proxyt mond, a cím soha nem élte volna túl, és ennek ellenkezőjét állítani egy hét csomagrögzítésbe kerül.

Mit követel a preserve mód a hálózattól

A forrás megőrzése azt jelenti, hogy a célcsomópontnak aktív VPN-gatewayen keresztül kell visszaküldenie a forgalmat a 10.90.0.42-re. A VPN-készlet nem klaszter-CIDR, ezért alapértelmezés szerint egyetlen CNI sem irányítja Ön helyett. Ön maga adja hozzá az útvonalat, majd gondoskodik arról, hogy a gateway végpontja, amelyre mutat, túléljen egy újraütemezést.

ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2

Ez a következő ugrás pod-cím, a pod-címek pedig mozognak. Irányítsa az útvonalat egy Service VIP-re vagy egy helyben maradó csomópontcímre, vagy fogadja el, hogy minden kilakoltatás után a gateway után fog szaladni. A fordított útvonal szűrése a másik csapda: a szigorú mód eldobja azokat a csomagokat, amelyek visszauta nem egyezik azzal az interfésszel, amelyen érkeztek, és ez pontosan a megőrzött VPN-folyam alakja.

A laza érvényesítés gyakran a különbség egy működő visszaút és a backend elhagyása után eltűnő válaszok között. A VPN-csomópont masquerade szabályainak is ki kell zárniuk az alagút tartományát, különben a továbbított csomag a pod címével lép ki, függetlenül az épített útvonaltól. Inkább a CNI saját konfigurációjában fejezze ki ezt a kizárást, mint hogy kézzel szerkessze az iptables-t, mert az ügynök újraindításkor átírja a láncait, és a kézzel írt szabálya pontosan a következő frissítésig él.

A NetworkPolicy hozzáférés-vezérlés, nem útválasztás. Egy szabályzat szigorítása soha nem állít helyre egy címet, amelyet a masquerade már helyettesített.

Mennyibe kerül a SNAT, és hogyan írjuk le

A klaszter felé irányuló forrás-NAT az olcsóbb tervezés, és nem hiba. A backend a VPN-pod vagy -csomópont címét látja, a naplók egyeznek, és nem kell visszautnak léteznie. Amit elveszít, az a képesség, hogy két ügyfelet megkülönböztessen a hálózati rétegen, ezért a kvótáknak, tilalmaknak és auditnyomoknak máshonnan kell jönniük.

Általában ez a máshonnan az alkalmazás: egy munkamenet-token, egy aláírt fejléc vagy egy PROXY protokoll-sor, amelyet az Ön által vezérelt proxy ír. Ezek csak akkor adnak a fogadónak megbízható identitást, ha a proxy az útvonalon van, és a fejlécet nem lehet az ügyfél oldaláról beállítani. A runbookban legyen egyértelmű, melyik érvényes, mert a következő mérnök azt fogja feltételezni, hogy a naplóban szereplő cím az ügyfél. Nem az, és egyetlen incidens elég ahhoz, hogy ez a feltételezés drága legyen.

A csere addig marad őszinte, amíg le van írva.

Ellenőrzések, amelyek elválasztják a működő utat a szerencséstől

Friss kapcsolattal teszteljen, ne gyorsítótárazottal, és mindkét irányban teszteljen. Több hiba csak azért tűnik szakaszosnak, mert az új folyamok az átírt utat veszik.

Rögzítse a tuple-t három ponton egy engedélyezett kérés során: közvetlenül a dekapszuláció után, a VPN-pod kimeneti interfészén és a backendon. Ha a forrás a második és a harmadik rögzítés között változik, az ok a pod alatt van. Ha a második előtt változik, maga a pod fordít.

Ezután törölje a VPN-podot, és ismételje meg a tesztet, miközben újraütemeződik. A kilakoltatáskor eltörő megőrzött út befejezetlen, és az a NAT-szabály is, amely már nem létező címhez van rögzítve. Végül küldjön egy kérést olyan forrásból, amelyről elutasítást vár, és erősítse meg, hogy az elutasítás szabályzatból, nem pedig hiányzó útvonalból ered.