Preverjanje vira/cilja so ena vrata, ne celotna pot VPN

VPN se konča na primerku EC2, do naslova tunela tega primerka lahko pridete, promet, ki bi moral iti skozenj do drugega zasebnega gostitelja, pa izgine. To sta dva različna preizkusa in njuno mešanje izgubi ure. Prvi sprašuje, ali lahko pridete do primerka; drugi zahteva, da posreduje promet za cilj, ki ni njegov, kar potrebuje posredovanje v Linuxu, pravilnik požarnega zidu, pot na drugi strani in dovoljenje na ravni AWS, ki nima nič skupnega z gostujočim operacijskim sistemom. Nič v konzoli ne opozarja na to razliko. Simptom je videti kot napaka pri usmerjanju in običajno ni.

Ločite oba preizkusa, preden karkoli spremenite

Doseganje prehoda dokazuje tunel, pot do njegovega naslova in varnostno skupino, ki dovoljuje izmenjavo. Posredovanje za drugega gostitelja ne dokazuje ničesar od tega: uporablja drug naslov vira, drug cilj in primerek v vlogi, za katero ni bil nujno zgrajen. Zapišite oba preizkusa ločeno in zabeležite, kateri ne uspe, ker je popravek za vsakega v drugi konzoli. Primerek prehoda, zgrajen samo za zaključevanje tunelov, nima razloga posredovati za kar koli drugega, in njegove privzete vrednosti to odražajo. Zato drugi preizkus potrebuje svojo nastavitev, ne majhnega popravka prvega.

Ping, ki deluje do prehoda, in ping, ki ne uspe do gostitelja za njim, ni občasna težava. To je pričakovano vedenje primerka, ki mu ni bilo rečeno, da sme posredovati.

Zapišite pot, preden se dotaknete nastavitve

Zabeležite predpono odjemalca, posredovalni primerek ali omrežni vmesnik, ciljno podomrežje in povratno pot. Vnos v tabeli poti VPC, ki kaže na primerek, ne konfigurira operacijskega sistema primerka za posredovanje, gostujoče jedro z omogočenim posredovanjem pa ne ustvari poti VPC. Oba konca te povezave morata obstajati, in urejajo se na različnih mestih ljudje z različnim dostopom.

Nato preglejte nastavitev preverjanja vira/cilja na dejanski komponenti posredovanja, ne na vsakem primerku v VPC. AWS dokumentira, zakaj mora imeti primerek, ki posreduje promet za druge, to preverjanje izklopljeno, in tudi zakaj je nastavitev odločitev za vsak primerek in ne privzeta vrednost za celoten VPC.

Štiri meje, in preverjanje je le ena od njih

Obravnavajte pot kot štiri vprašanja in odgovorite nanje po vrsti. Prvi neuspešni odgovor pove, kje je delo, in noben od ostalih ga ne bo nadomestil.

Vrstni red je pomemben, ker je preverjanje poceni: poti so vidne na eni strani, preverjanje je en atribut, mnenje cilja pa je običajno zadnje, kar kdo vpraša.

Prevajanje spremeni, kateri vir cilj vidi

Usmerjena zasnova ohrani naslov vira odjemalca, zato cilj potrebuje povratno pot do predpone odjemalca. Prevedena zasnova namesto tega predstavi naslov prehoda, kar odstrani to zahtevo in jo nadomesti s tabelo stanj na prehodu. Odločite se glede na arhitekturo, ki jo nameravate, namesto da dodate prevajanje, ker ga je uporabil nepovezan primer in je bil videti delujoč.

Če prevajate, omejite pravilo na predpono odjemalca in predvideni cilj. Če ohranjate, potrdite, da druga stran pot res pozna, namesto da predvidevate, da se je bo naučila.

Preizkusite iz izvirnega odjemalca, nato spremembo obdržite

Zahteva, ustvarjena na prehodu, lahko uspe, medtem ko posredovana zahteva ne uspe, ker gre za drug vir in drug primer posredovanja. Po ciljnem popravku ponovite natančen preizkus odjemalec-do-vira, ki ni uspel, iz istega odjemalca, in potrdite, da se odgovor vrne, ne le da je zahteva prispela.

Na koncu vstavite nastavitev v upravljano konfiguracijo prehoda, da jo nadomestni primerek prejme. Uspešen preizkus, ki je odvisen od ročne izjeme, je preizkus, ki poteče ob naslednji ponovni gradnji, in oseba, ki ga je odkrila, ne bo tam, da bi se spomnila zakaj.