Komentáře k článku

Jak funguje proxy?

Posledních pár let mě baví se zabývat bezpečností aplikací. Čistě technicky. A když člověk tyhle věci implementuje, dostane se k zajímavým problémům, které by ho ani nenapadly. A tak se stalo, že jsem se dostal k proxy. Jako slepý k houslím.

Zpět na článek

6 komentářů k článku Jak funguje proxy?:

  1. franta

    Par poznamek
    V clanku nebylo dle meho receno to nejdulezitejsi:

    Proxy vzdy narozdil treba od natu/portforwardingu navazuje nove spojeni k cili a casto rozumi aplikacnimu protokolu (ne vzdy).Ma tedy vetsi rezii, ale na druhou stranu ma vetsi moznosti jak ridit, filtrovat a enbo dokonce agregovat provoz.

    Dale loadbalancig zdaleka nemusi byt resen jen pomoci proxy, muze byt configurovan (a take v nekterych sdnkach resen je) na urovni ip (tcp/udp) pomoci treba iptables nebo jineho mechanismu v jadre systemu, pripadne dynamickych dns zaznamu (jeden a zaznam ma vic ip adress)Takove reseni sice neni nijak sofistikovane, ale zase je rychle :).

    A konecne ingress controller neni nic jineho nez jakysi dynamicky prekladac ingress objektu v k8s do reci haproxy/nginxu ci jineho reseni. Samotny proxying pak dela vyse zminena technologie. Pro tuto funkci koneckoncu ani ingress controller nemusite potrebovat, staci Vam obycejny nginx s podporou treba srv zaznamu (tady uz je potreba naka distribuce openresty, protoze ce verze to tusim sama neumi)

    1. Vít KotačkaAutor příspěvku

      Re: Par poznamek
      Díky za poznámky. Převážně s nimi souhlasím.

      Ohledně toho, co mělo být zmíněno jako nejdůležitější – záleží na kontextu a úhlu pohledu. Neměl jsem potřebu psát nějaké srovnání s alternativními přístupy. Samozřejmě, mohl bych do toho zamotat třeba NAT traversal, protože „je to trochu příbuzné“, ale nedávalo mi to v článku smysl. Stejně tak jako port forwarding. To prostě nebylo na stole.

      Totéž platí ohledně load balancerů – nechtěl jsem psát o tom, jak fungují. Diskuze, jestli load balancer má nebo nemá být řešen pomocí proxy, může být relevantní – (opět) záleží na kontextu. Pokud například budu dělat design architektury, tak load balancer může být jenom logická komponenta a jeho technické řešení může být (v daný moment) irelevantní.

      Moc nerozumím poznámce o ingress controllerech. 🤔 Opět, jednak ani nepíšu jak fungují, ani o jejich designu, jednak bych ho spíše formuloval jako komponent (produkt), který jako proxy „navíc rozumí Kubernetes API“. Stejně tak nebylo mým záměrem psát o alternativách k ingress controlleru – ano, můžu mít load balancer, který komunikuje s K8s service, ale tím se jen dostávám v kruhu k tomu, že to je proxy.

  2. Petr Sršeň

    Názvosloví
    Ahoj,
    nejdřív díky za článek o Proxy. Pohybuji se v tomto světě řádku roků a obecná averze vůči proxy je podle mě neopodstaněná a spávně nastavená proxy odvede spoustu práce. Proxy „rozumí“ protokolu, který přes ní má procházet a je schopná odchytit anomálie, případně něco co tam vůbec nepatří. K článku bych měl pár poznámek:

    • TLS terminace se většinou používá obráceně. mezi klientem a proxy je spojení šifrované a mezi proxy (reverzní) a serverem již TLS není použito. Jedná se primárně o SSL offload z důvodu snížení zatížení serveru.
    • Standardně používané názvosloví ohledně explicitní a transparentní proxy je u forward proxy dáno zapojením do infrastruktury. Explicitní proxy musí mít systém (nebo browser) nakonfigurovánu aby o ní věděl, případně musí být použit autovyhledávací nastavení (Pomocí DHCP či DNS). Transparentní proxy je z pohledu browseru (klienta) „neznámá“ a do provozu se vloží buď jako bridge (odchytává si provoz sama) případně tvz, virtuálně inline, kdy se na síťovém prvku použije např. WCCP pro přesměrování provozu na proxy.
    • S termíny Ingress a Egress jsem se primárně setkal ve spojení s identifikací směru provozu na proxy. Použití uvedené v článku je hodně specifické (alespoň myslím) pro použití v cloudové infrastruktuře. U klasické proxy je tak označován směr provozu z pohledu proxy. Client Egress je tok dat proxy > klient, Server Egress je proxy > server. Client ingress je client > proxy a Server Ingress server > proxy. Možná to vypadá jakou matoucí, ale bez ohledu na topologii sítě a konkrétní použití proxy to jednoznačně identifikuje kam daná data „tečou“.
      Nakonec jedna podstatná poznámka. Forward a reverse proxy jdou většinou nakonfigurovat zároveň na jenom zařízení, SW, instanci, jak to kdo nazve. Pak je nutné poctivě ošetřit aby se z toho nestala vůči internetu tzv. OpenProxy, kdy umožní každému připojit se přes ní kamkoli a efektivně se za ní schovat. Pár adminům se to již povedlo a většinou následuje velmi rychlý problém v podobě IP adresy na blacklistech apod. Tak pozor na to.
  3. Vít KotačkaAutor příspěvku

    Re: Názvosloví
    Díky za doplnění a upřesnění. Ano s tím TLS je to pravda. Já jsem to psal z pohledu mikroservis, nebo cloudové infrastruktury, kdy klientem je většinou/často služba a přes proxy komunikuje s dalšími (externími) službami. To jsem měl v článku zdůraznit.

    S těmi směry je to podobný – u „klasické “ proxy je kontext pevně daný, ale třeba v service mesh se kontext dynamicky mění a služby vystupují v různých rolích.

    Možná další věc, kterou jsem měl v úvodu článku napsat, že jsem chtěl ty proxy popsat abstraktně, protože většinou se použije nějaký produkt, ale někdy je nutné tu proxy přímo implementovat.

  4. Borůvka

    pojem tranpsarent
    Mělo to hezký, začátek, ale pak to rychle skončilo.

    Ohledně transparetní proxy: pojem Transparentní může znament víc věcí a není jendoznačný. V kontextu TLS, transparentní proxy by bylo že by přenos nebyl nijak modikován, tedy bez terminace a opakovaného šifrování (jiným certifikátem). Jenže to vyvolá chybu certifikátu.

    = Transparentní pro uživatele = nemusí nikde nic měnit ; případně ženepozná že ke změně došlo (což ale u https nelze, právě díky neshodě certifikátu)

    Historicky, transparentní znamenalo, že se nic neděje s daty, což je jednoduché dosáhnout v HTTP. Nebo jiný příklad: TPROXY v iptables (nebo divert či redirect se tomu říká v bsd firewall pravidlech) je hezký příklad co transparentní znamená. Je to takové znásilnění routingu – IP adresy datagramů zůstanou, ale lze je směrovat dle libosti (na rozhraní nebo danému procesu)…

    Právě tohle je klíčem k správnému fungování HTTPS proxy bez CONNECT, SOCKS atd. Právě znalost IP adresy je kritické místo.. když ji proxy nebude znát, jak pozná kam se připojit (Hlavička Host je zasifrovaná – problém slepice a vejce)… Ještě do toho vstupuje SNI

    Ale dál se to vyvíjí ještě dalším směrem: domain fronting, kdy klient se snaží přisotupit k cenzuovanému obsahu například na doméně blabla.appspot.com (patří googlu). Klient vyšle request na nějakou doménu googlu (tedy IP adrese, kterou získá, za přepodkladu že google.es, google.com, gstatic atd není cenzurované), v SNI uvede taky nějakou doménu googlu. Ale až samotném TLS vesele použije hlavičku Host: dle libosti.

    Kromě toho je úsilí o zašifrované SNI. (Mozilla)

  5. Vít KotačkaAutor příspěvku

    Díky za doplnění. Ano, transparentní je nejednoznačný pojem a záleží na kontextu, v jakém se používá. Byť jsem to v článku lehce naznačil, tak vzhledem k plánovanému zaměření, byla transparentnost marginálním tématem. Samozřejmě, rozpory ve vnímání mohou být značné – podle toho jestli se tento termín použije ve specifikaci/RFC, jak lidé chápou tento pojem obecně a jak ho chápou v určité (technické) doméně, nebo při určitém použití. Možná by to i stálo za samostatný článek, ale ten už bude muset napsat někdo jiný.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://zdrojak.cz/?p=24235