AWS Site-to-Site VPN-ը NAT Gateway-ին. VGW թե՞ Transit Gateway

Բոլորը առաջին անգամ նույն դիագրամն են նկարում՝ VPN՝ VPC, NAT gateway՝ ինտերնետ, վերջ։ Բայց AWS-ը չի աջակցում այդ ուղուն, երբ VPN-ն ավարտվում է virtual private gateway-ում, և ձախողումն այնքան լուռ է, որ թիմերը այն վերակառուցում են մեկից ավելի անգամ։ Աշխատող լուծումը պահանջում է transit gateway, ինչը փոխում է gateway-ը և route-ների աղյուսակները երկու կողմում։ Նախքան նկարելը համեմատեք երկու ձևերը։

Տոպոլոգիան, որը թվում է ակնհայտ և աջակցված չէ

AWS-ի NAT gateway-ի փաստաթղթերը գծում են մի գիծ, որը զարմացնում է բոլորին, ովքեր կառուցել են միայն մեկ VPC-ով լուծումներ։ Site-to-Site VPN կապից երթևեկությունը չի կարող ուղղորդվել NAT gateway-ին virtual private gateway-ի միջոցով։ Gateway-ի տեսակը, որում ավարտվում է VPN-ը, որոշում է՝ արդյոք ընդհանրապես գոյություն ունի թարգմանության ուղի։ Սխալը պահպանվում է, որովհետև թունելի կարգավիճակը UP է, և նույն subnet-ի EC2 instance-ը առանց խնդիրների հասնում է ինտերնետ։ Այս դիտարկումներից ոչ մեկը չի ստուգում կոտրված ուղղությունը։

Գործնականում փաթեթը գալիս է տեղական ցանցի աղբյուրի հասցեով և չի գտնում աջակցվող հաջորդ hop, որը կթարգմաներ այն։ Կախված աղյուսակներից՝ այն դեն է նետվում ելքի սահմանին, և քանի որ թունելը մնում է UP, մինչ նույն subnet-ի instance-ը հասնում է ինտերնետ, ձախողումը հաղորդվում է որպես տեղական firewall-ի խնդիր։

Virtual private gateway-ը՝ transit gateway-ի դիմաց

Virtual private gateway-ը պատկանում է մեկ VPC-ի։ Այն ավարտում է VPN-ը, route-ներ տեղադրում այդ VPC-ի աղյուսակներում և կանգ առնում այնտեղ։ Այն attachment-ի մոդել չունի, ուստի չի կարող երթևեկությունը հանձնել այլ VPC-ի կամ ընդհանուր ելքի սեգմենտի։ Այս մեկ VPC-ի սահմանն է ամբողջ սահմանափակումը, և VPC-ի ներսում ավելացված ոչ մի route այն չի փոխում։

Transit gateway-ը տարածաշրջանային կենտրոն է, որտեղ VPN-ը, յուրաքանչյուր spoke VPC-ն և ընդհանուր ծառայությունների VPC-ն հայտնվում են որպես attachment-ներ։ Այն ունի իր route-ների աղյուսակները, որոնք ընտրում են, թե որ attachment-ը կստանա տրված prefix-ը։

Այդ կենտրոնն է, որ հնարավոր է դարձնում կենտրոնացված ելքը։ VPN-ը վայրէջք է կատարում որպես մեկ attachment, ելքի VPC-ն՝ որպես մյուս, և transit gateway-ի route-ների աղյուսակը ինտերնետ ուղղված prefix-ները փոխանցում է առաջինից երկրորդին։ Virtual private gateway-ի դեպքում երկրորդ attachment չկա, ուստի լուծումը հնարավոր չէ հետագայում կարկատել։

Աջակցվող ելքի ուղին՝ քայլ առ քայլ

Հղման լուծումն ունի հինգ hop, և յուրաքանչյուր սլաք route-ավորման որոշում է, որը պետք է կարգավորեք։ Երթևեկը տեղական ցանցից անցնում է Site-to-Site VPN attachment, transit gateway-ի աղյուսակը փոխանցում է այն ելքի VPC-ի attachment-ին, որտեղ subnet-ի աղյուսակը ուղարկում է այն հանրային NAT gateway։ NAT gateway-ը թարգմանում է աղբյուրը, և internet gateway-ը դուրս է տանում փաթեթը։

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

Երկու մանրամասնորոշում են՝ աշխատու՞մ են վերջին hop-երը։ NAT gateway-ը պետք է հանրային լինի՝ elastic IP-ով և route դեպի internet gateway, քանի որ մասնավոր NAT gateway-ը թարգմանում է ցանցերի միջև և երբեք չի դառնում ինտերնետի ելք։

Պլանավորեք մեկ NAT gateway յուրաքանչյուր Availability Zone-ի համար, որը պատրաստվում եք սպասարկել, և յուրաքանչյուր subnet-աղյուսակ թող ցույց տա տեղականին։ Ձեր նշումներում transit gateway-ի աղյուսակը և VPC-ի աղյուսակները պահեք որպես առանձին օբյեկտներ, որովհետև մեկը ընտրում է attachment, մյուսը՝ VPC-ի ներսի ռեսուրս։ Default route-ը դրանցից միայն մեկում թողնում է ուղու կեսը չսահմանված և առաջացնում այն մասնակի ձախողումները, որոնք ամենադժվարն է վերագրել։

Հենց վերադարձի ուղու վրա են այս լուծումները ձախողվում

NAT gateway-ը պահում է վիճակ արդեն տեսած հոսքերի համար, ուստի ելքային կապի պատասխանները վերադառնում են առանց նոր ներգնա կանոնի։ Այդ հատկությունը տեղական ծառայություն չի հրապարակում ինտերնետում, և դա այնպես դիտարկելը թիմին մեկ օր արժենում է մի կապի վրիպազերծման վրա, որը երբեք չէր հաստատվի։ Հաճախորդից սկսվող երթևեկի համար չորս route պետք է համաձայնեն՝ տեղական քաղաքականությունը, transit gateway-ի աղյուսակը, ելքի subnet-ի աղյուսակը և NAT subnet-ի աղյուսակը։ Բաց թողեք վերջինը, և հարցումը դուրս է գալիս շենքից, մինչ պատասխանը մահանում է AWS-ի ներսում։

Ստուգեք VPN-ի հետևում գտնվող իրական հաճախորդով և տեսեք, թե ինչ հանրային աղբյուրի հասցե է ներկայացնում։ Եթե դա NAT gateway-ի elastic IP-ն է, թարգմանություն տեղի է ունենում. եթե այլ բան է, դուք այլ ելք եք չափում։

Այս ձախողման ասիմետրիկ տարբերակը արժե վաղ ճանաչել։ Երբ մի Availability Zone-ի NAT subnet-աղյուսակում կա վերադարձի route դեպի հաճախորդի prefix, իսկ մյուսում՝ ոչ, նոր կապերը հաջողվում կամ ձախողվում են՝ կախված այն գոտուց, որտեղ ընկնում է հոսքը, և օրինաչափությունը սխալ կերպով կարդացվում է որպես անկայուն ինտերնետ։ Համեմատեք subnet-աղյուսակները ձեր սպասարկած յուրաքանչյուր գոտու համար, փոխանակ ուղղեք այն, որտեղ բացվել է ticket-ը, որովհետև բացակայող route-ը ամբողջ խափանումն է, և մյուս կողմում ոչինչ պետք չէ փոխել։

Երբ բացահայտ proxy-ն ավելի լավ լուծում է

Ելքի VPC-ի instance-ի վրա HTTP proxy-ն օրինական այլընտրանք է և հաճախ ավելի էժան։ Հաճախորդները կարգավորվում են օգտագործել այն, proxy-ն բացում է իր կապը դուրս, և վերադարձի ուղին նրա խնդիրն է, այլ ոչ թե համաչափ route-ավորման հանելուկ։ Փոքր թվով հավելվածների համար դա վերացնում է transit gateway-ի աշխատանքի մեծ մասը։ Այն նաև տալիս է օգտվողական մակարդակի գրանցում, որը NAT gateway-ը չի կարող արտադրել։

Սակայն այն թափանցիկ չէ։ Ամեն ինչ, որ անտեսում է proxy-ի կարգավորումները, և յուրաքանչյուր արձանագրություն, որը HTTP չէ, այդ ուղով չեն գնա։

Ընտրությունը կախված է նրանից, թե ինչ են իրականում խոսում ձեր հավելվածները և որքան ինքնություն է պետք գրանցումներում։ Որտեղ նրանք խոսում են HTTP, proxy-ն արժանանում է իր տեղին. որտեղ պետք է ընդհանուր ելք կամայական արձանագրությունների համար, transit gateway-ի լուծումն է այն, ինչին AWS-ը աջակցում է։ Դա նախապես որոշելն ավելի էժան է, քան route-ների աղյուսակները կառուցելուց հետո հայտնաբերելը։