Puncte:1

CIDR-uri AWS VPC atât în ​​10.0.0.0/8, cât și în 192.168.0.0/16

drapel za

Am VPC A cu CIDR 10.A.0.0/16 și VPC B cu CIDR 10.B.0.0/16. Am VPC A și B peered și actualizat tabelele de rute și de pe un server în 10.B.0.0/16 poate ping un server 10.A.0.0/16 si invers.

Aplicațiile de pe VPC A folosesc și unele IP-uri în 192.168.0.0/16 gamă. Nu este ceva ce pot schimba cu ușurință, dar trebuie să pot ajunge 192.168.0.0/16 pe VPC A de la VPC B. VPC A este folosit pentru un cluster kubernetes mai vechi care folosește project-calico. Nodurile de lucru (instanțele ec2) primesc IP-uri în blocul CIDR VPC 10.A.0.0/16 dar rețeaua calico este setată cu setarea CIDR de cluster 192.168.0.0/16 iar IP-urile pod de pe acele noduri de lucru sunt alocate în acel interval. Cel mai nou cluster este un cluster EKS, iar IP-urile podului sunt atribuite din intervalul CIDR al VPC-ului, 10.B.0.0/16. În perioada de tranziție, am analizat VPC-urile celor două clustere. Există o aplicație Elixir distribuită care rulează, iar podurile formează un cluster Erlang, ajungând unul la altul prin adresa lor IP a podului. Cu grupul meu de peering actual, podurile A pot ajunge atât la podurile A, cât și la B, dar podurile de cluster B pot ajunge doar la B (datorită 192.168.0.0/16 IP-urile nu sunt accesibile.

Am încercat să adaug 192.168.0.0/16 la tabelul de rute utilizat pentru VPC B și setarea țintei conexiunii peered. Asta nu merge, cred pentru că 192.168.0.0/16 nu se află în blocul CIDR pentru VPC A.

Nu pot adăuga 192.168.0.0/16 ca CIDR secundar în VPC A deoarece este restricționat. Vedea CIDR blochează restricțiile de asociere și întrebare legată. Înțeleg că este restricționat, dar de ce este restricționat? RFC1918 nu pare să spună nimic împotriva utilizării mai multor spații de adrese private.

De asemenea, am încercat să fac un Transit Gateway, să atașez ambele VPC-uri și să adaug o rută statică la Transit Gateway Route Table pentru 192.168.0.0/16 care vizează atașamentul VPC A. Dar tot nu se poate ajunge la acest interval din interiorul VPC B.

Tabel de rute

Tabelul de rute pentru subrețeaua privată pentru VPC A

10.A.0.0/16 local
10.B.0.0/16 pcx-[VPC A - VPC B conexiune peering]
0.0.0.0/0 nat-[gateway pentru cluster A]

Tabel de rute pentru subrețeaua privată pentru VPC B

10.B.0.0/16 local
10.A.0.0/16 pcx-[VPC A - VPC B conexiune peering]
192.168.0.0/16 pcx-[VPC A - VPC B conexiune peering]
0.0.0.0/0 nat-[gateway pentru cluster B]

Acest lucru nu funcționează, desigur, pentru că 192.168.0.0/16 nu se află în blocul CIDR al VPC A și nici nu poate fi adăugat.

Dacă primesc un shell pe un Nod A, pot face ping a 192.168... pod și pot da ping a 10.B.0.0 păstaie. Dar dintr-un shell de pe Nodul B pot face ping doar a 10.B.0.0 păstaie.

Există o altă modalitate de a privi ambele 10.0.0.0/8 și 192.168.0.0/16 Blocuri CIDR pe același VPC?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.