Millist lähte-IP-d kasutab AWS-i NAT-lüüs VPN-i suunas?

Avad VPC-konsooli, sest partner küsis, milline lähtevõrk saabub site-to-site VPN-i kaudu. NAT-lüüside leht näitab avalikku lüüsi, millele on lisatud Elastic IP, ja kiusatus on see aadress ära saata ning edasi liikuda. See on õige vastus interneti teekonna jaoks ja vale vastus VPN-i teekonna jaoks, ning erinevus on selles, millisele lüüsile marsruutimistabel osutab. Käi teekond läbi enne, kui allowlisti kirjutad.

Alusta NAT-lüüside lehest, mitte allowlistist

NAT-lüüside leht ütleb sulle alamvõrgu, tüübi ja Elastic IP, ning need kolm välja on alustamiseks piisavad. Mida see ei ütle, on teekond, mille liiklus seejärel läbib. See tuleneb marsruutimistabelitest, mis on seotud NAT-lüüsi alamvõrku.

Loe kõigepealt tüüp, sest avalik või privaatne otsustab, kas ahelasse ilmub hiljem internetilüüs. Seejärel loe alamvõrk, sest seal elab teine marsruut.

Järgi kahte teisendust

Nii avalikud kui ka privaatsed NAT-lüüsid teisendavad töökoormuse privaatse IPv4 lähte NAT-lüüsi enda privaatseks IPv4 aadressiks. See esimene teisendus toimub tüübist sõltumata. Teine teisendus on see, mille inimesed unustavad: avalik NAT-lüüs annab liikluse internetilüüsile, mis vastendab aadressi lisatud Elastic IP-ga.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

Privaatsel teekonnal ei ole ahelas internetilüüsi. Kui liiklus väljub läbi transiidlüüsi või virtuaalse privaatse lüüsi, dokumenteerib NAT-lüüside juhend NAT-lüüsi privaatse aadressi allikana, mille kaugem pool saab. Just seda aadressi peaks partner lubama, mitte Elastic IP-d.

VPN-i teekond näitab tavaliselt privaatset aadressi

Töökoormuse puhul võrgus 10.20.1.0/24, mis jõuab partneri prefiksini, osutab töökoormuse alamvõrgu marsruutimistabel NAT-lüüsile ja NAT-lüüsi alamvõrgu marsruutimistabel privaatse lüüsi teekonnale. Mõlemad hüpped loevad ja ainult teine otsustab, mida partner näeb. Kui NAT-i alamvõrgul puudub marsruut VPN-i teekonnale, ei jõua pakett kunagi kohale ja see on teistsugune tõrge kui vale lähteaadress.

Kontrolli seda teist marsruuti enne, kui üldse aadressidest räägid. Puuduv marsruut ja valesti teatatud allikas näevad partneri jaoks, kes lihtsalt liiklust ei näe, täpselt ühesugused välja.

Kui teine teisendus muudab vastust

AWS pakub ka selgesõnalist, sobivat üks-ühele NAT-vastendust transiidlüüsi kinnitusel. See vastendus võib allika veel kord teisendada, enne kui kaugteenus seda näeb, ja see ei ole vaikekäitumine, mis ainult marsruudib. Kuna seda tuleb teadlikult seadistada, käsitle seda projekteerimiserandina, mitte millegi sellisena, mille sa kogemata pärid. Kui keegi sinu meeskonnas ei mäleta, et selle sisse lülitas, eelda, et seda pole, kuni oled kinnituse läbi lugenud.

Kui sinu lahendus seda kasutab, peab allowlist kirjeldama lõplikku vastendust, mitte NAT-lüüsi aadressi. Sama ettevaatus kehtib kättesaadavuse teekondade puhul: kui osaleb mitu lüüsi aadressi, on oodatav lähtekogum ühend, mitte üks esindav aadress. Kirjuta üles, millisesse teisendusse iga aadress kuulub, sest päritoluta nimekirja on hiljem võimatu auditeerida.

Privaatsele NAT-lüüsile ei saa anda internetiteenust, suunates selle internetilüüsile; AWS dokumenteerib, et selline liiklus jäetakse kõrvale. Vali tüüp kogu teekonna järgi, mitte nõude sõna VPN järgi.

Kirjuta leping, mille järgi sinu partner saab tegutseda

Kasutataval lepingul on neli osa: suund, kust voogusid algatatakse, teisendatud identiteet, mida partner näeb, tagasitee selle identiteedi jaoks ja kehtiv kaitseulatus. NAT-lüüsi vood algatatakse toetatud lähtepoolelt, seega ei ole see sissetulev pordiedastusteenus privaatse töökoormuse avamiseks. Selle varakult valjusti ütlemine hoiab ära projekteerimisülevaatuse, kus kumbki pool eeldas, et algatas teine.

Teisendus ostab leevendust aadresside kattumisele ja ennustatava lähtepoliitika ning maksab sulle kätte töökoormuse individuaalse identiteedi partneri logides. Kui audit vajab omistamist töökoormuse kaupa, hoia seda identiteeti rakenduskihis, selle asemel et proovida seda teisendatud lähteaadressist taastada.

Seejärel kontrolli pärast igasugust muudatust uuesti mõlemat marsruutimistabelit, sest uus kinnitus või ümber seotud alamvõrk kirjutab vastuse vaikselt ümber.