Zašto GKE podovi preko VPN-a ne mogu dosegnuti lokalne servere

Ping radi s čvora i ne uspijeva s poda, a lokalno ne stiže ništa. Tunel i ruta su u redu; izvorna adresa na žici nije. Ono što se razlikuje između ta dva slučaja jeste šta paket tvrdi da je kada napusti klaster, a GKE o tome ima mišljenje. Mehanizam je lista masquerade izuzetaka, a njeno čitanje traži jednu naredbu.

Pročitajte važeću listu prije nego što bilo šta promijenite

GKE isporučuje agenta koji po odredišnom rasponu odlučuje hoće li se pod promet pri izlasku prepisati na adresu čvora. Njegova isporučena konfiguracija navodi tri RFC1918 bloka, 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16, kao odredišta koja su izuzeta. Zato sve što pošaljete s poda na lokalni 10.x host napušta čvor s još prikačenom vlastitom adresom poda. Promet samog čvora se ne prepisuje, i upravo zato njegov ping radi.

Pročitajte namjeravanu konfiguraciju i instalirana pravila, jer se mogu ne slagati. kubectl -n kube-system get configmap ip-masq-agent -o yaml pokazuje šta je agentu rečeno, a kubectl -n kube-system get pods -l k8s-app=ip-masq-agent pokazuje da li nešto radi da to primijeni. Na čvoru iptables-save | grep -i masq pokazuje pravila koja stvarno postoje u kernelu. Kada ConfigMap kaže jedno a pravila drugo, osumnjičeni je agent, a ne mreža.

Potvrdite izvornu adresu snimkom

Snimite prije nego što promijenite listu. Filter na jedno odredište drži izlaz čitljivim: tcpdump -ni any host 10.20.30.40.

Uporedite to s onim što prijavljuje suprotna strana. Snimak lokalno koji pokazuje adresu poda i nikakav odgovor zatvara krug: lista izuzetaka objašnjava asimetriju bez ikakvog kvara tunela. Dva zapažanja jedne izvorne adrese dovoljna su da prestanete nagađati o CNI-ju.

Suzite izuzetak na pod CIDR

Podržani popravak sužava izuzeće umjesto da ga ukloni: zadržite pod CIDR izuzetim i ispustite ostatak 10.x prostora. Ta lista živi u agentovom ConfigMapu pod nonMasqueradeCIDRs, a njeno mijenjanje je izmjena nakon koje slijedi uvođenje. Zamijenite široki unos stvarnim rasponom podova klastera, zadržite ostale privatne blokove ako je promet unutar klastera još potreban, i ostavite resyncInterval na miru osim ako imate razlog. Primijenite to, potvrdite da su se agentovi podovi ponovo pokrenuli i potvrdite da su se kernel pravila promijenila.

Ovo je promjena na nivou cijelog klastera sa stvarnim radijusom djelovanja. Nakon što prođe, promet koji je prije zadržavao svoj pod izvor sada stiže prepisan na čvor, pa sve što je bilo vezano za te adrese podova vidi drugog pošiljaoca. Žrtve su logovi, liste dozvola i lokalna firewall pravila koja imenuju adrese podova, i ona tiho padaju. Najavite promjenu kao promjenu ponašanja, a ne kao popravak.

Na klasteru s nekoliko grupa čvorova provjerite je li agent zakazan na čvorovima na kojima pogođeni podovi stvarno rade. Grupa bez DaemonSet-a zadržava svoja stara pravila, a ništa u ConfigMapu to neće pokazati.

Alternativa i njena cijena

Druga opcija čuva adrese podova netaknutim i uči put o njima. Pod CIDR ide u Cloud VPN birače prometa, a lokalna strana treba povratnu rutu za njega da bi odgovori znali kuda ići. To čuva identitet poda, koji neki sigurnosni modeli žele, i širi i usmjeravanje i firewall obim koji suprotna strana mora prihvatiti.

Trgovina je čitljivost protiv obima. Prevođenje čini da lokalna strana vidi jednu adresu po čvoru, što je lako staviti na listu dozvola i krije koji je pod šta poslao. Bez prevođenja adresa poda ostaje od kraja do kraja, što je bolje za pripisivanje a gore za svaki uređaj na putu koji mora naučiti novi raspon. Nijedna opcija nije Docker ili CNI defekt; obje su odluke o usmjeravanju s operativnim računom. Odaberite onu čiji račun vaš tim može platiti i zapišite zašto.

Provjerite i vratite

Pokrenite isti snimak ponovo. Snimak na nivou čvora koji i nakon vaše izmjene ispisuje adresu poda znači da se pravila nikada nisu promijenila, šta god ConfigMap govorio. Žica je činjenica; sve ostalo je zaključivanje.

Zatim provjerite obrnuti smjer, jer se polovina ovih promjena provjerava samo prema van. Potvrdite da odgovor stiže do čvora ili poda koji je poslao zahtjev i potvrdite da je aplikacija završila, a ne samo primila SYN. Snimak koji pokazuje zahtjev bez odgovora je problem usmjeravanja na suprotnoj strani, ne masquerade problem na ovoj.

Vraćanje je prethodni ConfigMap, primijenjen na isti način, uz istu potvrdu da se agent ponovo pokrenuo i da su se pravila promijenila. Zadržite izvornu adresu prije i poslije za jedan poznati zahtjev u zapisu promjene, jer ta jedna linija dokazuje da je promjena učinila ono što ste rekli. GKE vodič za IP masquerade agenta dokumentuje zadane vrijednosti i polja ConfigMapa. Ako izvorna adresa nakon uvođenja ostane nepromijenjena, agent ne radi na tom čvoru i nikakvo uređivanje YAML-a to neće popraviti.