Kilde-/destinasjonssjekk er én port, ikke hele VPN-stien

VPN-et avsluttes på en EC2-instans, du kan nå tunneladressen til den instansen, og trafikk som skulle passere gjennom den mot en annen privat vert, forsvinner. Det er to forskjellige tester, og å blande dem kaster bort timer. Den første spør om du kan nå instansen; den andre krever at den videresender trafikk for en destinasjon som ikke er dens egen, noe som krever Linux-videresending, en brannmurpolicy, en rute på den andre siden og en tillatelse på AWS-nivå som ikke har noe med gjesteoperativsystemet å gjøre. Ingenting i konsollen henleder oppmerksomheten på den forskjellen. Symptomet ser ut som en rutefeil, og det er det vanligvis ikke.

Skill de to testene før du endrer noe

Å nå gatewayen beviser tunnelen, ruten til adressen og sikkerhetsgruppen som tillater utvekslingen. Videresending for en annen vert beviser ingenting av dette: den bruker en annen kildeadresse, en annen destinasjon og en instans i en rolle den ikke nødvendigvis er bygget for. Skriv de to testene hver for seg og noter hvilken som feiler, fordi rettelsen for hver av dem ligger i en annen konsoll. En gateway-instans bygget bare for å avslutte tunneler har ingen grunn til å videresende for noe annet, og standardverdiene gjenspeiler det. Derfor trenger den andre testen sitt eget oppsett i stedet for en liten justering av den første.

En ping som virker til gatewayen, og en ping som feiler til verten bak den, er ikke et periodisk problem. Det er forventet oppførsel fra en instans som ikke har fått beskjed om at den kan videresende.

Skriv ned stien før du rører en innstilling

Noter klientprefikset, den videresendende instansen eller nettverksgrensesnittet, målsubnettet og svarreturruten. En oppføring i VPC-rutetabellen som peker på en instans, konfigurerer ikke instansens operativsystem for videresending, og en gjestekjerne med videresending aktivert oppretter ikke en VPC-rute. Begge endene av det forholdet må finnes, og de redigeres på forskjellige steder av personer med forskjellig tilgang.

Undersøk deretter innstillingen for kilde-/destinasjonssjekk på den faktiske videresendingskomponenten, ikke på hver instans i VPC-en. AWS dokumenterer hvorfor en instans som videresender trafikk for andre, må ha den sjekken deaktivert, og også hvorfor innstillingen er en beslutning per instans og ikke en standard for hele VPC-en.

Fire grenser, og sjekken er bare én av dem

Behandle stien som fire spørsmål og svar på dem i rekkefølge. Det første svaret som feiler, er der arbeidet ligger, og ingen av de andre vil kompensere for det.

Rekkefølgen betyr noe fordi det er billig å kontrollere: ruter er synlige på én side, sjekken er ett attributt, og destinasjonens mening er vanligvis det siste noen spør om.

Oversettelse endrer hvilken kilde destinasjonen ser

Et rutet design bevarer klientens kildeadresse, så destinasjonen trenger en returrute til klientprefikset. Et oversatt design presenterer i stedet gatewayens adresse, noe som fjerner det kravet og erstatter det med en tilstandstabell på gatewayen. Bestem ut fra arkitekturen du sikter mot, i stedet for å legge til oversettelse fordi et urelatert eksempel brukte det og så ut til å virke.

Hvis du oversetter, begrens regelen til klientprefikset og den tiltenkte destinasjonen. Hvis du bevarer, bekreft at den andre siden faktisk kjenner ruten i stedet for å anta at den lærer en.

Test fra den opprinnelige klienten, og behold deretter endringen

En forespørsel som genereres på gatewayen, kan lykkes mens en videresendt forespørsel feiler, fordi det er en annen kilde og et annet videresendingstilfelle. Etter en målrettet rettelse, gjenta den nøyaktige klient-til-ressurs-testen som feilet, fra samme klient, og bekreft at svaret kommer tilbake og ikke bare at forespørselen ankom.

Til slutt, legg innstillingen i gatewayens administrerte konfigurasjon slik at en erstatningsinstans får den. En vellykket test som avhenger av et manuelt unntak, er en test som utløper ved neste gjenoppbygging, og personen som oppdaget den, vil ikke være der for å huske hvorfor.