VGW или TGW? Каде завршува IPsec тунелот на AWS Site-to-Site

Луѓето прашуваат каде AWS Site-to-Site VPN престанува да го штити пакетот и очекуваат еден одговор: кај портата. Корисната верзија на тој одговор именува која порта, зашто виртуелната приватна порта и транзитната порта се различни поставки со различни објекти за приклучување, а рецензентот што ја претпостави погрешната ја гради останатата проценка врз дијаграм што не постои. Изведи ги трите проверки подолу по ред. Секоја или ја потврдува границата или ти кажува дека претходниот одговор бил за друг ресурс.

Именувај ги трите крајни точки пред да процениш нешто

Прегледот на шифрирањето на оваа патека бара три именувани нешта: портата на клиентот, целта на AWS VPN што го завршува IPsec, и крајната точка на апликацијата што го прима внатрешниот пакет. Запиши ги со нивните идентификатори на ресурси пред да отвориш и една страница од конзолата, зашто сето по оваа точка е тврдење за една од тие три.

Портата на клиентот е твоја и нејзината конфигурација ти е видлива. Целта на AWS е управуван ресурс, а грешката е да се претпостави: VPN врската може да се приклучи на виртуелна приватна порта или директно на транзитна порта, и ниту едната не ја подразбира другата. Третата крајна точка е онаа што луѓето ја прескокнуваат, и единствена е што одговара на вистинското прашање за податоците на апликацијата.

Проверка 1: која порта навистина го завршува тунелот

Двете поставки се поддржани и архитектонскиот водич за Site-to-Site VPN ги опишува една до друга, затоа прашај го API-то наместо дијаграм што често е стар една година. Барање само за читање на една врска ги враќа полињата на целта на VPN:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

Разликувачот е TransitGatewayId, а не VpnGatewayId. Врска со празно TransitGatewayId завршува на самостојна виртуелна приватна порта, додека врска со поставено тоа поле завршува на VPN приклучок на транзитната порта, и VpnGatewayId може да остане пополнето во тој случај зашто може да ја именува носечката порта на приклучокот. Прво прочитај го полето TGW, потоа потврди го типот на приклучокот од списокот на приклучоци, а не од името на поле, зашто VPC приклучокот на таа транзитна порта не е VPN приклучокот. Наоѓањето на целната инстанца во поврзан VPC не ти кажува ништо за тоа кој VPN приклучок го пренел пакетот.

Додека си таму, провери ги тунелите. Врската носи два IPsec тунели за резерва, а врска чиј втор тунел никогаш не се подигнал е вистинско откритие за достапноста, иако ништо не менува на границата на шифрирањето:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

Проверка 2: што уште носи внатрешниот пакет

Откако IPsec ќе заврши, AWS го проследува дешифрираниот пакет по маршрутата што му одговарала. Од таа точка сообраќајот е обичен VPC сообраќај, а заштитата на VPN е завршена. Тоа не е празнина во услугата; тоа е значењето на границата, а точката на списокот е тоа да се каже јасно наместо да се дозволи „VPN-от е шифриран“ да стои наместо „податоците се шифрирани од крај до крај“.

Сега разгледај што имало внатре. Ако внатрешниот пакет е протокол на апликација во чист текст, ништо подолу не додава доверливост додека нешто друго не го шифрира. Ако внатрешниот пакет веќе носи TLS сесија, отстранувањето на надворешниот IPsec не менува ништо за таа сесија: таа останува заштитена до својата крајна точка, каде и да е таа крајна точка.

Вообичаената претерана корекција е да се заклучи дека сето зад портата е изложено. Не е. Транспортот на услугата, шифрирањето на складиштето и TLS-от на апликацијата се одделни механизми со одделни услови, и секој мора да се процени според своите услови наместо да се изведе од формата на VPN-от. Запис во дневникот на текови што покажува ACCEPT докажува дека рутирањето работело и не кажува ништо за доверливоста, што е токму грешката што овој список постои за да ја спречи.

Проверка 3: што го завршува TLS-от зад портата

Следи го слушателот, не адресата. Ако балансерот на оптоварување или проксито го завршува TLS-от, врската што ја држи твојот клиент завршува таму, а проксито отвора втора врска кон бекендот што може да биде чист текст или TLS со друг синџир на доверба. Приватна IP адреса и соодветна маршрута не се доказ за таа втора врска.

Тестирај ја крајната точка што навистина ти е важна од внатрешноста на VPC-то, со името што го користи апликацијата, а не со IP што си го решил еднаш:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

Повтори го тоа за секој скок низ кој поминува барањето. Ако одговорот се разликува меѓу името свртено кон клиентот и името на бекендот, си го нашол точно тој сегмент што VPN-от никогаш не го покрил, и тоа е откритието што треба да се запише.

Запиши го резултатот како сегменти, не како пресуда

Излезот на овој список е мала табела со еден ред за секој сегмент: портата на клиентот до целта на AWS VPN, портата до работното оптоварување, работното оптоварување до складиштето на податоци, и секој скок на прокси меѓу нив. Секој ред кажува што го штити и од што зависи таа заштита. „Шифрирано“ без механизам и без крајна точка не е ред.

Потоа одговори на првобитното барање со истите термини со кои било поставено. Ако барањето е податоците да останат доверливи додека работното оптоварување не ги прими, VPN-от го задоволува само првиот сегмент, а останатите редови бараат транспорт на апликацијата, TLS на услугата или шифрирање на складиштето, конфигурирани и проверени одделно.

Чувај ги идентификаторите на врските, состојбите на тунелите и субјектите на сертификатите во записот. Кога некој ќе се врати на дизајнот по шест месеци, тие три артефакти одговараат на прашањето за границата за неколку минути наместо да ја почнат расправата одново од дијаграм.