Kilde-/destinationskontrol er én port, ikke hele VPN-stien
En videresendende instans skal have AWS-tilladelse samt Linux-ruter og firewallregler. Kontroller kilde-/destinationsvalidering på den instans, der videresender.
VPN'et slutter på en EC2-instans, du kan nå den instans' tunneladresse, og trafik, der skulle passere gennem den mod en anden privat vært, forsvinder. Det er to forskellige tests, og at blande dem spilder timer. Den første spørger, om du kan nå instansen; den anden kræver, at den videresender trafik for en destination, der ikke er dens egen, hvilket kræver Linux-videresendelse, en firewallpolitik, en rute på den anden side og en tilladelse på AWS-niveau, der intet har med gæsteoperativsystemet at gøre. Intet i konsollen henleder opmærksomheden på den forskel. Symptomet ligner en rutefejl, og det er det normalt ikke.
Adskil de to tests, før du ændrer noget
At nå gatewayen beviser tunnelen, ruten til dens adresse og den sikkerhedsgruppe, der tillader udvekslingen. Videresendelse for en anden vært beviser intet af det: den bruger en anden kildeadresse, en anden destination og en instans i en rolle, den ikke nødvendigvis er bygget til. Skriv de to tests hver for sig, og noter hvilken der fejler, fordi rettelsen for hver af dem ligger i en anden konsol. En gateway-instans, der kun er bygget til at afslutte tunneler, har ingen grund til at videresende for noget andet, og dens standardindstillinger afspejler det. Derfor kræver den anden test sin egen opsætning i stedet for en lille justering af den første.
En ping, der virker til gatewayen, og en ping, der fejler til værten bag den, er ikke et periodisk problem. Det er den forventede adfærd for en instans, der ikke har fået at vide, at den må videresende.
Skriv stien ned, før du rører en indstilling
Noter klientpræfikset, den videresendende instans eller netværksgrænseflade, målsubnettet og svarreturruten. En post i VPC-rutetabellen, der peger på en instans, konfigurerer ikke instansens operativsystem til at videresende, og en gæstekerne med videresendelse aktiveret opretter ikke en VPC-rute. Begge ender af det forhold skal findes, og de redigeres forskellige steder af personer med forskellig adgang.
Undersøg derefter indstillingen for kilde-/destinationskontrol på den faktiske videresendelseskomponent, ikke på hver instans i VPC'en. AWS dokumenterer, hvorfor en instans, der videresender trafik for andre, skal have den kontrol deaktiveret, og også hvorfor indstillingen er en beslutning for hver instans frem for en standard for hele VPC'en.
Fire grænser, og kontrollen er kun én af dem
Behandl stien som fire spørgsmål, og svar på dem i rækkefølge. Det første svar, der fejler, er der, hvor arbejdet ligger, og ingen af de andre vil kompensere for 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? |
Rækkefølgen er vigtig, fordi det er billigt at kontrollere: ruter er synlige på én side, kontrollen er et enkelt attribut, og destinationens mening er normalt det sidste, nogen spørger om.
Oversættelse ændrer, hvilken kilde destinationen ser
Et rutet design bevarer klientens kildeadresse, så destinationen har brug for en returrute til klientpræfikset. Et oversat design præsenterer i stedet gatewayens adresse, hvilket fjerner det krav og erstatter det med en tilstandstabel på gatewayen. Beslut ud fra den arkitektur, du sigter mod, i stedet for at tilføje oversættelse, fordi et urelateret eksempel brugte det og så ud til at virke.
Hvis du oversætter, skal du afgrænse reglen til klientpræfikset og den tilsigtede destination. Hvis du bevarer, skal du bekræfte, at den anden side faktisk kender ruten i stedet for at antage, at den lærer en.
Test fra den oprindelige klient, og behold derefter ændringen
En anmodning, der genereres på gatewayen, kan lykkes, mens en videresendt anmodning fejler, fordi det er en anden kilde og et andet videresendelsestilfælde. Efter en målrettet rettelse skal du gentage den præcise klient-til-ressource-test, der fejlede, fra den samme klient og bekræfte, at svaret kommer tilbage, og ikke kun at anmodningen nåede frem.
Læg endelig indstillingen i gatewayens administrerede konfiguration, så en erstatningsinstans får den. En vellykket test, der afhænger af en manuel undtagelse, er en test, der udløber ved næste genopbygning, og den person, der opdagede den, vil ikke være der for at huske hvorfor.