Ce IP sursă folosește un gateway NAT AWS către un VPN?
Elastic IP-ul unui gateway NAT public este identitatea pe internet, nu ceea ce vede un partener VPN. Urmați ruta de la subrețea la gateway pentru a afla sursa reală.
Deschideți consola VPC pentru că un partener a întrebat ce interval sursă va ajunge prin VPN-ul de la site la site. Pagina gateway-urilor NAT arată un gateway public cu un Elastic IP atașat, iar tentația este să trimiteți acea adresă și să mergeți mai departe. Este răspunsul corect pentru calea internetului și răspunsul greșit pentru calea VPN, iar diferența este către ce gateway indică tabela de rute. Parcurgeți ruta înainte de a scrie lista de adrese permise.
Începeți de la pagina gateway-urilor NAT, nu de la lista de adrese permise
Pagina gateway-urilor NAT vă spune subrețeaua, tipul și Elastic IP-ul, iar aceste trei câmpuri sunt suficiente pentru început. Ce nu vă spune este calea pe care o ia traficul după aceea. Aceasta provine din tabelele de rute atașate subrețelei gateway-ului NAT.
Citiți mai întâi tipul, pentru că public sau privat decide dacă mai târziu va apărea un gateway de internet în lanț. Apoi citiți subrețeaua, pentru că acolo se află a doua rută.
Urmați cele două traduceri
Atât gateway-urile NAT publice, cât și cele private traduc sursa IPv4 privată a sarcinii de lucru în adresa IPv4 privată proprie a gateway-ului NAT. Această primă traducere are loc indiferent de tip. A doua traducere este cea pe care oamenii o uită: un gateway NAT public predă traficul gateway-ului de internet, care mapează adresa la Elastic IP-ul atașat.
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10
Pe calea privată nu există niciun gateway de internet în lanț. Când traficul iese printr-un gateway de tranzit sau un gateway privat virtual, ghidul gateway-urilor NAT documentează adresa privată a gateway-ului NAT ca sursa pe care o primește partea îndepărtată. Aceasta este adresa pe care partenerul ar trebui să o permită, nu Elastic IP-ul.
Calea VPN arată de obicei adresa privată
Pentru o sarcină de lucru în 10.20.1.0/24 care ajunge la un prefix al partenerului, tabela de rute a subrețelei sarcinii indică gateway-ul NAT, iar tabela de rute a subrețelei gateway-ului NAT indică calea gateway-ului privat. Ambele salturi contează, iar doar al doilea decide ce vede partenerul. Dacă subrețeaua NAT nu are nicio rută către calea VPN, pachetul nu ajunge niciodată, iar aceasta este o defecțiune diferită de o adresă sursă greșită.
Verificați acea a doua rută înainte de a vorbi despre adrese. O rută lipsă și o sursă raportată greșit arată identic pentru un partener care pur și simplu nu vede trafic.
Când o a doua traducere schimbă răspunsul
AWS oferă și o mapare NAT explicită și corespunzătoare unu-la-unu pe o atașare de gateway de tranzit. Acea mapare poate traduce din nou sursa înainte ca serviciul îndepărtat să o vadă, iar acesta nu este comportamentul implicit care doar rutează. Deoarece trebuie configurată intenționat, tratați-o ca pe o excepție de proiectare și nu ca pe ceva moștenit din greșeală. Dacă nimeni din echipa dumneavoastră nu își amintește să o fi activat, presupuneți că lipsește până când veți fi citit atașarea.
Dacă proiectarea dumneavoastră o folosește, lista de adrese permise trebuie să descrie maparea finală și nu adresa gateway-ului NAT. Aceeași prudență se aplică și căilor de disponibilitate: când participă mai multe adrese de gateway, setul de surse așteptat este reuniunea, nu o singură adresă reprezentativă. Notați cărei traduceri îi aparține fiecare adresă, pentru că o listă fără proveniență este imposibil de auditat mai târziu.
Unui gateway NAT privat nu i se poate oferi serviciu de internet direcționându-l către un gateway de internet; AWS documentează că un astfel de trafic este eliminat. Alegeți tipul din calea completă, nu din cuvântul VPN din cerință.
Scrieți contractul pe baza căruia partenerul dumneavoastră poate acționa
Contractul utilizabil are patru părți: direcția din care sunt inițiate fluxurile, identitatea tradusă pe care o va vedea partenerul, ruta de întoarcere pentru acea identitate și sfera de protecție aplicabilă. Fluxurile gateway-ului NAT sunt inițiate din partea sursă acceptată, deci acesta nu este un serviciu de redirecționare a porturilor de intrare pentru a expune o sarcină de lucru privată. A spune acest lucru cu voce tare devreme previne o revizuire de proiectare în care fiecare parte presupunea că cealaltă a inițiat.
Traducerea cumpără alinare de la suprapunerea adreselor și o politică de sursă previzibilă, iar dumneavoastră vă costă identitatea individuală a sarcinii de lucru în jurnalele partenerului. Dacă auditul are nevoie de atribuire pe sarcină de lucru, păstrați acea identitate la nivelul aplicației în loc să încercați să o recuperați dintr-o adresă sursă tradusă.
Apoi verificați din nou ambele tabele de rute după orice modificare, pentru că o atașare nouă sau o subrețea reasociată rescrie răspunsul în tăcere.