VPN-klant-IP yn Kubernetes: bewarje of SNAT?
Kies tusken it bewarjen fan it echte VPN-klantadres en boarne-NAT yn Kubernetes op grûn fan trije betingsten, en ferifiearje dêrnei it werompaad en pod-ferrin.
Earne tusken de tunnel en de backend oerlibbet in klantadres of wurdt it ferfongen, en beide útkomsten binne ferdigenber. De kar heart ta de eigner fan 'e ûntfangende tsjinst, net ta dy't de CNI ynstallearre hat. Wannear't autorisaasje per klant, kwota's of auditspoaren der ta dogge, moat it adres elke hop oerlibje. Wannear't dielde taskriuwung akseptabel is, ferwideret boarne-NAT in routingprobleem datst oars foar altyd ûnderhâlde soest.
Wêr't it klantadres echt ferdwynt
It pakket fan in fiere klant komt by de VPN-pod oan mei in ynterne boarne binnen it tunnelberik, sis 10.90.0.42. Wannear't de pod dat pakket trochstjoert nei in ClusterIP of in pod-IP, kinne trije ferskillende meganismen de boarne werskriuwe. De masquerade-regel fan 'e CNI op 'e node dekt ferkear dat de pod bûten de cluster-CIDR stjoert. De conntrack-yngong fan kube-proxy op 'e doelnode dekt de Service-hop sels. In proxy dy't de ferbining beëiniget, stjoert it pakket hielendal net troch, dus de boarne dy'tsto úteinlik sjochst is fan 'e proxy.
Elk libbet yn in oare laach, en dêrom reparearret ien Service-fjild hast nea it hiele paad.
externalTrafficPolicy op 'e iepenbiere Service fan 'e VPN beslút allinnich wat der mei de bûtenste ferbining bart: Local hâldt it fiere adres op 'e node dy't it ûntfong, wylst Cluster kube-proxy tastiet it pakket oan in oare node te jaan en it dêr te masqueraden. Dy ynstelling regelet de listener dêr't dyn klanten op ynbelje. Se seit neat oer it ûntsifere pakket dat dyn VPN-proses dêrnei de cluster yn routearret.
Trije betingsten dy't de diskusje besljochtsje
Ik stel deselde trije fragen yn deselde folchoarder elke kear as dit opkomt, om't de earste de diskusje meastentiids einiget. Beäntwurdzje se foar de spesifike workload en net foar de cluster as gehiel. Twa clusters binnen ien bedriuw kinne op ferskillende antwurden útkomme en beide gelyk hawwe.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
As de backend ja antwurdet op 'e earste fraach en nee op 'e twadde, hasto netwurkwurk te dwaan ynstee fan in manifest te bewurkjen. As de tredde rige proxy seit, soe it adres nea oerlibbe hawwe, en dwaan as wie dat oars kostet in wike pakketfangers.
Wat preserve-modus fan it netwurk freget
De boarne bewarje betsjut dat de doelnode ferkear nei 10.90.0.42 weromstjoere moat fia in aktive VPN-gateway. De VPN-pool is gjin cluster-CIDR, dus gjin CNI routearret dy standert foar dy. Do heakest de rûte sels ta en soargest der dan foar dat it gateway-einpunt dêr't se nei wiist in werplanning oerlibbet.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Dy folgjende hop is in pod-adres, en pod-adressen ferpleatse har. Rjochtsje de rûte op in Service-VIP of in node-adres dat stean bliuwt, of akseptearje datsto nei elke eviction de gateway efternei sittest. Reverse path filtering is de oare falstrik: strikte modus lit pakketten falle waans werompaad net oerienkomt mei de interface dêr't se op oankamen, en dat is krekt de foarm fan in bewarre VPN-flow.
Losse falidaasje is faak it ferskil tusken in wurkjend werompaad en antwurden dy't ferdwine nei't se de backend ferlitten hawwe. Masquerade-regels op 'e VPN-node moatte ek it tunnelberik útslute, oars ferlit it trochstjoerde pakket mei it adres fan 'e pod, hokker rûte do ek boud hast. Drukt dy útsluting leaver út yn 'e konfiguraasje fan 'e CNI sels ynstee fan iptables mei de hân te bewurkjen, want de agent skriuwt syn keatlingen by in werstart opnij en dyn hânskreaune regel oerlibbet krekt oant de folgjende upgrade.
NetworkPolicy is tagongskontrôle, gjin routing. In belied ferskerpje sil nea in adres werstelle dat masquerade al ferfongen hat.
Wat SNAT kostet, en hoe't do it opskriuwst
Boarne-NAT nei de cluster is it goedkeapere ûntwerp, en it is gjin flater. De backend sjocht it adres fan 'e VPN-pod of node, logs komme mei elkoar oerien, en der hoecht gjin weromrûte te bestean. Watsto ferliest is it fermogen om twa klanten op netwurknivo te ûnderskieden, dus kwota's, bans en auditspoaren moatte earne oars wei komme.
Meastentiids is dat earne oars de applikaasje: in sesjetoken, in ûndertekene header of in PROXY-protokolrige skreaun troch in proxy dy'tsto behearst. Dy jouwe de ûntfanger in identiteit dy't er allinnich fertrouwe kin as de proxy yn it paad sit en de header net fan 'e klantkant ôf set wurde kin. Wêz eksplisyt yn 'e runbook hokker jildt, want de folgjende yngenieur sil oannimme dat it adres yn 'e log de klant is. Dat is it net, en ien ynsidint is genôch om dy oanname djoer te meitsjen.
De ruil bliuwt earlik salang't er opskreaun is.
Kontrôles dy't in wurkjend paad fan in gelokkich paad skiede
Test mei in farske ferbining ynstee fan in cachede, en test yn beide rjochtingen. Ferskate flaters lykje allinnich ûnregelmjittich om't nije flows it werskreaune paad nimme.
Fang de tuple op trije punten yn ien autorisearre fersyk: fuort nei dekapsulaasje, op 'e egress-interface fan 'e VPN-pod en op 'e backend. As de boarne feroaret tusken de twadde en tredde fangst, sit de oarsaak streamôf fan 'e pod. As er feroaret foar de twadde, oerset de pod sels.
Ferwiderje dan de VPN-pod en werhelje de test wylst er werplend wurdt. In bewarre paad dat by eviction brekt is ûnfoltôge, en dat jildt ek foar in NAT-regel dy't fêst sit oan in adres dat net mear bestiet. Stjoer ta slot ien fersyk fan in boarne dy'tsto ferwachtest dat wegere wurdt en befêstigje dat de wegering fan belied komt en net fan in ûntbrekkende rûte.