Miksi AWS Client VPN pudottaa liikenteen ilman vastaavaa reittiä

Päätepiste välittää paketin vain, kun sen reittitaulu kattaa kohteen. Lue reitit, ilmoita etuliitteet for_eachilla, varmista paluureitti.

Client VPN antaa asiakkaalle osoitteen, kättely valmistuu, ja yhteys ei silti johda mihinkään. Ennen kuin kosket varmenteisiin tai asiakasversioihin, katso päätepisteen omaa reittitaulua. AWS Client VPN -päätepiste välittää paketin vain, kun jokin sen reiteistä kattaa kohde-etuliitteen; jos mikään ei täsmää, paketti hylätään päätepisteessä eikä kohdeisäntä näe koskaan SYN:iä.

Tämä on välityspäätös, ei todennuspäätös. Se tehdään sen jälkeen, kun tunneli on pystyssä ja kun valtuutussäännöt on arvioitu, siksi kelvollinen varmenne ja kelvollinen ryhmä voivat silti tuottaa kuolleen yhteyden.

Päätepiste välittää vain sen, minkä sen reittitaulu kattaa

Jokainen reitti on kohde-CIDR plus aliverkko, jonka pitäisi vastaanottaa liikenne. Päätepiste vertaa asiakkaan kohdetta tähän luetteloon, valitsee täsmäävän merkinnän ja lähettää paketin siihen liitettyyn aliverkkoon. Ei merkintää tarkoittaa ei seuraavaa hyppyä.

Huomaa, mitä reitti ei ole. Se ei ole VPC:n reittitaulun merkintä eikä valtuuta mitään. Valtuutussäännöt päättävät, saako ryhmä saavuttaa kohteen; reitit päättävät, onko päätepisteellä jokin paikka, johon paketin voi lähettää. Molempien on täsmättävä, ja ne epäonnistuvat eri oireilla, joten arvailu siitä, kumpi on rikki, tuhlaa iltapäivän.

Klassinen epäsuhta on peerattu VPC. Joku lisää reitin osoitteelle 10.20.0.0/24, vaikka isäntä asuu osoitteessa 10.20.4.0/24, joten osoite jää jokaisen merkinnän ulkopuolelle. Asiakaspuolen kaappaus näyttää toistuvia SYN-paketteja ilman vastausta, eikä kohteen lokeissa näy yhtään mitään.

Lue reittiluettelo ennen varmennetta

Päätepisteen reitit ovat oma objektinsa, joten kysy niitä suoraan sen sijaan, että lukisit VPC:n taulukkoa:

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

Ota tarkka osoite ja etuliitteen pituus epäonnistuvasta asiakkaasta ja tarkista kattavuus merkki merkiltä. Pisimmän etuliitteen täsmäytys pätee, joten leveämpi reitti ei pelasta sinua, kun kapeampi osoittaa muualle.

Yksi resurssi kohdetta kohti for_eachilla

Käsin kirjoitetut reittilohkot ajautuvat heti, kun joku lisää etuliitteen konsolissa. Pidä kohteet kartassa ja luo yksi resurssi avainta kohti, jotta jokainen lisäys tai poisto pysyy eristettynä.

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]
}

Säilytä riippuvuus verkkoliitokseen. Reitti tarvitsee liitetyn aliverkon, joten apply, joka luo molemmat, on järjestettävä liitos ensin, ja ilman tuota viitettä Terraform saa yrittää reittiä ensin. Lue sitten suunnitelma: reittilisäysten määrän pitäisi vastata lisäämiäsi etuliitteitä. Jos suunnitelma korvaa myös päätepisteen, päätepisteen resurssi on kirjoitettu väärin, ja sen soveltaminen katkaisee jokaisen yhdistetyn asiakkaan.

Sellaisen päätepisteen käyttöönotto, jota et luonut

Useimmat tiimit perivät konsolissa rakennetun päätepisteen, minkä vuoksi reittikoodia ei ole. Älä pystytä toista päätepistettä vain saadaksesi reitit Terraformiin.

Importoi sen sijaan, tai välitä id:t muuttujina ja jätä perityt objektit hallitsemattomiksi. Import vaatii tunnisteen muodon, jonka tarjoaja dokumentoi jokaiselle resurssityypille; se koodaa päätepisteen, kohde-etuliitteen ja kohdealiverkon. Kopioi tuo merkkijono resurssin dokumentaatiosta sen sijaan, että kokoaisit sen muistista, aja suunnitelma ja odota, ettei muutoksia tule ennen kuin lisäät jotain uutta.

Jäljitä paketti siinä järjestyksessä, jossa se kulkee

Kun reitti on olemassa ja yhteys silti epäonnistuu, käy polku läpi järjestyksessä sen sijaan, että arvailisit ylimmällä kerroksella.

  1. Reitti: etuliite kattaa kohteen ja osoittaa aliverkkoon, joka on liitetty päätepisteeseen.
  2. Valtuutus: valtuutussääntö sallii tuon kohteen käyttäjän ryhmälle. Pelkkä reitti ei koskaan myönnä pääsyä.
  3. Paluureitti: kohdealiverkon reittitaulu lähettää vastaukset takaisin päätepistettä kohti, ja tietoturvaryhmä sallii portin asiakkaan osoitepoolista.
  4. Sovellus: avaa todellinen TCP-yhteys asiakkaasta ja varmista sitten, että kohteen lokit näyttävät odotetun lähdeosoitteen poolista.

Muuta yhtä etuliitettä per apply, lue reittiluettelo sen jälkeen uudelleen ja kirjaa kohde, valtuuttava sääntö ja paluureitti yhdessä. Seuraavan, joka selvittää hylättyä yhteyttä, pitäisi aloittaa tuosta luettelosta, ei varmenneteoriasta.

Aiheeseen liittyvät artikkelit