VPN-asiakkaan IP Kubernetesissa: säilytetäänkö vai SNAT?

Jossain tunnelin ja backendin välissä asiakkaan osoite joko säilyy tai korvataan, ja molemmat lopputulokset ovat puolustettavissa. Valinta kuuluu vastaanottavan palvelun omistajalle, ei sille, joka asensi CNI:n. Kun asiakaskohtainen valtuutus, kiintiöt tai audit-tietueet merkitsevät, osoitteen on selvittävä jokaisesta hypystä. Kun jaettu kohdistus on hyväksyttävää, lähde-NAT poistaa reititysongelman, jota muuten ylläpitäisit ikuisesti.

Missä asiakkaan osoite oikeasti katoaa

Etäasiakkaan paketti saapuu VPN-podiin sisäisellä lähteellä tunnelin alueelta, sanotaan 10.90.0.42. Kun podi välittää paketin ClusterIP:tä tai podin IP:tä kohti, kolme eri mekanismia voi kirjoittaa lähteen uudelleen. Solmun CNI:n masquerade-sääntö kattaa liikenteen, jonka podi lähettää klusterin CIDR:n ulkopuolelle. kube-proxyn conntrack-merkintä kohdesolmussa kattaa itse Service-hypyn. Yhteyden päättävä proxy ei välitä pakettia lainkaan, joten lopulta näkemäsi lähde kuuluu proxylle.

Kukin elää eri kerroksessa, minkä vuoksi yksi Service-kenttä lähes koskaan korjaa koko polkua.

externalTrafficPolicy VPN:n julkisessa Servicessä päättää vain siitä, mitä ulommaiselle yhteydelle tapahtuu: Local pitää etäosoitteen vastaanottaneessa solmussa, kun taas Cluster antaa kube-proxyn luovuttaa paketti toiselle solmulle ja maskata sen siellä. Tämä asetus hallitsee kuuntelijaa, johon asiakkaasi yhdistävät. Se ei kerro mitään salatusta puretusta paketista, jonka VPN-prosessisi reitittää sen jälkeen klusteriin.

Kolme ehtoa, jotka ratkaisevat väittelyn

Esitän samat kolme kysymystä samassa järjestyksessä aina, kun tämä nousee esiin, koska ensimmäinen yleensä lopettaa keskustelun. Vastaa niihin kyseiselle työkuormalle, älä koko klusterille. Kaksi klusteria samassa yrityksessä voivat päätyä eri vastauksiin ja molemmat voivat olla oikeassa.

Jos backend vastaa kyllä ensimmäiseen kysymykseen ja ei toiseen, sinulla on verkkotyötä tehtävänä sen sijaan, että muokkaisit manifestia. Jos kolmas rivi sanoo proxy, osoite ei olisi koskaan säilynyt, ja muun väittäminen maksaa viikon pakettikaappauksia.

Mitä preserve-tila vaatii verkolta

Lähteen säilyttäminen tarkoittaa, että kohdesolmun on palautettava liikenne osoitteeseen 10.90.0.42 aktiivisen VPN-yhdyskäytävän kautta. VPN-allas ei ole klusterin CIDR, joten mikään CNI ei reititä sitä puolestasi oletuksena. Lisäät reitin itse ja varmistat sitten, että yhdyskäytävän päätepiste, johon se osoittaa, selviää uudelleenajoituksesta.

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

Seuraava hyppy on podin osoite, ja podien osoitteet liikkuvat. Kohdista reitti Service-VIP:iin tai solmun osoitteeseen, joka pysyy paikallaan, tai hyväksy, että jahtaat yhdyskäytävää jokaisen poiston jälkeen. Käänteisen polun suodatus on toinen ansa: tiukka tila pudottaa paketit, joiden paluupolku ei vastaa rajapintaa, jolta ne saapuivat, ja se on täsmälleen säilytetyn VPN-vuon muoto.

Löyhä validointi on usein ero toimivan paluupolun ja vastausten välillä, jotka katoavat backendista lähdettyään. VPN-solmun masquerade-sääntöjen on myös jätettävä tunnelin alue pois, muuten välitetty paketti lähtee podin osoitteella riippumatta siitä, minkä reitin rakensit. Ilmaise tämä poissulkeminen mieluummin CNI:n omassa kokoonpanossa kuin muokkaamalla iptablesia käsin, koska agentti kirjoittaa ketjunsa uudelleen uudelleenkäynnistyksessä ja käsin kirjoitettu sääntösi säilyy täsmälleen seuraavaan päivitykseen.

NetworkPolicy on pääsynvalvontaa, ei reititystä. Käytännön tiukentaminen ei koskaan palauta osoitetta, jonka masquerade on jo korvannut.

Mitä SNAT maksaa, ja miten se kirjataan

Lähde-NAT klusteria kohti on halvempi suunnittelu, eikä se ole virhe. Backend näkee VPN-podin tai solmun osoitteen, lokit täsmäävät ja paluureittiä ei tarvitse olla. Menetät kyvyn erottaa kaksi asiakasta verkkokerroksessa, joten kiintiöiden, kieltojen ja audit-jälkien on tultava muualta.

Yleensä se muualta on sovellus: istuntotunniste, allekirjoitettu otsake tai PROXY-protokollan rivi, jonka kirjoittaa hallitsemasi proxy. Ne antavat vastaanottajalle identiteetin, johon se voi luottaa vain, kun proxy on polulla eikä otsaketta voi asettaa asiakkaan puolelta. Ole runbookissa selvä siitä, kumpi pätee, koska seuraava insinööri olettaa, että lokin osoite on asiakas. Se ei ole, ja yksi tapaus riittää tekemään oletuksesta kalliin.

Vaihtokauppa pysyy rehellisenä niin kauan kuin se on kirjattu.

Tarkistukset, jotka erottavat toimivan polun onnekkaasta

Testaa tuoreella yhteydellä äläkä välimuistiin tallennetulla, ja testaa molempiin suuntiin. Useat viat näyttävät ajoittaisilta vain siksi, että uudet vuot kulkevat uudelleenkirjoitettua polkua.

Kaappaa tuple kolmessa kohdassa yhden valtuutetun pyynnön aikana: heti dekapsuloinnin jälkeen, VPN-podin lähtörajapinnalla ja backendissa. Jos lähde muuttuu toisen ja kolmannen kaappauksen välillä, syy on podin alavirrassa. Jos se muuttuu ennen toista, podi itse kääntää.

Poista sitten VPN-podi ja toista testi, kun se ajoitetaan uudelleen. Säilytetty polku, joka katkeaa poistossa, on kesken, ja niin on myös NAT-sääntö, joka on kiinnitetty osoitteeseen, jota ei enää ole. Lähetä lopuksi yksi pyyntö lähteestä, jonka odotat hylättävän, ja vahvista, että hylkäys tulee käytännöstä eikä puuttuvasta reitistä.