AWS Site-to-Site VPN nei NAT-gateway: VGW tsjin Transit Gateway

Elkenien tekenet de earste kear itselde diagram: VPN yn 'e VPC, NAT-gateway út nei it ynternet, klear. Mar AWS stipet dat paad net as de VPN op in virtual private gateway einiget, en de flater is sa stil dat teams it mear as ien kear opnij bouwe. It ûntwerp dat wurket hat in transit gateway nedich, en dat feroaret de gateway en de rûtetabellen oan beide kanten. Ferlykje de twa foarmen foardat jo wat tekenje.

De topology dy't fanselssprekkend liket en net stipet wurdt

De dokumintaasje oer NAT-gateway fan AWS lûkt in line dy't elkenien ferrast dy't allinnich ûntwerpen mei ien VPC boud hat: ferkear fan in Site-to-Site VPN-ferbining kin net fia in virtual private gateway nei in NAT-gateway rûte wurde. It type gateway dêr't de VPN op einiget, beslút oft der überhaupt in oersetpaad is. De flater oerlibbet om't de tunnelstatus UP is en in EC2-ynstânsje yn itselde subnet it ynternet sûnder problemen berikt. Gjin fan beide waarnimmingen testet de stikene rjochting.

Yn 'e praktyk komt it pakket mei in boarneadres út it lokale net en fynt gjin stipet folgjend hop dat it oersette soe. Ofhinklik fan 'e tabellen wurdt it by de útgonggrins weilitten, en om't de tunnel UP bliuwt wylst in ynstânsje yn itselde subnet it ynternet berikt, wurdt de flater as in firewallprobleem by de lokaasje rapportearre.

Virtual private gateway tsjin transit gateway

In virtual private gateway heart by ien VPC. It einiget de VPN, ynstallearret rûtes yn 'e rûtetabellen fan dat VPC en hâldt dêr op. It hat gjin attachment-model, dus it kin ferkear net oan in oar VPC of oan in dield útgongsegmint oerjaan. Dy ien-VPC-omfang is de hiele beheining, en gjin rûte dy't jo yn 'e VPC tafoegje feroaret dat.

In transit gateway is in regionaal sintrum dêr't de VPN, elk spoke-VPC en in VPC foar dielde tsjinsten as attachments ferskine. It hat eigen rûtetabellen, dy't kieze hokker attachment in opjûne prefix kriget.

Dat sintrum makket sintralisearre útgong mooglik: de VPN lânet as ien attachment, it útgong-VPC as in oar, en in rûtetabel fan 'e transit gateway stjoert ynternet-rjochte prefixes fan 'e earste nei de twadde. Mei in virtual private gateway is der gjin twadde attachment om wat hinne te stjoeren, en dêrom kin it ûntwerp net efterôf reparearre wurde.

IT stipete útgongpaad, hop foar hop

it referinsje-ûntwerp hat fiif hops en elke pylk is in rûtebeslissing dy't jo konfigurearje moatte. Ferkear ferlit it lokale net yn 'e Site-to-Site VPN-attachment, de rûtetabel fan 'e transit gateway stjoert it troch nei de attachment fan it útgong-VPC, dêr't de subnettabel it nei in iepenbiere NAT-gateway stjoert. De NAT-gateway oerset de boarne en de internetgateway draacht it pakket nei bûten.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Twa details beslute oft de lêste hops wurkje. De NAT-gateway moat iepenbier wêze, mei in elastic IP en in rûte nei in internetgateway, om't in partikuliere NAT-gateway tusken netwurken oerset en nea in ynternetútgong wurdt.

Plan ien NAT-gateway per Availability Zone dy't jo betsjinje wolle, mei elke subnettabel dy't nei de lokale wiist. Hâld de transit-gateway-tabel en de VPC-tabellen as aparte objekten yn jo notysjes, om't de iene in attachment kiest en de oare in boarne binnen it VPC. In standertrûte yn mar ien fan beide lit de helte fan it paad ûnbepaald en produsearret de dielstige flaters dy't it minst te taskriuwen binne.

It werompaad is dêr't dizze ûntwerpen misse

In NAT-gateway ûnthâldt de tastân fan streams dy't it al sjoen hat, sadat antwurden op in útgeande ferbining weromkomme sûnder nije yngeande regel. Dy eigenskip publisearret gjin lokale tsjinst op it ynternet, en it sa behannelje kostet in team in dei debuggen fan in ferbining dy't nea ta stân komme soe. Foar ferkear dat de klant begjint, moatte fjouwer rûtes oerienkomme: it lokale belied, de transit-gateway-tabel, de útgong-subnettabel en de NAT-subnettabel. Mis de lêste en it fersyk ferlit it gebou wylst it antwurd yn AWS stjert.

Falidearje mei in echte klant efter de VPN en sjoch hokker iepenbier boarneadres it presintearret. As dat it elastic IP fan 'e NAT-gateway is, bart der oersetting; as it wat oars is, mjitte jo in oare útgong.

De asymmetryske ferzje fan dizze flater is it wurdich betiid te kennen. As de NAT-subnettabel fan ien Availability Zone de weromrûte nei it klantprefix hat en in oare net, slagje of misse nije ferbiningen ôfhinklik fan 'e sône dêr't de stream yn lânet, en it patroan wurdt ferkeard lêzen as ûnstjoer ynternet. Ferlykje de subnettabellen foar elke sône dy't jo betsjinje ynstee fan dy te reparearjen dêr't it ticket iepene waard, om't de ûntbrekkende rûte de hiele flater is en oan 'e oare kant neat feroare hoecht te wurden.

Wannear't in eksplisite proxy it bettere ûntwerp is

In HTTP-proxy op in ynstânsje yn it útgong-VPC is in legitym alternatyf en faak goedkeaper. Klanten wurde konfigurearre om it te brûken, de proxy iepenet syn eigen ferbining nei bûten, en it werompaad is syn probleem ynstee fan in symmetrysk-rûte-puzel. Foar in pear applikaasjes ferwideret dat it measte wurk fan 'e transit gateway. It jout ek logging per brûker dy't in NAT-gateway net meitsje kin.

IT is lykwols net transparant. Alles dat proxy-ynstellingen negearret, en elk protokol dat gjin HTTP is, sil dat paad net folgje.

De kar hinget ôf fan wat jo applikaasjes echt prate en hoefolle identiteit jo yn 'e logs nedich hawwe. Dêr't se HTTP prate, fertsjinnet de proxy syn plak; dêr't jo algemiene útgong foar willekeurige protokollen nedich hawwe, is it transit-gateway-ûntwerp datjinge dat AWS stipet. Dat foarôf beslute is goedkeaper as it te ûntdekken nei't de rûtetabellen boud binne.