VPN lõpeb EC2 instansil, selle instanssi tunneliaadressile on teil juurdepääs, ja liiklus, mis pidi sealtkaudu kulgema teise privaatse hostini, kaob. Need on kaks erinevat katset ja nende segamine raiskab tunde. Esimene küsib, kas saate instanssile ligi; teine nõuab, et see edastaks liiklust sihtkohale, mis ei ole tema oma, mis vajab Linuxi edastust, tulemüüri poliitikat, marsruuti kaugemal küljel ja AWS-i tasandi luba, millel pole külalisoperatsioonisüsteemiga mingit seost. Konsoolis ei juhi miski sellele erinevusele tähelepanu. Sümptom näeb välja nagu marsruutimise rike, ja tavaliselt see seda ei ole.

Eraldage kaks katset enne, kui midagi muudate

Väravani jõudmine tõestab tunnelit, marsruuti selle aadressini ja turvagruppi, mis vahetust lubab. Edastamine teise hosti jaoks ei tõesta neist midagi: see kasutab teist lähteaadressi, teist sihtkohta ja instanssi rollis, mille jaoks seda ei pruugitud ehitada. Kirjutage kaks katset eraldi ja märkige, milline ebaõnnestub, sest iga parandus asub eri konsoolis. Ainult tunnelite lõpetamiseks ehitatud värava instanssil pole põhjust millegi muu jaoks edastada, ja selle vaikeväärtused seda peegeldavad. Seetõttu vajab teine katse oma seadistust, mitte väikest parandust esimeses.

Väravani töötav ping ja sellest kaugemal asuva hostini ebaõnnestuv ping ei ole aeg-ajalt esinev probleem. See on oodatud käitumine instanssilt, kellele pole öeldud, et ta tohib edastada.

Kirjutage teekond üles enne, kui seadistust puudutate

Märkige üles kliendi prefiks, edastav instanss või võrguliides, sihtalavõrk ja vastuse marsruut. VPC marsruutimistabeli kirje, mis osutab instanssile, ei seadista instanssi operatsioonisüsteemi edastama, ja edastamisega lubatud külalis-tuum ei loo VPC marsruuti. Selle suhte mõlemad otsad peavad olemas olema, ja neid muudetakse eri kohtades erineva juurdepääsuga inimeste poolt.

Seejärel kontrollige allika/sihtkoha kontrolli seadistust tegelikul edastuskomponendil, mitte igal instanssil VPC-s. AWS dokumenteerib, miks instanss, mis edastab liiklust teiste eest, vajab selle kontrolli väljalülitamist, ja ka seda, miks on seadistus iga instanssi otsus, mitte kogu VPC vaikeväärtus.

Neli piiri ja kontroll on neist ainult üks

Käsitlege teekonda nelja küsimusena ja vastake neile järjekorras. Esimene ebaõnnestuv vastus on koht, kus töö on, ja ükski teine ei korva seda.

BoundaryQuestion it answers
VPC route tablesDo the destinations and replies select the intended gateway?
Forwarding instanceDo the AWS check and the guest OS both permit forwarding?
Access policyDo security groups, ACLs and host rules allow the exchange?
DestinationCan the service accept that source and return a reply?

Järjekord loeb, sest kontrollimine on odav: marsruudid on nähtavad ühel lehel, kontroll on üks atribuut ja sihtkoha arvamus on tavaliselt viimane, mida keegi küsib.

Tõlkimine muudab, millist allikat sihtkoht näeb

Marsruuditud lahendus säilitab kliendi lähteaadressi, seega vajab sihtkoht tagasimarsruuti kliendi prefiksini. Tõlgitud lahendus esitab selle asemel värava aadressi, mis kõrvaldab selle nõude ja asendab selle väraval oleva olekutabeliga. Otsustage kavandatud arhitektuuri järgi, selle asemel et lisada tõlkimist, sest mõni seostamatu näide kasutas seda ja näis toimivat.

Kui tõlgite, piirake reegel kliendi prefiksi ja kavandatud sihtkohaga. Kui säilitate, kinnitage, et kaugem pool tegelikult teab marsruuti, selle asemel et eeldada, et see õpib selle.

Katsetage algse kliendi pealt ja jätke siis muudatus alles

Väraval loodud päring võib õnnestuda, samal ajal kui edastatud päring ebaõnnestub, sest see on teine allikas ja teine edastusjuhtum. Pärast sihitud parandust korrake täpset klient-ressursi katset, mis ebaõnnestus, samalt kliendilt, ja kinnitage, et vastus tuleb tagasi, mitte ainult see, et päring kohale jõudis.

Lõpuks pange seadistus värava hallatavasse konfiguratsiooni, et asendusinstanss selle saaks. Edukas katse, mis sõltub käsitsi tehtud erandist, on katse, mis aegub järgmisel ülesehitamisel, ja inimest, kes selle avastas, ei ole seal, et meenutada, miks.

Seotud artiklid