înregistrare Logare
Puncte:1
avatar Server

Timeouts pe Cloud SQL și alte servicii externe atunci când utilizați NAT + IP Masquerade pe GKE

drapel it
rsan

Trebuie să configurez un IP static într-unul dintre POD-urile mele, deoarece un serviciu de la distanță (în afara clusterului meu) necesită o listă albă de IP de încredere.

Am urmat documentația oferită de Google:

https://cloud.google.com/nat/docs/overview?hl=es-419

https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent

Dar când încerc să configurez traficul de ieșire folosind serviciul Google cloud NAT în clusterul meu GKE plus masquerading folosind ip-masq-agent Încep să am timeout-uri și probleme când accesez servicii de la distanță în afara clusterului.

Clusterul meu este în versiune 1.19.10-gke.1600.

Am încercat aceste fișiere de configurare cu următoarele rezultate:

Interval de resincronizare: 60s

Rezultat:

Lanț IP-MASQ (2 referințe)
target prot opt ​​sursă destinație         
RETURN all -- oriunde 10.0.0.0/8 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 172.16.0.0/12 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 192.168.0.0/16 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
MASQUERADE all -- oriunde oriunde /* ip-masq-agent: traficul de ieșire este sub
ject to MASQUERADE (trebuie să fie ultimul din lanț) */

Serviciile continuă să folosească IP greșit.

Interval de resincronizare: 60s
masqLinkLocal: adevărat

Lanț IP-MASQ (2 referințe)
target prot opt ​​sursă destinație         
RETURN all -- oriunde 169.254.0.0/16 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 10.0.0.0/8 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 172.16.0.0/12 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 192.168.0.0/16 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
MASQUERADE all -- oriunde oriunde /* ip-masq-agent: traficul de ieșire este sub
ject to MASQUERADE (trebuie să fie ultimul din lanț) */

Același efect, serviciile mele externe obțin IP greșit.

nonMasqueradeCIDRs:
  - 0.0.0.0/0
Interval de resincronizare: 60s
masqLinkLocal: adevărat

Lanț IP-MASQ (2 referințe)
target prot opt ​​sursă destinație         
RETURN all -- oriunde oriunde /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
MASQUERADE all -- oriunde oriunde /* ip-masq-agent: traficul de ieșire este sub
ject to MASQUERADE (trebuie să fie ultimul din lanț) */

Se pare că acest lucru funcționează mai bine deoarece serviciile externe primesc IP-ul corect, dar am probleme de conexiune și timeout-uri.

Aceasta este configurația mea NAT:

Cartografierea NAT
- Disponibilitate ridicată: Da
- Subrețele sursă și intervale IP: intervalele IP primare și secundare ale tuturor subrețelelor
- Adrese IP NAT: static-egress-ip XXX.XXX.XXX.XXX

Am ramas fara idei, imi poate da cineva un sfat?

După ce răspunsul a ajuns aici, mi-am actualizat fișierul de configurare pentru a adăuga ips-ul după documentația Google Cloud, fișierul merge astfel:

nonMasqueradeCIDRs:
  - 10.0.0.0/8
  - 172.16.0.0/12
  - 192.168.0.0/16
  - 100.64.0.0/10
  - 192.0.0.0/24
  - 192.0.2.0/24
  - 192.88.99.0/24
  - 198.18.0.0/15
  - 198.51.100.0/24
  - 203.0.113.0/24
  - 240.0.0.0/4
Interval de resincronizare: 60s
masqLinkLocal: adevărat

Rezultatul acestui lucru în iptables este:

Lanț IP-MASQ (2 referințe)
target prot opt ​​sursă destinație         
RETURN all -- oriunde 10.0.0.0/8 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 172.16.0.0/12 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 192.168.0.0/16 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 100.64.0.0/10 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 192.0.0.0/24 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 192.0.2.0/24 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 192.88.99.0/24 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 198.18.0.0/15 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 198.51.100.0/24 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 203.0.113.0/24 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
RETURN all -- oriunde 240.0.0.0/4 /* ip-masq-agent: traficul local nu este sub
ject to MASQUERADE */
MASQUERADE all -- oriunde oriunde /* ip-masq-agent: traficul de ieșire este sub
ject to MASQUERADE (trebuie să fie ultimul din lanț) */

Dar dacă trec o buclă checkip.amazonaws.com pentru a vedea ce IP este folosit de nod, primesc un IP diferit de cel definit în configurația mea NAT Cloud și serviciile externe resping cererea ca nefiind de încredere din clusterul meu.

312
2 + 0
Puncte:1
Anbu Thirugnana Sekar avatar Server
drapel gh
Anbu Thirugnana Sekar

Se pare că ai setat nonMasqueradeCIDRs: ca 0.0.0.0/0, prevenind astfel Masquerading-ul întregului trafic CIDR, deci pentru a remedia această problemă, în fișierul de configurare actualizați cheia nonMasqueradeCIDRs: cu IP-urile menționate în paragraful [1] de destinație implicită non-masquerade, așa cum este prezentat mai jos.

nonMasqueradeCIDRs:

  • 172.16.0.0/12
  • 192.168.0.0/16
  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4
  • 10.0.0.0/8

De asemenea, vă rugăm să rețineți că IP-urile menționate în captură de ecran nu erau IP-uri greșite, dar acestea sunt intervale rezervate de RFC 1918/link-local, adică IP-urile 10.0.0.0/8, 172.16.0.0/12 192.168.0.0/16 sunt rezervate pentru RFC 1918, iar intervalul IP 169.254.0.0/16 este rezervat pentru link-local și acestea nu pot fi mascate și, prin urmare, aceste IP-uri sunt afișate cu descrierea âip-masq-agent: traficul local nu este supus mascariiâ [2].

[1] https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent#default-non-masq-dests

[2] https://kubernetes.io/docs/tasks/administer-cluster/ip-masq-agent/#ip-masquerade-agent-user-guide

Salutari, Anbu.

0 + 1
drapel it
rsan
Bună @Anbu, mulțumesc mult pentru ajutor. Am urmat instrucțiunile tale și în loc să folosesc 0.0.0.0/0 ca masq am pus intervalele definite în documentație. Puteți vedea edițiile făcute la întrebarea mea pentru a vedea rezultatul comenzilor, dar încă am problema că nodurile și podurile mele apelează serviciile externe folosind un IP pe care nu îl controlez. IP-ul fix NAT pe care l-am configurat în GOOGLE CLOUD NAT este ignorat. Testez acest lucru cu un curl direct de la nodul ssh sau apelând serviciile mele externe care returnează IP nepermis. Vreo idee?
0
Răspunde
Puncte:0
avatar Server
drapel it
rsan

În sfârșit am reușit să diagnosticăm problema. Clusterul nostru a fost creat cu ceva timp în urmă, când GCP nu accepta clustere private, așa că clusterul nostru este public.

Fiecare nod are un IP public efemer, astfel încât regulile NAT sunt ignorate.

Soluția a fost setarea unui nod cu o IP statică și nu efemeră și configurarea sarcinii de lucru care necesită o autorizare de încredere pentru a se implementa întotdeauna pe acel nod specific. Aceasta nu este o soluție perfectă, dar este ceea ce putem face rapid pentru a rezolva problema.

Soluția reală ar fi migrarea către un cluster privat și configurarea NAT, dar, din păcate, GCP nu acceptă migrarea de la un cluster public la unul privat. Singura opțiune ar fi crearea unui nou cluster și migrarea sarcinilor de lucru către noul cluster, proces pe care va trebui să-l executăm pe termen scurt.

Poate că este un moment bun pentru a testa pilotul automat, care nu acceptă nici migrarea automată.

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.