Säilytä VPN-asiakkaiden IP-osoitteet tai SNAT:aa ne pilven rajalla

VPN-asiakkaan osoitteen säilyttäminen sovellukseen asti tekee jokaisesta lokirivistä ja jokaisesta sallittujen luettelon merkinnästä samaa tarkoittavan. Sen uudelleenkirjoittaminen pilven reunalla tekee reititystaulusta yksinkertaisemman ja lokit vähemmän hyödyllisiksi. Kumpikaan valinta ei ole itsessään väärä, ja sen ratkaiseva argumentti koskee harvoin suorituskykyä. Kolme ehtoa ratkaisee: täytyykö sovelluksen tietää, kuka ihminen yhdisti, hyväksyykö pilven kudos lähteen, jonka aiot lähettää, ja kuka on valmis ottamaan paluureitin vastuulleen jälkeenpäin.

Kolme ehtoa ratkaisee

Aloita sovelluksen vaatimuksesta, älä verkkokaaviosta. Jos valtuutus tai auditointi riippuu yksittäisen asiakkaan osoitteesta, sen säilyttäminen on toiminnallinen vaatimus ja kääntäminen on regressio. Jos sovelluksen tarvitsee vain tietää, että liikenne saapui etäkäyttöpolkua pitkin, käännetty osoite riittää ja on paljon halvempi ylläpitää.

Toinen ehto on mekaaninen. Virtuaaliverkko ei luota automaattisesti pakettiin, joka väittää osoitetta, jota ei ole annettu lähettävälle rajapinnalle. Useimmat pilvikudokset valvovat sitä eri tavoin ja eri nimillä, ja suunnittelu, joka jättää sen huomiotta, näyttää kaaviossa oikealta ja häviää tuotannossa hiljaa.

Kolmas on organisatorinen. Lähteiden säilyttäminen tarkoittaa, että sovelluksen aliverkon reititystaulun on osoitettava takaisin yhdyskäytävään asiakkaan etuliitteen osalta, ja jokaisen tiimin, joka lisää aliverkon myöhemmin, on pidettävä tämä reitti johdonmukaisena. Se on kerran pieni kustannus ja toistuva kustannus kymmenien tilien yli. Päätä, kuka sen maksaa, ennen kuin lupaat käyttäytymisen.

Reitti ei ole lupa huijata

Paluureitin lisääminen kertoo aliverkollesi, mihin vastausten pitää mennä. Se ei kerro kudokselle, että instanssi, joka välittää ne paketit, saa lähettää ne vieraalla lähteellä. AWS:ssä asiaankuuluva valvonta on lähteen ja kohteen tarkistus, ja se näkyy instanssikohtaisesti:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Poista se käytöstä vain instanssilta, jonka dokumentoitu työ on välitys, eikä miltään muulta. Jokainen sovelluksen VM, joka pitää tarkistuksen päällä, on yksi kone vähemmän, jota voidaan käyttää liikenteen lähettämiseen lainatulla lähteellä. Jos alustasi ei ole AWS, etsi vastaava anti-spoofing- tai sallittujen osoitteiden asetus sen sijaan, että olettaisit käyttäytymisen siirtyvän.

Nopea paketin kaappaus ratkaisee kysymyksen nopeammin kuin konsolin lukeminen. Jos vastaukset lähtevät eikä asiakas koskaan näe niitä, kudos hylkää väärennetyn lähteen, eikä sovellus epäonnistu.

Mitä kääntäminen ostaa ja mitä se maksaa

Lähteen uudelleenkirjoittaminen yhdyskäytävällä poistaa paluupolun ongelman. Sovellus näkee yhden osoitteen, johon se jo osaa päästä, eikä asiakkaan etuliitteen tarvitse koskaan esiintyä pilven reititystaulussa. Linuxissa sääntö on yksi rivi, ja kannattaa kirjoittaa kapein versio, jonka pystyt:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Huomaa, mitä sovellus nyt tallentaa: 10.40.3.10 jokaiselle käyttäjälle, jokaisessa yhteydessä, ikuisesti. Mikä tahansa tähän arvoon perustuva osoitteiden sallittujen luettelo myöntää nyt pääsyn koko etäkäyttäjäpopulaatiolle, ja jokaisen tapahtuman katsauksen on palattava yhdyskäytävälle vastaamaan, kuka tämä oli.

Ratkaisu ei ole luopua kääntämisestä, vaan lopettaa teeskentely, että osoite on identiteetti. Kanna asiakkaan identiteettiä todennetussa kentässä, kirjaa se yhdyskäytävällä käännetylle monikolle ja anna sovelluksen liittyä siihen. Ilman liitosavainta kääntäminen muuttaa verkko-ongelman pysyväksi rikostekniseksi ongelmaksi.

Välitys on eri rajapinta

Sovelluksen edessä oleva käänteinen välityspalvelin ohittaa reititetyn polun kysymyksen kokonaan. Välityspalvelin avaa oman taustayhteytensä, joten asiakkaan etuliitteen ei tarvitse koskaan olla reititettävissä virtuaaliverkossa, ja sovellus voi vastaanottaa identiteetin otsakkeessa, jonka välityspalvelin asettaa.

Tämä otsake on luotettava vain silloin, kun tausta hyväksyy sen välityspalvelimelta eikä miltään muulta. Nginx-termein se tarkoittaa luotetun vertaisen nimeämistä eksplisiittisesti sen sijaan, että uskoisi kaiken saapuvan:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Jokainen asiakas, joka pääsee taustaan suoraan, voi väärentää saman otsakkeen, joten taustan on oltava saavuttamaton muuten kuin välityspalvelimen kautta. Se on palomuurin tosiasia, ei kokoonpanon mielipide, ja juuri sen oletuksen ihmiset ohittavat kopioidessaan katkelman.

Välitys muuttaa myös sitä, mitä ostat. Saat sovellustason identiteetin ja luonnollisen paikan kirjata se; luovut yleisyydestä, koska jokainen uusi protokolla tarvitsee oman välityspalvelintukensa. HTTP-palveluille tämä vaihtokauppa on yleensä hyvä, ja kaikelle mikä ei ole HTTP, sitä ei yleensä ole lainkaan tarjolla.

Kirjoita ylös, mitä kukin raja näkee

Mitä ikinä valitset, suunnittelukatsauksen pitäisi päättyä yhteen taulukkoon, joka nimeää lähdeosoitteen ja todistettavan identiteetin jokaisella hypyllä. Ilman sitä ensimmäinen tapahtuma tuottaa kolme tiimiä, joista jokainen kuvaa eri asiakasta.

Valitse sitten. Säilytä lähde, kun sovelluksen valtuutus todella riippuu asiakkaan osoitteesta ja voit ottaa reitin vastuullesi. Käännä, kun se ei riipu ja voit kantaa identiteettiä kaistan ulkopuolella, ja käytä AWSm välitysinstanssien ohjetta alustakohtaisiin välitysasetuksiin. Turvaudu välitykseen, kun palvelu puhuu HTTP:tä ja haluat identiteetin lakkaavan olemasta osoite.