De ce AWS Client VPN aruncă traficul fără o rută potrivită

Punctul final transmite un pachet doar când tabelul de rute acoperă destinația. Citește rutele, declară prefixele cu for_each, verifică drumul de întoarcere.

Client VPN îi dă clientului o adresă, handshake-ul se încheie, iar conexiunea tot nu duce nicăieri. Înainte să atingi certificatele sau versiunile clientului, uită-te la tabelul de rute al punctului final. Un punct final AWS Client VPN transmite un pachet doar când una dintre rutele sale acoperă prefixul destinației; dacă nimic nu se potrivește, pachetul este aruncat la punctul final, iar gazda țintă nu vede niciodată un SYN.

Aceasta este o decizie de transmitere, nu de autentificare. Ea apare după ce tunelul este activ și după ce regulile de autorizare sunt evaluate, de aceea un certificat valid și un grup valid pot produce totuși o conexiune moartă.

Punctul final transmite doar ce acoperă tabelul său de rute

Fiecare rută este un CIDR de destinație plus subrețeaua care ar trebui să primească traficul. Punctul final compară destinația clientului cu lista, alege intrarea potrivită și trimite pachetul în subrețeaua asociată. Fără intrare nu există următorul salt.

Observă ce nu este ruta. Nu este o intrare în tabelul de rute al VPC-ului și nu autorizează nimic. Regulile de autorizare decid dacă un grup poate ajunge la o destinație; rutele decid dacă punctul final are unde să trimită pachetul. Ambele trebuie să fie de acord, iar ele eșuează cu simptome diferite, așa că a ghici care este stricată pierde o după-amiază.

Neconcordanța clasică este un VPC cu peering. Cineva adaugă o rută pentru 10.20.0.0/24 în timp ce gazda se află în 10.20.4.0/24, așa că adresa cade în afara fiecărei intrări. O captură pe partea clientului arată SYN repetate fără răspuns, iar jurnalele țintei nu arată absolut nimic.

Citește lista de rute înainte de certificat

Rutele punctului final sunt un obiect separat, așa că interogă-le direct în loc să citești tabelul VPC-ului:

aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 --query 'Routes[].{Dest:DestinationCidr,Target:TargetSubnet,Origin:Origin}'

Ia adresa exactă și lungimea prefixului de la clientul care eșuează, apoi verifică acoperirea caracter cu caracter. Se aplică potrivirea celui mai lung prefix, așa că o rută mai largă nu te salvează când una mai îngustă indică altundeva.

O resursă pe destinație cu for_each

Blocurile de rute scrise de mână se decalează în momentul în care cineva adaugă un prefix în consolă. Ține destinațiile într-o hartă și creează o resursă pe cheie, ca fiecare adăugare sau eliminare să rămână izolată.

variable "client_vpn_routes" {
  type = map(string)
  default = {
    "10.20.0.0/16"  = "subnet-0aa11bb22cc33dd44"
    "172.31.0.0/20" = "subnet-0aa11bb22cc33dd44"
  }
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_routes
  client_vpn_endpoint_id = var.client_vpn_endpoint_id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = each.value
  depends_on             = [aws_ec2_client_vpn_network_association.this]
}

Păstrează dependența de asocierea de rețea. O rută are nevoie de o subrețea asociată, așa că un apply care le creează pe amândouă trebuie să ordoneze asociația prima, iar fără acea referință Terraform este liber să încerce ruta prima. Apoi citește planul: numărul de adăugiri de rute trebuie să corespundă prefixelor adăugate. Dacă planul înlocuiește și punctul final, resursa punctului final este scrisă greșit, iar aplicarea ei deconectează fiecare client conectat.

Preluarea unui punct final pe care nu l-ai creat

Majoritatea echipelor moștenesc un punct final construit în consolă, de aceea nu există cod de rute. Nu ridica un al doilea punct final doar ca să aduci rute în Terraform.

Importă în schimb, sau trimite id-urile ca variabile și lasă obiectele moștenite neadministrate. Importul cere formatul de identificator pe care furnizorul îl documentează pentru fiecare tip de resursă; el codifică punctul final, prefixul destinației și subrețeaua țintă. Copiază șirul din documentația resursei în loc să îl compui din memorie, rulează un plan și așteaptă-te la nicio schimbare înainte de a adăuga ceva nou.

Urmărește pachetul în ordinea în care călătorește

Când ruta există și conexiunea tot eșuează, parcurge drumul în ordine în loc să ghicești la stratul superior.

  1. Rută: un prefix acoperă destinația și indică o subrețea asociată punctului final.
  2. Autorizare: o regulă de autorizare permite acea destinație pentru grupul utilizatorului. O rută singură nu acordă niciodată acces.
  3. Drum de întoarcere: tabelul de rute al subrețelei țintă trimite răspunsurile înapoi spre punctul final, iar grupul de securitate permite portul din pool-ul de adrese al clientului.
  4. Aplicație: deschide o conexiune TCP reală din client, apoi confirmă că jurnalele țintei arată adresa de sursă așteptată din pool.

Schimbă un prefix pe apply, recitește lista de rute după aceea și notează împreună destinația, regula care autorizează și drumul de întoarcere. Următoarea persoană care depanează o conexiune refuzată ar trebui să înceapă de la acel inventar, nu de la o teorie despre certificate.

Articole similare