AWS Client VPN ja jaettu tunneli: mitkä reitit kannattaa julkaista

Konsoli tarjoaa jaetun tunnelin kytkimen, joten päätös tuntuu valintaruudulta. Se ei ole. Asiakkaalle todella saapuva asia on päätepisteen julkaistu reittijoukko, ja tuo luettelo päättää, mitkä yksityiset etuliitteet käyttävät tunnelia, jääkö yleinen internetyhteysliikenne paikalliseksi vai poistuuko se AWS:n kautta, ja mihin resolveriin asiakas voi vielä puhua. Kolme kysymystä ratkaisevat suunnittelun, ja kuhunkin voi vastata huonosti, vaikka yhteys silti onnistuu.

Jaetun tunnelin lippu ei ole kohdeluettelo

AWS kuvaa jaetun tunnelin päätepisteen reittien lisäämisenä asiakkaan reittitauluun yhteyden muodostuksen yhteydessä. Yksityisen VPC:n reitti rajoittaa tunnelin tuohon kohteeseen; kaikki muu seuraa asiakkaan tavallista polkua. Oletusreitti on eri ohje, jolla on eri vaikutus, minkä vuoksi jaetun tunnelin dokumentaatio varoittaa julkaisemasta 0.0.0.0/0:aa tätä tilaa varten määritetyssä päätepisteessä: se yleensä rikkoo yhteyden sen sijaan että laajentaisi sitä. Päätepisteen reittitaulu on käytäntö, ja asiakkaan reittitaulu on tulos, jonka voit tarkistaa.

Lue päätepisteen reittitaulu ja asiakkaan asennetut reitit yhdessä. Nimike kuvaa aikomuksen; reitit kuvaavat, mitä tapahtuu.

Ensimmäinen päätös: pitäisikö yleisen internetyhteysliikenteen jäädä paikalliseksi?

Jos selailun on tarkoitus käyttää käyttäjän omaa yhteyttä, julkaise vain ne yksityiset kohteet, joita työ tarvitsee, ja lopeta siihen. Älä lisää internetreittiä siksi, että täystunnelin opas sisälsi yhden, äläkä oleta, että ylimääräinen reitti parantaa turvallisuutta. Se muuttaa polun, ei lisää käytäntöä, ja maksaa yleensä viivettä, jota et budjetoinut.

Jos internetyhteysliikenteen on tarkoitus poistua AWS:n kautta, rakenna dokumentoitu internetyhteyden arkkitehtuuri: päätepisteen reitti, valtuutussäännöt, liitetyn aliverkon polku, tietoturvakäytäntö ja toimiva ylävirran ulostulo. Pelkkä oletusreitti ei tarjoa mitään näistä.

Toinen päätös: mitkä yksityiset etuliitteet ja kenen valtuuttamana?

Julkaise pienin kohdejoukko, joka palvelee todellista työkuormaa, ja varmista, että jokainen liitetty aliverkko voi reitittää niihin. Päätepisteen reittikohde ja aliverkon VPC-reititys ovat eri kerroksia, eikä yhdessä oleva reitti ole todiste toisesta. Valtuutus on jälleen erillinen: kohde voi olla saavutettavissa ja silti hylätty, koska asiakkaan ryhmällä ei ole sääntöä, joka sallii sen.

Yhden onnistuneen istunnon testaaminen todistaa yhden polun. Tarkista jokainen liitetty aliverkko, sillä myöhemmin lisätty aliverkkoliitos on juuri se paikka, jossa puuttuva reitti yleensä sijaitsee.

Kun kohteen on oltava saavutettavissa nimellä, huomaa, että seuraava kysymys on nimien ratkaisu, ei reitti.

Kolmas päätös: mikä resolver seuraa tunnelia?

Asiakas voi saada DNS-palvelimen, joka on saavutettavissa vain VPN:n kautta, ja tämä resolver toimii vain, jos sen osoite on itse valtuutetun reitin sisällä. Tarkista molemmat puolet: resolverin osoite seuraa julkaistua reittiä ja palvelin vastaa nimiin, joita sovellus kysyy. Pyyntö, joka onnistuu osoitteella mutta epäonnistuu isäntänimellä, viittaa nimeämiseen, ei reititykseen, ja tunnelin vianetsintä tässä tapauksessa tuhlaa iltapäivän.

Julkisten nimien pitäisi ratketa kuten ennen yhteyttä, mikä on toinen syy olla täsmällinen siinä, mitä julkaiset.

Muuta reittijoukkoa ja tarkista sitten molemmat maailmat

AWS dokumentoi, että reittien muuttaminen jaetun tunnelin päätepisteessä nollaa asiakasyhteydet. Suunnittele muutos tämä mielessä: ota se käyttöön, yhdistä uudelleen tuetulla asiakkaalla ja lue asennetut reitit uudelleen sen sijaan, että luottaisit ennen muokkausta käyttöön otettuun tilaan. Vanhentunut käyttöön otettu tila on yleisin syy siihen, että oikea muutos näyttää rikkinäiseltä.

Hyväksy suunnittelu vain, kun yksi yksityinen resurssi ja yksi julkinen kohde käyttäytyvät tarkoitetulla tavalla, nimellä ja osoitteella, niissä osoiteperheissä, joita todella tuet. Tunneli, joka todentaa, ei ole sama asia kuin tunneli, joka jakaa oikein.

Kirjoita reittiluettelo runbookiin perustelujen viereen, jotta seuraava henkilö erottaa tahallisen poissulkemisen unohdetusta.