AWS Site-to-Site VPN uz NAT Gateway: VGW vai Transit Gateway

Virtuālā privātā vārteja nevar nodot Site-to-Site VPN datplūsmu NAT gateway. Salīdziniet VGW un transit gateway ceļus un maršrutus, kas nepieciešami katram.

Pirmajā reizē visi zīmē vienu un to pašu shēmu: VPN uz VPC, NAT gateway uz internetu, gatavs. Taču AWS neatbalsta šo ceļu, kad VPN beidzas virtual private gateway, un kļūme ir tik klusa, ka komandas to pārbūvē vairāk nekā vienu reizi. Strādājošajam risinājumam vajag transit gateway, kas maina gateway un maršrutu tabulas abās pusēs. Pirms zīmēšanas salīdziniet abas formas.

Topoloģija, kas izskatās acīmredzama un netiek atbalstīta

AWS NAT gateway dokumentācija novelk līniju, kas pārsteidz ikvienu, kurš būvējis tikai viena VPC risinājumus: datplūsmu no Site-to-Site VPN savienojuma nevar maršrutēt uz NAT gateway caur virtual private gateway. Gateway tips, kurā beidzas VPN, nosaka, vai tulkošanas ceļš vispār pastāv. Kļūda saglabājas tāpēc, ka tuneļa statuss ir UP un EC2 instance tajā pašā subnet sasniedz internetu bez problēmām. Neviens no šiem novērojumiem nepārbauda salauzto virzienu.

Praksē pakete ierodas ar lokālā tīkla avota adresi un neatrod atbalstītu nākamo hop, kas to tulkotu. Atkarībā no tabulām tā tiek izmesta pie iziešanas robežas, un, tā kā tunelis paliek UP, kamēr instance tajā pašā subnet sasniedz internetu, kļūme tiek ziņota kā lokāla firewall problēma.

Virtual private gateway pret transit gateway

Virtual private gateway pieder vienam VPC. Tā pabeidz VPN, ievieto maršrutus šī VPC maršrutu tabulās un tur apstājas. Tai nav attachment modeļa, tāpēc tā nevar nodot datplūsmu citam VPC vai kopīgam iziešanas segmentam. Šis viena VPC tvērums ir viss ierobežojums, un neviens VPC iekšienē pievienots maršruts to nemaina.

Transit gateway ir reģionāls centrs, kurā VPN, katrs spoke VPC un kopīgo pakalpojumu VPC parādās kā attachment. Tam ir savas maršrutu tabulas, kas izvēlas, kurš attachment saņems doto prefix.

Šis centrs padara iespējamu centralizētu iziešanu: VPN nolaižas kā viens attachment, iziešanas VPC kā otrs, un transit gateway maršrutu tabula sūta uz internetu vērstus prefix no pirmā uz otro. Ar virtual private gateway nav otra attachment, kam kaut ko sūtīt, tāpēc risinājumu nevar pielāpot vēlāk.

Atbalstītais iziešanas ceļš, hop pa hop

Atsauces risinājumā ir pieci hop, un katra bultiņa ir maršrutēšanas lēmums, kas jums jākonfigurē. Datplūsma iziet no lokālā tīkla uz Site-to-Site VPN attachment, transit gateway tabula to pārsūta uz iziešanas VPC attachment, kur subnet tabula to sūta uz publisku NAT gateway. NAT gateway tulko avotu, un internet gateway iznes paketi ārā.

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

Divi dati izšķir, vai pēdējie hop darbosies. NAT gateway jābūt publiskam, ar elastic IP un maršrutu uz internet gateway, jo privāts NAT gateway tulko starp tīkliem un nekad nekļūst par interneta izeju.

Plānojiet vienu NAT gateway katram Availability Zone, kuru plānojat apkalpot, un katrai subnet tabulai jānorāda uz vietējo. Glabājiet transit gateway tabulu un VPC tabulas kā atsevišķus objektus savos pierakstos, jo viena izvēlas attachment, otra – resursu VPC iekšienē. Noklusējuma maršruts tikai vienā no tām atstāj pusi ceļa nedefinētu un rada daļējas kļūmes, kuras visgrūtāk attiecināt.

Tieši atgriešanās ceļā šie risinājumi cieš neveiksmi

NAT gateway saglabā stāvokli jau redzētām plūsmām, tāpēc atbildes uz izejošu savienojumu atgriežas bez jauna ienākošā noteikuma. Šī īpašība nepublicē lokālu pakalpojumu internetā, un izturēties pret to tā, it kā publicētu, nozīmē, ka komanda pavada dienu atkļūdojot savienojumu, kas nekad nebūtu izveidojies. Klienta iniciētai datplūsmai jāsaskaņo četri maršruti: lokālā politika, transit gateway tabula, iziešanas subnet tabula un NAT subnet tabula. Ja pēdējais iztrūkst, pieprasījums pamet ēku, kamēr atbilde mirst AWS iekšienē.

Pārbaudiet ar reālu klientu aiz VPN un apskatiet, kādu publisko avota adresi tas uzrāda. Ja tā ir NAT gateway elastic IP, tulkošana notiek; ja kas cits, jūs mērāt citu izeju.

Šīs kļūmes asimetrisko versiju ir vērts atpazīt agri. Ja viena Availability Zone NAT subnet tabulā ir atgriešanās maršruts uz klienta prefix, bet citā nav, jauni savienojumi izdodas vai neizdodas atkarībā no zonas, kurā nonāk plūsma, un modelis tiek nepareizi nolasīts kā nestabils internets. Salīdziniet subnet tabulas katram apkalpotajam apgabalam, nevis labojiet to, kurā tika atvērts pieteikums, jo trūkstošais maršruts ir visa kļūme un otrā pusē nekas nav jāmaina.

Kad skaidrs proxy ir labāks risinājums

HTTP proxy uz instances iziešanas VPC ir likumīga alternatīva un bieži lētāka. Klienti tiek konfigurēti to lietot, proxy atver savu savienojumu uz āru, un atgriešanās ceļš kļūst par tā problēmu, nevis simetriskas maršrutēšanas mīklu. Dažām lietojumprogrammām tas novērš lielāko daļu transit gateway darba. Tas dod arī žurnālus pa lietotājiem, ko NAT gateway nespēj radīt.

Tomēr tas nav caurspīdīgs. Viss, kas ignorē proxy iestatījumus, un katrs protokols, kas nav HTTP, neies šo ceļu.

Izvēle atkarīga no tā, ko jūsu lietojumprogrammas patiešām runā, un cik daudz identitātes vajag žurnālos. Kur tās runā HTTP, proxy iegūst savu vietu; kur vajag vispārīgu izeju patvaļīgiem protokoliem, transit gateway risinājums ir tas, ko AWS atbalsta. To izlemt iepriekš ir lētāk nekā atklāt pēc maršrutu tabulu izbūves.

Saistītie raksti