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 услуге или шифровање складишта, одвојено конфигурисано и проверено.

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