Pam na all podiau GKE gyrraedd gwesteiwyr ar-safle dros VPN

Mae ping yn gweithio o'r nod ac yn methu o'r pod, ac nid oes dim yn cyrraedd ar-safle. Mae'r twnnel a'r llwybr yn iawn; nid yw'r cyfeiriad ffynhonnell ar y wifren. Yr hyn sy'n wahanol rhwng y ddau achos hyn yw'r hyn y mae'r pecyn yn honni ei fod pan fydd yn gadael y clwstwr, ac mae gan GKE farn am hynny. Y mecanism yw rhestr eithrio masquerade, ac mae ei darllen yn cymryd un gorchymyn.

Darllenwch y rhestr effeithiol cyn newid unrhyw beth

Mae GKE yn cludo asiant sy'n penderfynu, fesul ystod cyrchfan, a yw traffig pod yn cael ei ailysgrifennu i gyfeiriad y nod ar y ffordd allan. Mae ei ffurfweddiad cludo yn enwi'r tri bloc RFC1918, 10.0.0.0/8, 172.16.0.0/12 a 192.168.0.0/16, fel cyrchfannau sydd wedi'u heithrio. Felly mae unrhyw beth a anfonwch o bod i westai 10.x ar-safle yn gadael y nod gyda chyfeiriad y pod ei hun yn dal ynghlwm. Nid yw traffig y nod ei hun yn cael ei ailysgrifennu, a dyna'n union pam mae ei ping yn gweithio.

Darllenwch y ffurfweddiad arfaethedig a'r rheolau sydd wedi'u gosod, oherwydd gallant anghytuno. Mae kubectl -n kube-system get configmap ip-masq-agent -o yaml yn dangos beth ddywedwyd wrth yr asiant, ac mae kubectl -n kube-system get pods -l k8s-app=ip-masq-agent yn dangos a oes unrhyw beth yn rhedeg i'w gymhwyso. Ar nod, mae iptables-save | grep -i masq yn dangos y rheolau sy'n bodoli mewn gwirionedd yn y cnewyllyn. Pan fydd y ConfigMap yn dweud un peth a'r rheolau'n dweud peth arall, yr asiant yw'r sawl a ddrwgdybir yn hytrach na'r rhwydwaith.

Cadarnhewch y cyfeiriad ffynhonnell gyda chipiad

Cipiwch cyn i chi newid rhestr. Mae hidlydd ar yr un gyrchfan yn cadw'r allbwn yn ddarllenadwy: tcpdump -ni any host 10.20.30.40.

Cymharwch hynny â'r hyn y mae'r ochr bell yn ei adrodd. Mae cipiad ar-safle sy'n dangos cyfeiriad y pod a dim ateb yn cau'r cylch: mae'r rhestr eithrio yn esbonio'r anghymesuredd heb unrhyw fai ar y twnnel. Mae dau arsylwad o un cyfeiriad ffynhonnell yn ddigon i roi'r gorau i ddyfalu am y CNI.

Culhewch yr eithriad i CIDR y pod

Mae'r atgyweiriad a gefnogir yn culhau'r eithriad yn hytrach na'i ddileu: cadwch CIDR y pod wedi'i eithrio a gollwng gweddill gofod 10.x. Mae'r rhestr honno'n byw yn ConfigMap yr asiant o dan nonMasqueradeCIDRs, ac mae ei newid yn olygiad ac yna'n gyflwyniad. Disodlwch y cofnod eang â gwir ystod pod y clwstwr, cadwch y blociau preifat eraill os oes angen traffig o fewn y clwstwr o hyd, a gadewch resyncInterval yn llonydd oni bai bod gennych reswm. Cymhwyswch ef, cadarnhewch fod podiau'r asiant wedi ailgychwyn, a chadarnhewch fod rheolau'r cnewyllyn wedi newid.

Mae hwn yn newid ar draws y clwstwr cyfan ag ystod effaith go iawn. Ar ôl iddo lanio, mae traffig a oedd yn cadw ei ffynhonnell pod bellach yn cyrraedd wedi'i ailysgrifennu i'r nod, felly mae unrhyw beth a oedd wedi'i allweddu ar y cyfeiriadau pod hynny'n gweld anfonwr gwahanol. Y dioddefwyr yw logiau, rhestrau caniatáu a rheolau wal dân ar-safle sy'n enwi cyfeiriadau pod, ac maent yn methu'n dawel. Cyhoeddwch y newid fel newid ymddygiad yn hytrach na chywiad.

Ar glwstwr â sawl pwll nod, gwiriwch fod yr asiant wedi'i drefnu ar y nodau lle mae'r podiau yr effeithiwyd arnynt yn rhedeg mewn gwirionedd. Mae pwll heb y DaemonSet yn cadw ei hen reolau, ac ni fydd dim yn y ConfigMap yn dangos hynny.

Y dewis arall a'i gost

Mae'r opsiwn arall yn cadw cyfeiriadau pod yn gyfan ac yn dysgu'r llwybr amdanynt. Mae CIDR y pod yn mynd i ddetholwyr traffig Cloud VPN, ac mae ar yr ochr ar-safle angen llwybr dychwelyd ar ei gyfer fel bod atebion yn gwybod i ble i fynd. Mae hynny'n cadw hunaniaeth y pod, y mae rhai modelau diogelwch yn ei dymuno, ac mae'n ehangu cwmpas y llwybrau a chwmpas y wal dân y mae'n rhaid i'r ochr bell ei dderbyn.

Y fasnach yw darllenadwyedd yn erbyn cwmpas. Mae cyfieithu yn gwneud i'r ochr ar-safle weld un cyfeiriad fesul nod, sy'n hawdd i'w roi ar restr caniatáu ac yn cuddio pa bod a anfonodd beth. Mae peidio â chyfieithu yn cadw cyfeiriad y pod o'r dechrau i'r diwedd, sy'n well ar gyfer priodoli ac yn waeth i bob dyfais yn y llwybr sy'n gorfod dysgu ystod newydd. Nid yw'r un opsiwn yn ddiffyg Docker na CNI; mae'r ddau yn benderfyniadau llwybrau â bil gweithredol. Dewiswch yr un y gall eich tîm dalu ei fil, ac ysgrifennwch pam.

Gwiriwch a rholiwch yn ôl

Rhedwch yr un cipiad eto. Mae cipiad ar lefel nod sy'n dal i argraffu cyfeiriad y pod ar ôl eich golygiad yn golygu na newidiodd y rheolau erioed, beth bynnag y mae'r ConfigMap yn ei ddweud. Y wifren yw'r ffaith; popeth arall yw casgliad.

Yna gwiriwch y cyfeiriad gwrthdro, oherwydd dim ond allan y mae hanner y newidiadau hyn yn cael eu gwirio. Cadarnhewch fod yr ateb yn cyrraedd y nod neu'r pod a anfonodd y cais, a chadarnhewch fod y rhaglen wedi gorffen yn hytrach na dim ond derbyn SYN. Mae cipiad sy'n dangos cais heb ateb yn broblem llwybro ar yr ochr bell, nid yn broblem masquerade ar yr ochr hon.

Rholio yn ôl yw'r ConfigMap blaenorol, wedi'i gymhwyso'r un ffordd, gyda'r un cadarnhad fod yr asiant wedi ailgychwyn a'r rheolau wedi newid. Cadwch y cyfeiriad ffynhonnell cyn ac ar ôl ar gyfer un cais hysbys yn y cofnod newid, gan mai'r un llinell honno sy'n profi bod y newid wedi gwneud yr hyn a ddywedasoch. Mae canllaw asiant masquerade IP GKE yn dogfennu'r rhagosodiadau a meysydd y ConfigMap. Os yw'r cyfeiriad ffynhonnell yn ddigyfnewid ar ôl y cyflwyniad, nid yw'r asiant yn rhedeg ar y nod hwnnw ac ni fydd unrhyw olygu YAML yn ei drwsio.