GKE-poddar tappade VPN-åtkomsten efter 1.14: två sätt att rätta källan

Efter 1.14 når poddar VPN med egna adresser, så peers släpper svar. Välj källkontraktet och ställ sedan in nonMasqueradeCIDRs efter det.

En uppgradering landar, och system på andra sidan tunneln börjar avvisa podtrafik som fungerade veckan innan. Tunneln är uppe, brandväggsreglerna är orörda och ingen har redigerat peer-policyn. Det som förändrades är osynligt i klustrets loggar: källadressen som dessa system nu ser. Den luckan förklarar ett fel som ser ut som ett nätavbrott och beter sig som ett behörighetsproblem.

Det finns två giltiga svar, och de leder till olika ställen. Välj källkontraktet innan du redigerar en ConfigMap.

Standardregeln som slutade installeras

Tidigare GKE-versioner installerade en masquerade-regel som ersatte podkällor med nodadressen närhelst målet låg utanför 10.0.0.0/8. En VPN-gateway inom det intervallet såg podadressen, medan allt längre bort såg ut att komma från noden. Peers byggde allowlists och returvägar kring nodadresser eftersom det var vad de observerade.

Senare versioner slutade installera den standardregeln. Podtrafik kommer nu till gatewayen med podadresser, oavsett mål. En peer som bara routar nodadresser släpper svaren, och ingen av sidorna skriver en användbar loggpost. Förfrågan kan till och med lyckas i fjärränden, och det är det som gör felet svårt att jaga.

Ingenting är trasigt i betydelsen en död komponent. De två sidorna är helt enkelt oense om vilken källa som är legitim.

Välj den källa som peeren ska se

Att behålla podadresser är det mer exakta kontraktet. Fjärrsidan ser den arbetsbelastning som producerade trafiken, loggningen förblir ärlig och policy per pod blir möjlig. Priset är att peeren måste bära podprefixet.

Att behålla nodadresser är det billigare kontraktet. Slå på masquerade igen för det målet och peeren fortsätter se en adress den redan litar på.

En fråga avgör mellan dem: vad gör peeren med källan? Om den loggar, tillämpar policy per källa eller genomdriver snäv returroutning, motiverar podadresser den extra konfigurationen. Om den bara behöver skicka svar kostar masquerade mindre och begär ingenting av andra sidan. Båda valen är försvarbara så länge båda teamen skriver ned dem.

Ett tredje alternativ är oftast ett misstag: masquerade allt och förlora förmågan att tillskriva trafik. Undvik det om inte en peer verkligen inte kan routa något annat än nodadresser.

Peka nonMasqueradeCIDRs mot de verkliga intervallen

GKE kör ip-masq-agent i kube-system, och dess ConfigMap listar de mål som hoppar över masquerade. För att bevara podkällor mot tunneln hör podintervallet, nodsubnätet och det lokala prefixet alla hemma i den listan.

Ersätt exempelvärdena med intervall från ditt eget kluster. Gör inte listan bredare än kravet motiverar, eftersom varje extra post ändrar vad ett annat mål ser. De tre posterna nedan står för podnätet, nodsubnätet och prefixet bakom tunneln:

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

En post på 0.0.0.0/0 stänger av masquerade för alla mål, vilket ändrar hur orelaterade arbetsbelastningar framstår för externa tjänster och är sällan avsiktligt. Agenten läser om sin konfiguration vid resyncInterval, så en omstart är oftast onödig. Kontrollera att agentens pod körs och öppna sedan den monterade filen i den. Det är läsningen av den filen som bevisar att ändringen kom fram.

Returvägen är den andra halvan

Masquerade ändrar förfrågans källa och ingenting annat. Vilken källa peeren än tar emot behöver den fortfarande en väg tillbaka till den, och klustret behöver fortfarande en väg mot peeren.

En fångst på VPN-gatewayen skiljer de två felen snabbt. Paket som kommer med podadresser och aldrig får svar betyder att peeren saknar en väg för podprefixet. Ett svar som dyker upp på gatewayen men aldrig når klustret betyder att den lokala vägen saknas. Skriv kontraktet i ärendet hur som helst: vilken källa peeren ser och vilket prefix den routar tillbaka.

Kontrollera igen efter varje uppgradering

Standardbeteendet för masquerade har redan ändrats en gång, och byte av en nodpool kan nollställa klustrets nätverk. Behandla källkontraktet som något att verifiera, inte att anta.

Efter en uppgradering, skicka en förfrågan från en pod till en lokal tjänst och läs källan som peeren loggar. Den enda observationen fångar en regression som en tunnelstatussida gladeligen skulle rapportera som frisk. Att upprepa det kostar en minut och sparar nästa person en kväll.

Relaterade artiklar