Nawalan ng VPN access ang mga pod ng GKE pagkatapos ng 1.14: dalawang paraan para ayusin ang pinagmulan

Dumating ang isang upgrade, at nagsimulang tanggihan ng mga system sa kabilang dulo ng tunnel ang trapik ng pod na gumagana noong nakaraang linggo. Nakataas ang tunnel, hindi nagalaw ang mga patakaran ng firewall, at walang nag-edit ng patakaran ng peer. Ang nagbago ay hindi nakikita sa mga log ng cluster: ang source address na nakikita ng mga system na iyon ngayon. Ang agwat na iyon ang nagpapaliwanag ng pagkabigo na mukhang pagkaantala ng network at kumikilos na parang problema sa pahintulot.

May dalawang wastong sagot, at dinadala ka nila sa magkaibang lugar. Piliin ang kontrata ng pinagmulan bago mag-edit ng ConfigMap.

Ang default na patakaran na hindi na ini-install

Nag-install ang mga naunang release ng GKE ng patakarang masquerade na pumapalit sa mga pinagmulan ng pod ng address ng node tuwing nasa labas ng 10.0.0.0/8 ang destinasyon. Nakikita ng gateway ng VPN sa loob ng saklaw na iyon ang address ng pod, habang ang anumang mas malayo ay mukhang galing sa node. Nagtayo ang mga peer ng mga allowlist at return route sa paligid ng mga address ng node dahil iyon ang naobserbahan nila.

Tumigil ang mga susunod na release sa pag-install ng default na patakarang iyon. Dumarating na ngayon ang trapik ng pod sa gateway na may mga address ng pod, anuman ang destinasyon. Itinatapon ng peer na nagruruta lamang ng mga address ng node ang mga tugon, at walang panig na nagsusulat ng kapaki-pakinabang na log entry. Maaaring magtagumpay pa ang kahilingan sa dulong bahagi, at iyon ang dahilan kung bakit nakakalito sundan ang pagkabigong ito.

Walang sira sa kahulugan ng patay na component. Hindi lamang nagkakasundo ang dalawang panig kung aling pinagmulan ang lehitimo.

Piliin ang pinagmulan na dapat makita ng peer

Ang pagpapanatili ng mga address ng pod ang mas tumpak na kontrata. Nakikita ng malayong panig ang workload na gumawa ng trapik, nananatiling tapat ang mga log, at nagiging posible ang patakaran sa bawat pod. Ang halaga ay kailangang dalhin ng peer ang prefix ng pod.

Ang pagpapanatili ng mga address ng node ang mas murang kontrata. I-on muli ang masquerade para sa destinasyong iyon at patuloy na makikita ng peer ang address na pinagkakatiwalaan na niya.

Isang tanong ang nagpapasya sa pagitan nila: ano ang ginagawa ng peer sa pinagmulan? Kung naglo-log ito, naglalapat ng patakaran sa bawat pinagmulan, o nagpapatupad ng makitid na return routing, nabibigyang-katwiran ng mga address ng pod ang karagdagang configuration. Kung kailangan lamang nitong magpadala ng mga tugon, mas mura ang masquerade at wala itong hinihiling sa kabilang panig. Mapagtatanggol ang alinmang pagpipilian hangga't isinusulat ito ng dalawang team.

Ang ikatlong opsiyon ay karaniwang pagkakamali: masquerade sa lahat at mawala ang kakayahang iugnay ang trapik. Iwasan ito maliban kung talagang hindi kayang iruta ng peer ang anuman maliban sa mga address ng node.

Ituro ang nonMasqueradeCIDRs sa tunay na mga saklaw

Pinapatakbo ng GKE ang ip-masq-agent sa kube-system, at inililista ng ConfigMap nito ang mga destinasyong lumalaktaw sa masquerade. Upang mapanatili ang mga pinagmulan ng pod patungo sa tunnel, ang saklaw ng pod, subnet ng node, at lokal na prefix ay kabilang lahat sa listahang iyon.

Palitan ang mga halimbawang halaga ng mga saklaw mula sa sarili mong cluster. Huwag gawing mas malawak ang listahan kaysa sa hinihingi ng pangangailangan, dahil binabago ng bawat karagdagang entry ang nakikita ng ibang destinasyon. Ang tatlong entry sa ibaba ay kumakatawan sa network ng pod, subnet ng node, at prefix sa likod ng tunnel:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

Ang entry na 0.0.0.0/0 ay nagpapawalang-bisa ng masquerade para sa lahat ng destinasyon, na nagbabago sa hitsura ng mga walang kaugnayang workload sa mga panlabas na serbisyo at bihirang sinasadya. Binabasa muli ng agent ang configuration nito sa resyncInterval, kaya karaniwang hindi kailangan ang restart. Tiyakin na tumatakbo ang pod ng agent, pagkatapos buksan ang naka-mount na file sa loob nito. Ang pagbasa sa file na iyon ang nagpapatunay na nakarating ang pagbabago.

Ang daan ng tugon ang kabilang kalahati

Binabago ng masquerade ang pinagmulan ng kahilingan at wala nang iba. Anuman ang pinagmulang matanggap ng peer, kailangan pa rin nito ng rutang pabalik doon, at kailangan pa rin ng cluster ng rutang patungo sa peer.

Ang paghuli sa gateway ng VPN ay mabilis na naghihiwalay sa dalawang pagkabigo. Ang mga packet na dumarating na may mga address ng pod at hindi kailanman nakakakuha ng tugon ay nangangahulugang kulang ang peer ng ruta para sa prefix ng pod. Ang tugon na lumilitaw sa gateway ngunit hindi kailanman nakakarating sa cluster ay nangangahulugang kulang ang lokal na ruta. Isulat ang kontrata sa ticket sa alinmang paraan: aling pinagmulan ang nakikita ng peer, at aling prefix ang pinagbabalikan nito.

Suriin muli pagkatapos ng bawat upgrade

Nagbago na nang isang beses ang default na pag-uugali ng masquerade, at maaaring i-reset ng pagpapalit ng node pool ang networking ng cluster. Ituring ang kontrata ng pinagmulan bilang bagay na dapat i-verify, hindi dapat ipagpalagay.

Pagkatapos ng upgrade, magpadala ng isang kahilingan mula sa pod patungo sa lokal na serbisyo at basahin ang pinagmulang nilo-log ng peer. Ang nag-iisang obserbasyon na iyon ay humuhuli ng regression na masayang iuulat ng status page ng tunnel bilang malusog. Ang pag-uulit nito ay tumatagal ng isang minuto at nakakatipid ng isang gabi para sa susunod na tao.