IP vafranna VPN-viðskiptavinar í Kubernetes: varðveita eða SNAT?
Veldu milli þess að varðveita raunverulegt VPN-viðskiptavinarheitið og uppruna-NAT í Kubernetes með þremur skilyrðum, og staðfestu síðan endurkomuleiðina og pod-vakninguna.
Einhvers staðar milli göngunnar og bakendans lifir heiti viðskiptavinar annaðhvort af eða er skipt út, og bæði útkoman er verjanleg. Valið tilheyrir eiganda móttökuljónustunnar, ekki þeim sem setti upp CNI-ið. Þegar heimildir á hvern viðskiptavin, kvótar eða endurskoðunarskrár skipta máli verður heitið að lifa af hverja hopp. Þegar sameiginleg eignfærsla er ásættanleg fjarlægir uppruna-NAT leiðarvaldsvandamál sem þú myndir annars viðhalda að eilífu.
Hvar heiti viðskiptavinarins hverfur í raun
Pakki fjartengds viðskiptavinar berst að VPN-pod með innri uppruna innan göngusviðsins, segjum 10.90.0.42. Þegar pod-ið sendir þann pakka áfram í átt að ClusterIP eða pod-IP geta þrjú mismunandi kerfi endurskrifað upprunann. Masquerade-regla CNI-sins á hnútnum nær yfir umferð sem pod-ið sendir út fyrir CIDR klasans. conntrack-færsla kube-proxy á áfangahnútnum nær yfir sjálfa Service-hoppið. Proxy sem lýkur tengingunni sendir pakkann alls ekki áfram, svo uppruninn sem þú sérð að lokum tilheyrir proxyinu.
Hvert þeirra býr í öðru lagi, og þess vegna lagar eitt Service-svið næstum aldrei alla leiðina.
externalTrafficPolicy á opinbera Service VPN-sins ræður aðeins því sem verður um ytri tenginguna: Local heldur fjarheitinu á hnútnum sem tók á móti því, en Cluster leyfir kube-proxy að afhenda pakkann öðrum hnút og masquerade hann þar. Þessi stilling stjórnar hlustandanum sem viðskiptavinir þínir hringja í. Hún segir ekkert um afkóðaða pakkann sem VPN-ferlið þitt leiðir síðan inn í klasann.
Þrjú skilyrði sem útkljá deiluna
Ég spyr sömu þriggja spurninga í sömu röð í hvert sinn sem þetta kemur upp, því sú fyrsta endar venjulega umræðuna. Svaraðu þeim fyrir tiltekna vinnuálagið en ekki klasann í heild. Tveir klasar innan sama fyrirtækis geta komist að ólíkum svörum og báðir verið réttir.
| 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 |
Ef bakendinn svarar já við fyrstu spurningunni og nei við þeirri annarri hefur þú netvinnu að gera í stað þess að breyta manifesti. Ef þriðja röðin segir proxy hefði heitið aldrei lifað af, og að þykjast öðruvísi kostar viku af pakkaskráningum.
Hvað preserve-stilling krefst af netinu
Að varðveita upprunann þýðir að áfangahnúturinn verður að senda umferð til baka á 10.90.0.42 gegnum virka VPN-gátt. VPN-laugin er ekki CIDR klans, svo ekkert CNI leiðar það fyrir þig sjálfgefið. Þú bætir við leiðinni sjálfur og gætir þess síðan að endapunktur gáttarinnar sem hún bendir á lifi af enduráætlun.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Næsta hopp er pod-heiti, og pod-heiti flytjast. Beindu leiðinni að Service-VIP eða hnútheiti sem stendur kyrrt, eða samþykktu að þú eltir gáttina eftir hverja úthýsingu. Öfug leiðarsíun er hin gildran: ströng stilling sleppir pökkum sem hafa endurkomuleið sem passar ekki við viðmótið sem þeir komu á, og það er nákvæmlega lögun varðveitts VPN-flæðis.
Slök staðfesting er oft munurinn á virkri endurkomuleið og svörum sem hverfa eftir að hafa yfirgefið bakendann. Masquerade-reglur á VPN-hnútnum verða líka að útiloka göngusviðið, annars fer framsendi pakkinn út með heiti podsins, sama hvaða leið þú byggðir. Lýstu þeirri útilokun frekar í stillingum CNI-sins sjálfs en að breyta iptables fyrir hönd, því umboðið endurskrifar keðjur sínar við endurræsingu og handskrifaða reglan þín lifir nákvæmlega til næstu uppfærslu.
NetworkPolicy er aðgangsstýring, ekki leiðarval. Herðing stefnu mun aldrei endurheimta heiti sem masquerade hefur þegar skipt út.
Hvað SNAT kostar, og hvernig á að skrifa það niður
Uppruna-NAT inn í klasann er ódýrari hönnunin, og það er ekki mistök. Bakendinn sér heiti VPN-podsins eða hnútsins, skrár stemma saman og engin endurkomuleið þarf að vera til. Það sem þú tapar er hæfileikinn til að greina tvo viðskiptavini á netlaginu, svo kvótar, bönn og endurskoðunarslóðir verða að koma annars staðar frá.
Venjulega er það annars staðar forritið: setutákn, undirrituð haus eða PROXY-samskiptareglulína sem proxy sem þú stýrir skrifar. Þau gefa móttakandanum auðkenni sem hann getur aðeins treyst þegar proxyið er á leiðinni og ekki er hægt að setja hausinn frá viðskiptavinahlið. Vertu skýr í runbooknum um hvort á við, því næsti verkfræðingur mun gera ráð fyrir að heitið í skránni sé viðskiptavinurinn. Það er það ekki, og einn atburður nægir til að gera þá forsendu dýra.
Skiptin haldast heiðarleg svo lengi sem þau eru skrifuð niður.
Athuganir sem aðskilja virka leið frá heppinni
Prófaðu með nýrri tengingu frekar en skyndiminni, og prófaðu í báðar áttir. Nokkrir gallar virðast slitróttir aðeins vegna þess að ný flæði fara endurskrifuðu leiðina.
Gríptu tuple á þremur stöðum meðan á einni heimilaðri beiðni stendur: strax eftir afkóðun, á útviðmóti VPN-podsins og á bakendanum. Ef uppruninn breytist milli annarrar og þriðju grípu liggur orsökin neðan við podið. Ef hann breytist fyrir hina aðra þýðir podið sjálft.
Eyðtu síðan VPN-podinu og endurtaktu prófið meðan það er enduráætlað. Varðveitt leið sem brotnar við úthýsingu er ókláruð, og það sama gildir um NAT-reglu sem er fest við heiti sem er ekki lengur til. Að lokum sendu eina beiðni frá uppruna sem þú býst við að verði hafnað og staðfestu að höfnunin komi frá stefnu en ekki frá leið sem vantar.