Käll-/målkontrollen är en port, inte hela VPN-vägen
En vidarebefordrande instans behöver AWS-behörighet samt Linux-rutter och brandväggsregler. Kontrollera käll-/målvalideringen på instansen som vidarebefordrar.
VPN:et avslutas på en EC2-instans, du kan nå tunneladressen för den instansen, och trafik som skulle passera genom den mot en annan privat värd försvinner. Det är två olika tester, och att blanda dem slösar bort timmar. Det första frågar om du kan nå instansen; det andra kräver att den vidarebefordrar trafik för ett mål som inte är dess eget, vilket kräver vidarebefordran i Linux, en brandväggspolicy, en rutt på andra sidan och ett tillstånd på AWS-nivå som inte har något med gästoperativsystemet att göra. Ingenting i konsolen fäster uppmärksamhet vid den skillnaden. Symtomet ser ut som ett routingfel, och det är det oftast inte.
Separera de två testerna innan du ändrar något
Att nå gatewayen bevisar tunneln, rutten till dess adress och den säkerhetsgrupp som tillåter utbytet. Vidarebefordran för en annan värd bevisar inget av detta: den använder en annan källadress, ett annat mål och en instans i en roll som den inte nödvändigtvis byggdes för. Skriv de två testerna var för sig och notera vilket som misslyckas, eftersom rättelsen för vart och ett finns i en annan konsol. En gateway-instans som bara byggdes för att avsluta tunnlar har ingen anledning att vidarebefordra för något annat, och standardvärdena speglar det. Därför behöver det andra testet sin egen uppsättning i stället för en liten justering av det första.
En ping som fungerar till gatewayen och en ping som misslyckas till värden bakom den är inte ett intermittent problem. Det är förväntat beteende hos en instans som inte har fått veta att den får vidarebefordra.
Skriv ner vägen innan du rör en inställning
Notera klientprefixet, den vidarebefordrande instansen eller nätverksgränssnittet, målsubnätet och svarsrutten. En post i VPC:ns routetabell som pekar på en instans konfigurerar inte instansens operativsystem för vidarebefordran, och en gästkärna med vidarebefordran aktiverad skapar inte en VPC-rutt. Båda ändarna av det förhållandet måste finnas, och de redigeras på olika ställen av personer med olika åtkomst.
Undersök sedan inställningen för käll-/målkontroll på den faktiska vidarebefordringskomponenten, inte på varje instans i VPC:n. AWS dokumenterar varför en instans som vidarebefordrar trafik för andra måste ha den kontrollen avstängd, och också varför inställningen är ett beslut per instans och inte en standard för hela VPC:n.
Fyra gränser, och kontrollen är bara en av dem
Behandla vägen som fyra frågor och svara på dem i ordning. Det första svaret som misslyckas är där arbetet ligger, och ingen av de andra kompenserar för det.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
Ordningen spelar roll eftersom det är billigt att kontrollera: rutter syns på en sida, kontrollen är ett enda attribut, och målets åsikt är vanligtvis det sista någon frågar om.
Översättning ändrar vilken källa målet ser
En routad design bevarar klientens källadress, så målet behöver en returrutt till klientprefixet. En översatt design presenterar i stället gatewayens adress, vilket tar bort det kravet och ersätter det med en tillståndstabell på gatewayen. Bestäm utifrån arkitekturen du avser, i stället för att lägga till översättning för att ett orelaterat exempel använde det och verkade fungera.
Om du översätter, begränsa regeln till klientprefixet och det avsedda målet. Om du bevarar, bekräfta att andra sidan verkligen känner till rutten i stället för att anta att den lär sig en.
Testa från den ursprungliga klienten och behåll sedan ändringen
En begäran som skapas på gatewayen kan lyckas medan en vidarebefordrad begäran misslyckas, eftersom det är en annan källa och ett annat vidarebefordringsläge. Efter en riktad rättelse, upprepa det exakta klient-till-resurs-testet som misslyckades, från samma klient, och bekräfta att svaret kommer tillbaka och inte bara att begäran anlände.
Lägg till slut in inställningen i gatewayens hanterade konfiguration så att en ersättningsinstans får den. Ett lyckat test som beror på ett manuellt undantag är ett test som löper ut vid nästa ombyggnad, och personen som upptäckte det kommer inte att vara där för att minnas varför.