Kāpēc GKE podi caur VPN nesasniedz vietējos serverus

Pings darbojas no mezgla un neizdodas no poda, un vietējā tīklā nekas neienāk. Tunelis un maršruts ir kārtībā; avota adrese uz vada nav. Šos divus gadījumus atšķir tas, ko pakete apgalvo esam, kad tā atstāj klasteri, un GKE par to ir savs viedoklis. Mehānisms ir masquerade izņēmumu saraksts, un tā nolasīšanai pietiek ar vienu komandu.

Izlasi spēkā esošo sarakstu, pirms kaut ko maini

GKE piegādā aģentu, kas katram galamērķa diapazonam izlemj, vai podu trafiks izejot tiek pārrakstīts uz mezgla adresi. Tā piegādātā konfigurācija nosauc trīs RFC1918 blokus, 10.0.0.0/8, 172.16.0.0/12 un 192.168.0.0/16, kā izņemtus galamērķus. Tāpēc viss, ko sūtāt no poda uz vietējo 10.x serveri, atstāj mezglu ar paša poda adresi joprojām pievienotu. Paša mezgla trafiks netiek pārrakstīts, un tieši tāpēc tā pings darbojas.

Izlasi paredzēto konfigurāciju un instalētos noteikumus, jo tie var nesakrist. kubectl -n kube-system get configmap ip-masq-agent -o yaml parāda, kas tika pateikts aģentam, un kubectl -n kube-system get pods -l k8s-app=ip-masq-agent parāda, vai kaut kas darbojas, lai to piemērotu. Uz mezgla iptables-save | grep -i masq parāda noteikumus, kas kodolā patiešām pastāv. Kad ConfigMap saka vienu un noteikumi otru, aizdomās turamais ir aģents, nevis tīkls.

Apstiprini avota adresi ar uztveršanu

Veic uztveršanu pirms saraksta maiņas. Filtrs uz vienu galamērķi saglabā izvadi lasāmu: tcpdump -ni any host 10.20.30.40.

Salīdzini to ar to, ko ziņo otrā puse. Uztveršana vietējā tīklā, kas rāda poda adresi un nekādu atbildi, noslēdz loku: izņēmumu saraksts izskaidro asimetriju bez jebkādas tuneļa kļūdas. Ar diviem vienas avota adreses novērojumiem pietiek, lai pārstātu minēt par CNI.

Sašaurini izņēmumu līdz podu CIDR

Atbalstītais labojums sašaurina izņēmumu, nevis to noņem: atstāj podu CIDR izņemtu un izmet pārējo 10.x telpu. Šis saraksts atrodas aģenta ConfigMap zem nonMasqueradeCIDRs, un tā maiņa ir rediģēšana un pēc tam izvēršana. Aizstāj plašo ierakstu ar klastera faktisko podu diapazonu, saglabā pārējos privātos blokus, ja trafikam klastera iekšienē tie vēl vajadzīgi, un atstāj resyncInterval mierā, ja vien tev nav iemesla. Piemēro, apstiprini, ka aģenta podi ir pārstartēti, un apstiprini, ka kodola noteikumi ir mainījušies.

Šīs ir izmaiņas visā klasterī ar reālu ietekmes rādiusu. Kad tās stājas spēkā, trafiks, kas iepriekš saglabāja savu poda avotu, tagad pienāk pārrakstīts uz mezglu, tāpēc viss, kas bija piesaistīts šīm podu adresēm, redz citu sūtītāju. Upuri ir žurnāli, atļauju saraksti un vietējie ugunsmūra noteikumi, kuros nosauktas podu adreses, un tie klusi sabrūk. Paziņo izmaiņas kā uzvedības maiņu, nevis kā labojumu.

Klasterī ar vairākiem mezglu pūliem pārbaudi, vai aģents ir ieplānots tajos mezglos, kuros skartie podi patiešām darbojas. Pūls bez DaemonSet saglabā savus vecos noteikumus, un nekas ConfigMap to neparādīs.

Alternatīva un tās cena

Otrs variants atstāj podu adreses neskartas un iemāca ceļam par tām. Podu CIDR nonāk Cloud VPN trafika selektoros, un vietējai pusei tam vajadzīgs atgriešanās maršruts, lai atbildes zinātu, kurp doties. Tas saglabā poda identitāti, ko vēlas daži drošības modeļi, un paplašina gan maršrutēšanas, gan ugunsmūra apjomu, kas otrai pusei jāpieņem.

Darījums ir lasāmība pret apjomu. Tulkošana liek vietējai pusei redzēt vienu adresi uz mezglu, ko ir viegli iekļaut atļauju sarakstā un kas slēpj, kurš pods ko nosūtīja. Bez tulkošanas poda adrese saglabājas no gala līdz galam, kas ir labāk atribūcijai un sliktāk katram ceļā esošajam ierīcei, kurai jāapgūst jauns diapazons. Neviens variants nav Docker vai CNI defekts; abi ir maršrutēšanas lēmumi ar operatīvu rēķinu. Izvēlies to, kura rēķinu tava komanda var samaksāt, un pieraksti, kāpēc.

Pārbaudi un atritini

Palaid to pašu uztveršanu vēlreiz. Uztveršana mezgla līmenī, kas pēc tavas rediģēšanas joprojām izdrukā poda adresi, nozīmē, ka noteikumi nekad nav mainījušies, lai ko arī teiktu ConfigMap. Vads ir fakts; viss pārējais ir secinājums.

Tad pārbaudi pretējo virzienu, jo puse no šīm izmaiņām tiek pārbaudīta tikai izejošā virzienā. Apstiprini, ka atbilde sasniedz mezglu vai podu, kas nosūtīja pieprasījumu, un apstiprini, ka lietojumprogramma pabeidza, nevis tikai saņēma SYN. Uztveršana, kas rāda pieprasījumu bez atbildes, ir maršrutēšanas problēma otrā pusē, nevis masquerade problēma šajā pusē.

Atritināšana ir iepriekšējais ConfigMap, piemērots tāpat, ar to pašu apstiprinājumu, ka aģents ir pārstartēts un noteikumi mainījušies. Izmaiņu žurnālā saglabā viena zināma pieprasījuma avota adresi pirms un pēc, jo tieši tā viena rinda pierāda, ka izmaiņas izdarīja to, ko tu teici. GKE IP masquerade aģenta rokasgrāmata dokumentē noklusējuma vērtības un ConfigMap laukus. Ja pēc izvēršanas avota adrese nav mainījusies, aģents šajā mezglā nedarbojas un nekāda YAML rediģēšana to nesalabos.