AWS Client VPN vai bastions, lai sasniegtu peering VPC
Abi ceļi darbojas, bet tie lūzt dažādās vietās. Salīdziniet endpoint maršrutus, atgriešanas maršrutēšanu un trīs gadījumus, kad bastions ir godīgā robeža.
Viens Client VPN endpoint var sasniegt VPC, kas ir peering savienojumā ar tā saistīto VPC, un, lai to padarītu likumīgu, jums nav vajadzīgs bastions. Izvēle, ko ir vērts izdarīt, ir vieta, kur satiksme maina rokas: endpoint maršruts, kas nolaižas asociācijas apakštīklā un šķērso peering savienojumu, vai host datorā peering VPC, kas beidz sesiju. Abi ceļi darbojas, un tie neizdodas dažādās vietās, tāpēc lēmums ir par īpašumtiesībām un auditu, nevis par to, ko atļauj AWS. Lūk, kā es izvēlos starp tiem, un četri ieraksti, kas padara maršrutēto ceļu darbspējīgu.
Divi ceļi, viens endpoint, dažādi īpašnieki
Maršrutētajā ceļā klienta satiksme sasniedz endpoint, tiek pārtulkota uz Client VPN tīkla saskarnes adresi asociācijas apakštīklā un atstāj šo apakštīklu pa peering savienojumu no A uz B. VPC B nepabeidz nevienu VPN sesiju; tas redz parastu satiksmi no VPC A, tāpēc tā atgriešanas maršruts norāda uz VPC A, nevis uz klientu kopu.
Bastiona ceļā klients vispirms sasniedz host datoru. Bastions A joprojām ļauj pēdējam lēcienam šķērsot peering savienojumu, tāpēc jūs saglabājat peering darbu un pievienojat sesiju. Bastionam B arī vajag ceļu no klienta, un, ja šis ceļš ir tas pats endpoint maršruts, jums ir maršrutētais dizains plus viens lēciens. Bastions noņem darbu tikai tad, kad tas jau pastāv, jau ir apstiprināts, un lieta aiz tā prasa sesijas robežu, nevis tīkla robežu.
Četri ieraksti padara maršrutēto ceļu darbspējīgu
AWS dokumentē šo scenāriju Client VPN how-it-works lapā, un praksē tas izpaužas kā četri ieraksti, kas pieder divām vai trim komandām. Diapazoni ir ilustratīvi; peering diapazonam jābūt unikālam, un atgriešanas diapazonam jāatbilst jūsu plānam.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
Maršruts un atļauja ir atsevišķas kontroles. Pareizs endpoint maršruts bez atbilstoša autorizācijas noteikuma klientam neko nedod; autorizācijas noteikums galamērķim, ko endpoint nevar maršrutēt, dod tam melnu caurumu. Abiem jānosauc viens un tas pats diapazons.
Endpoint maršruts norāda uz apakštīklu paša endpoint VPC, nekad uz peering savienojumu. VPC maršrutu tabulas norāda uz peering savienojumu, nekad uz instanci vai saskarni. Vērtības kopēšana starp abiem tiek saglabāta bez iebildumiem un neko nemaršrutē.
Tā kā asociācijas apakštīkls pārtulko klienta avotu, B ir jāmaršrutē atpakaļ uz VPC A, nevis uz klientu kopu. Klientu diapazona sūtīšana pa peering savienojumu izskatās simetriska, iztur pārskatīšanu un klusi neizdodas, jo B nekad neredz paketi ar klienta avotu.
Drošības grupas un pēdējais atļaujas metrs
Maršrutēšana ienes paketes B; B joprojām izlemj. Aktīvam peering savienojumam tajā pašā reģionā drošības grupa B var atsaukties uz grupu, kas piemērota Client VPN asociācijai, kas notur noteikumu šauru un iztur adrešu izmaiņas. Kur grupas atsauce nav iespējama, skaidri atļaujiet asociācijas apakštīkla diapazonu, nevis paplašiniet līdz 0.0.0.0/0, kas maršrutēšanas kļūdu pārvērš neizskaidrojamā taimautā.
Pēc tam pārbaudiet to, ko maršrutēšana nekad neaiztiek: tīkla ACL abos apakštīklos, lietojumprogrammas atļauto sarakstu vai token auditoriju, un DNS. Peering nekopē privātās hostētās zonas, tāpēc klēpjdators var turēt strādājošu maršrutu uz adresi, ko tas nevar atrisināt, un peering savienojums nepievieno uzticību sertifikātam. Novirziet endpoint uz risinātāju, kas atbild par B, pēc tam apstipriniet, ka privātais nosaukums un sertifikāts sakrīt.
Kad bastions ir godīgā atbilde
Es paturu trīs trigerus apzinātai bastiona izvēlei. Peering VPC pieder komandai, kas nepievienos atgriešanas maršrutu jūsu diapazonam vai nepieņems grupas atsauci. Piekļuve jāapstiprina vai jāreģistrē katrai sesijai, un lietojumprogramma to nevar pati iznest. Vai arī pēdējam lēcienam jāpaliek B iekšienē, jo pakalpojums tiek atrisināts tikai tur un tā TLS identitāte ir piesaistīta iekšējam nosaukumam.
Nekas no tā nav apiet to, ka peering nav transitīvs. Netransitivitāte ierobežo to, ko drīkst darīt B resursi: tie nevar izmantot A kā tranzītu uz trešo VPC, ar kuru A ir peering. Tas nekad nav nozīmējis, ka VPN lietotājs nevar sasniegt tieši peering VPC, un bastions, kas uzbūvēts, lai apietu šo nepareizo lasījumu, ir host dators, kas jālabo bez iemesla.
Pretējā kļūda laika gaitā izmaksā vairāk: izvediet katru komandu caur vienīgo jau esošo bastionu, pēc tam atklājiet, ka tā drošības grupa, maršrutu tabula un labošanas logs ir ražošanas atkarība. Pierakstiet, kuram trigerim host dators kalpo, un izņemiet to no ekspluatācijas, kad trigeris pazūd.
Transit Gateway un vairākas asociācijas maina aritmētiku
Ja endpoint ir pievienots tieši Transit Gateway, nevis apakštīklam, modelis mainās: klienti vairs netiek pārtulkoti uz saskarnes adresi asociācijas apakštīklā, un gateway maršrutu tabulām jānes klientu diapazons plus pievienojums, kas ved uz peering VPC. Tas ir tīrāk mērogā, bet darbs pārvietojas no četriem ierakstiem uz gateway maršrutu tabulām.
Vairākas asociācijas reizina pārbaudes. Endpoint maršruts pieder endpointam, tomēr katram asociācijas apakštīklam vajag maršrutu tabulu ar īstu peering nākamo lēcienu. Sesija var izdoties caur vienu asociāciju, kamēr citai nav atgriešanas ceļa, tāpēc pārbaudiet katru.
Pārbaudes secība, kas ātri atrod lūzumu
Izpildiet šos secībā; katrs solis var izdoties, kamēr nākamais neizdodas, un klienta taimauts gandrīz nekad nepasaka, kurš salūza.
- Atrisiniet lietojumprogrammas nosaukumu no klienta un pārbaudiet, vai adrese ir peering diapazonā.
- Izveidojiet savienojumu, pēc tam nolasiet endpoint savienojumu žurnālu asociācijai, kas beidza sesiju.
- Šajā asociācijas apakštīklā apstipriniet, ka maršrutu tabula novirza peering diapazonu uz aktīvu peering savienojumu.
- B resursu apakštīklā apstipriniet atgriešanas ierakstu saskarnes diapazonam un atbilstošus grupas noteikumus.
- Pārbaudiet vienu atļautu darbību un vienu resursu, kam jāpaliek nesasniedzamam; otrais noķer atkļūdošanas paliekas.
- Pēc jebkuras split-tunnel maršruta izmaiņas savienojieties no jauna, jo darbojošs tunelis neuzņems jaunu maršrutu kopu.
Divi simptomi ir vērts iegaumēt. SYN, kas sasniedz B bez atbildes, gandrīz vienmēr ir trūkstošais atgriešanas maršruts. Savienojums, kas pabeidzas un pēc tam tiek atiestatīts, parasti ir grupa, ACL vai lietojumprogramma. Neviens no tiem neparādās endpoint žurnālā kā cēlonis, tāpēc turiet četrus ierakstus ar īpašnieku blakus katram.
Ja neviens no trim trigeriem nav spēkā, pabeidziet maršrutēto ceļu un pierakstiet šos četrus ierakstus. Ja viens ir spēkā, paturiet bastionu tikai šai robežai un atstājiet endpoint maršrutu pakalpojumiem, kuriem priekšā nav vajadzīga sesija.