Őrizze meg vagy SNAT-elje a VPN-kliensek IP-címeit a felhő peremén

A VPN-ügyfél címének megtartása egészen az alkalmazásig azt eredményezi, hogy minden naplósor és minden engedélyezési lista-bejegyzés ugyanazt jelenti. A felhő peremén történő átírása egyszerűbbé teszi az útválasztási táblát, és kevésbé hasznossá a naplókat. Egyik választás sem rossz önmagában, és az ezt eldöntő érv ritkán a teljesítményről szól. Három feltétel dönti el: tudnia kell-e az alkalmazásnak, hogy melyik ember kapcsolódott, elfogadja-e a felhő szövete a küldeni kívánt forrást, és ki vállalja később a visszaút felelősségét.

Három feltétel dönti el

Kezdje az alkalmazás követelményével, ne a hálózati diagrammal. Ha az engedélyezés vagy az audit az egyedi ügyfélcímtől függ, akkor annak megőrzése funkcionális követelmény, az átírás pedig visszalépés. Ha az alkalmazásnak csak azt kell tudnia, hogy a forgalom a távoli hozzáférési útvonalon érkezett, egy átírt cím elegendő, és sokkal olcsóbb üzemeltetni.

A második feltétel mechanikus. Egy virtuális hálózat nem bízik meg automatikusan egy olyan csomagban, amely olyan címet állít, amelyet nem osztottak ki a küldő interfésznek. A legtöbb felhőszövet ezt különböző módokon és különböző neveken kényszeríti ki, és az ezt figyelmen kívül hagyó terv a diagramon helyesnek tűnik, éles környezetben pedig csendben elvész.

A harmadik szervezeti. A források megőrzése azt jelenti, hogy az alkalmazás alhálózatának útválasztási táblájának az ügyfél-előtaghoz vissza kell mutatnia az átjáróra, és minden csapatnak, amely később alhálózatot ad hozzá, ezt az útvonalat konzisztensen kell tartania. Ez egyszer kis költség, és több tucat fiókon át visszatérő költség. Döntse el, ki fizeti, mielőtt megígéri a viselkedést.

Az útvonal nem engedély a hamisításra

Egy visszaút hozzáadása megmondja az alhálózatának, hová menjenek a válaszok. Nem mondja meg a szövetnek, hogy a csomagokat továbbító példány jogosult azokat idegen forrással kibocsátani. Az AWS-en a vonatkozó vezérlés a forrás- és célcím-ellenőrzés, és példányonként látható:

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

Csak annál a példánynál kapcsolja ki, amelynek dokumentált feladata a továbbítás, és semmi másnál. Minden alkalmazás-VM, amely bekapcsolva hagyja az ellenőrzést, egy géppel kevesebb, amelyet kölcsönzött forrással történő forgalom kibocsátására lehet használni. Ha a platformja nem AWS, keresse a megfelelő hamisításellenes vagy engedélyezett cím beállítást, ahelyett hogy feltételezné, hogy a viselkedés átvihető.

Egy gyors csomagrögzítés gyorsabban eldönti a kérdést, mint a konzol olvasása. Ha a válaszok kimennek, és az ügyfél soha nem látja őket, akkor a szövet dobja el a hamisított forrást, és nem az alkalmazás hibázik.

Mit vesz a fordítás, és mit ér

A forrás átírása az átjárón megszünteti a visszaút problémáját. Az alkalmazás egy olyan címet lát, amelyet már tud elérni, és az ügyfél-előtagnak soha nem kell megjelennie egy felhő útválasztási táblában. Linuxon a szabály egy sor, és érdemes a lehető legszűkebb változatot megírni:

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

Figyelje meg, mit rögzít most az alkalmazás: 10.40.3.10 minden felhasználóhoz, minden kapcsolatban, örökre. Minden erre az értékre épülő címengedélyezési lista most a teljes távoli hozzáférési populációnak ad hozzáférést, és minden incidensvizsgálatnak vissza kell térnie az átjáróhoz, hogy megválaszolja, ki volt ez.

A megoldás nem a fordítás feladása, hanem annak abbahagyása, hogy a címet identitásnak tettessük. Vigye az ügyfél identitását egy hitelesített mezőben, naplózza az átjárón az átírt rendezett együttessel, és hagyja, hogy az alkalmazás arra illeszkedjen. Az illesztőkulcs nélkül a fordítás egy hálózati problémát állandó törvényszéki problémává alakít.

A továbbító más interfész

Az alkalmazás előtti fordított proxy teljesen megkerüli az útválasztott útvonal kérdését. A proxy saját háttérkapcsolatot nyit, így az ügyfél-előtagnak soha nem kell útválaszthatónak lennie a virtuális hálózaton belül, és az alkalmazás identitást kaphat a proxy által beállított fejlécben.

Ez a fejléc csak akkor megbízható, ha a háttér a proxytól fogadja el, és semmi mástól nem. nginx kifejezésekkel ez azt jelenti, hogy a megbízható partnert kifejezetten meg kell nevezni, ahelyett hogy elhinnénk, ami érkezik:

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

Minden ügyfél, amely közvetlenül eléri a hátteret, ugyanazt a fejlécet hamisíthatja, ezért a háttér csak a proxyn keresztül lehet elérhető. Ez tűzfal-tény, nem konfigurációs vélemény, és éppen ezt a feltételezést hagyják ki az emberek, amikor a részletet másolják.

A továbbító azt is megváltoztatja, hogy mit vásárol. Alkalmazásszintű identitást és természetes helyet kap a naplózáshoz; feladja az általánosságot, mert minden új protokollnak saját proxy-támogatásra van szüksége. HTTP-szolgáltatásoknál ez a csere általában jó, és mindenre, ami nem HTTP, általában egyáltalán nem elérhető.

Írja le, mit lát minden határ

Bármit is választ, a tervezési áttekintésnek egyetlen táblázattal kell zárulnia, amely minden ugrásnál megnevezi a forráscímet és a bizonyítható identitást. Nélküle az első incidens három csapatot eredményez, amelyek mindegyike más ügyfelet ír le.

Aztán válasszon. Őrizze meg a forrást, ha az alkalmazás engedélyezése valóban az ügyfélcímtől függ, és Ön vállalni tudja az útvonalat. Fordítson, ha ez nem áll fenn, és az identitást sávon kívül tudja vinni, és használja az AWS továbbító példányokra vonatkozó útmutatását a platformspecifikus továbbítási beállításokhoz. Forduljon továbbítóhoz, ha a szolgáltatás HTTP-t beszél, és azt szeretné, hogy az identitás egyáltalán ne legyen cím.