Ohranite ali uporabite SNAT na IP naslovih odjemalcev VPN na meji oblaka
Ohranjanje vira ohrani identiteto odjemalca v vsakem dnevniku, SNAT ohrani tabelo usmerjanja majhno. Trije pogoji povedo, katerega aplikacija potrebuje.
Ohranjanje naslova odjemalca VPN vse do aplikacije pomeni, da vsaka vrstica dnevnika in vsak vnos na seznamu dovoljenih pomenita isto. Prepisovanje naslova na robu oblaka naredi tabelo usmerjanja preprostejšo in dnevnike manj uporabne. Nobena izbira sama po sebi ni napačna, in argument, ki jo odloči, se redko nanaša na zmogljivost. Odločijo trije pogoji: ali mora aplikacija vedeti, katera oseba se je povezala, ali bo tkivo oblaka sprejelo vir, ki ga nameravate poslati, in kdo bo pozneje prevzel odgovornost za povratno pot.
Odločijo trije pogoji
Začnite z zahtevo aplikacije, ne z omrežnim diagramom. Če sta avtorizacija ali revizija odvisni od posameznega naslova odjemalca, je njegovo ohranjanje funkcionalna zahteva in prevajanje je regresija. Če mora aplikacija vedeti le, da je promet prispel po poti oddaljenega dostopa, zadošča preveden naslov in je veliko cenejši za upravljanje.
Drugi pogoj je mehanski. Virtualno omrežje ne zaupa samodejno paketu, ki trdi, da ima naslov, ki ni bil dodeljen pošiljajočemu vmesniku. Večina tkiv oblaka to uveljavlja, na različne načine in pod različnimi imeni, in zasnova, ki to ignorira, bo na diagramu videti pravilna in bo v produkciji tiho propadla.
Tretji je organizacijski. Ohranjanje virov pomeni, da mora tabela usmerjanja podomrežja aplikacije za predpono odjemalca kazati nazaj na prehod, in vsaka ekipa, ki pozneje doda podomrežje, mora to pot ohranjati dosledno. To je enkrat majhen strošek in ponavljajoč se strošek pri desetinah računov. Odločite, kdo ga plača, preden obljubite vedenje.
Pot ni dovoljenje za ponarejanje
Dodajanje povratne poti pove vašemu podomrežju, kam naj gredo odgovori. Tkivu pa ne pove, da sme primer, ki te pakete posreduje, pošiljati s tujim virom. V AWS je ustrezna kontrola preverjanje vira in cilja, in je vidna za vsak primer:
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
Onemogočite jo samo za primer, katerega dokumentirano delo je posredovanje, in za nič drugega. Vsaka VM aplikacije, ki kontrolo pusti vklopljeno, je en stroj manj, ki ga je mogoče uporabiti za pošiljanje prometa s sposojenim virom. Če vaša platforma ni AWS, poiščite enakovredno nastavitev za preprečevanje ponarejanja ali dovoljene naslove, namesto da bi domnevali, da se vedenje prenese.
Hitro zajetje paketov odgovori na vprašanje hitreje kot branje konzole. Če odgovori odidejo in jih odjemalec nikoli ne vidi, tkivo zavrže ponarejen vir in ne aplikacija spodleti.
Kaj prevajanje kupi in koliko stane
Prepis vira na prehodu odpravi težavo povratne poti. Aplikacija vidi en naslov, ki ga že zna doseči, in predponi odjemalca se ni treba nikoli pojaviti v tabeli usmerjanja oblaka. V Linuxu je pravilo ena vrstica in vredno je napisati najožjo različico, ki jo zmorete:
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
Bodite pozorni, kaj aplikacija zdaj beleži: 10.40.3.10 za vsakega uporabnika, ob vsaki povezavi, za vedno. Vsak seznam dovoljenih naslovov, zgrajen na tej vrednosti, zdaj daje dostop celotni populaciji oddaljenega dostopa, in vsak pregled incidenta se mora vrniti na prehod, da odgovori, kdo je bil to.
Rešitev ni opustiti prevajanje, ampak nehati se pretvarjati, da je naslov identiteta. Nosite identiteto odjemalca v overjenem polju, zabeležite jo na prehodu skupaj s prevedeno terko in pustite aplikaciji, da se pridruži po njej. Brez ključa za povezovanje prevajanje spremeni omrežno težavo v trajno forenzično.
Posrednik je drugačen vmesnik
Obratni posrednik pred aplikacijo se povsem izogne vprašanju usmerjene poti. Posrednik odpre svojo povezavo do zaledja, zato predponi odjemalca ni treba biti nikoli usmerljiva znotraj virtualnega omrežja, aplikacija pa lahko prejme identiteto v glavi, ki jo posrednik nastavi.
Ta glava je zanesljiva le, ko jo zaledje sprejme od posrednika in od ničesar drugega. V izrazih nginx to pomeni, da zaupanja vrednega partnerja izrecno imenujete, namesto da bi verjeli vsemu, kar pride:
set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
Vsak odjemalec, ki lahko doseže zaledje neposredno, lahko ponaredi isto glavo, zato mora biti zaledje nedosegljivo razen prek posrednika. To je dejstvo požarnega zidu, ne mnenje o konfiguraciji, in prav to domnevo ljudje izpustijo, ko kopirajo odlomek.
Posrednik spremeni tudi to, kar kupujete. Dobite identiteto na ravni aplikacije in naravno mesto za beleženje; odpoveste se splošnosti, ker vsak nov protokol potrebuje svojo podporo posrednika. Za storitve HTTP je ta menjava običajno dobra, za vse, kar ni HTTP, pa običajno sploh ni na voljo.
Zapišite, kaj vidi vsaka meja
Karkoli izberete, pregled zasnove bi se moral končati z eno tabelo, ki poimenuje izvorni naslov in dokazljivo identiteto na vsakem skoku. Brez nje prvi incident ustvari tri ekipe, od katerih vsaka opisuje drugega odjemalca.
| Boundary | Source the next hop sees | What is actually proven |
|---|---|---|
| Client to gateway | 172.20.8.14 | A certificate or credential was presented |
| Gateway to app subnet, preserved | 172.20.8.14 | The same session, if the return route exists |
| Gateway to app subnet, translated | 10.40.3.10 | Only that traffic came through the gateway |
| Proxy to backend | 10.40.3.10 plus a header | The proxy asserted an identity it authenticated |
Nato izberite. Ohranite vir, ko je avtorizacija aplikacije res odvisna od naslova odjemalca in lahko prevzamete pot. Prevedite, ko to ne velja in lahko identiteto nosite zunaj pasu, in za nastavitve posredovanja, specifične za platformo, uporabite smernice AWS za posredovalne primerke. Segajte po posredniku, ko storitev govori HTTP in želite, da identiteta preneha biti naslov.