Onduidelijkheid in het begrip reverse proxy

[xsienix]

Mijn vraag

Ik zit met een probleem t.a.v. het gebruik van een reverse proxy. Wellicht is het een gedachtenkronkel maar het wil mijn hoofd niet in (of uit).
De reverse proxy zit voor de verschillende (webservers) servers en forward request van de clients naar de servers toe. Ik zie dat als 1 apparaat in een netwerk. Waar bij het inkomende verkeer eerst door de router gaat en daarna door de reverse proxy

Maw de reverse proxy heeft 2 fysieke nics en is dus eigenlijk 1 apparaat. Zo zit dat in mijn hoofd.
Ik hoop dat jullie het begrijpen. Ik weet, het klinkt nogal


Wat ik al gevonden of geprobeerd heb
Verschillende YT filmpjes en grafische uitleggen hoe het werkt, waarbij ik de methodiek wel begrijpen kan. In veel van deze uitleg wordt de reverse proxy server ook als fysiek apparaat weergegeven.
Is dat vaak een combinatie met een firewall?


Kunnen jullie mij van de verwarring afhelpen??

Hartelijk dank.

[boyette]

maar wat is nou eigenlijk het probleem?

[Compizfox]

Een reverse proxy is geen apparaat, maar een serverapplicatie. Een reverse proxy "heeft" dus geen NICs.

De fysieke server waarop die draait, hoeft ook geen meerdere NICs te hebben.

[Jef61]

Mijn 'reverse proxy', (nginx op een Raspberry Pi, met één fysieke interface) staat in een DMZ vlan. Poort 80/443 staat in de router open naar de Rapberry Pi.

Vanuit het DMZ-vlan staat voor de Pi poort 443 open naar het interne vlan waar de webservers draaien (vm's op een Debian server). Mocht de Pi dus overgenomen worden door een hack dan kun je nog steeds alleen via poort 443 naar het interne vlan.

Verder kan ik aan de hand van de domein naam het verkeer naar de juiste webserver sturen, ook al zitten ze achter het zelfde IP-nummer, dus a.nl gaat naar webserver-a en b.nl gaat naar webserver-b

[nelizmastr]

Een reverse proxy staat tussen de webserver en het internet. Het kan een fysiek apparaat zijn, een virtuele machine, een container etc.

Verbindingen naar je webserver worden door je router gelaten via een port forward, daarna komt het verkeer op de proxy terecht die op basis van regels het verkeer naar de juiste webserver stuurt. Je certificaten leven dan ook op de proxy en niet op de webserver.

Een firewall kan een extra beveiligingslaag zijn, maar is niet per se een component. Daarmee kun je vooral inregelen wie wel bij je webserver mag en wie niet (een NGFW kan dit op GeoIP basis en met IPS functionaliteit doen).

[FredvZ]

xsienix schreef op vrijdag 8 november 2024 @ 21:06:
Kunnen jullie mij van de verwarring afhelpen??

Ik kan eerlijk gezegd geen verwarring herkennen in je OP.

Afhankelijk van de inrichting kan een reverse proxy prima een server zijn met 2 NICs. Het kan ook met 1 en het kan ook gecombineerd met een firewall. Het principe heb ik je in elk geval goed begrepen.

[Spiral]

Proxy: van binnen je netwerk naar buiten toe.
Reverse-proxy: van buiten je netwerk naar binnen toe.

[SPee]

Een firewall zorgt ervoor dat bepaald verkeer doorgelaten wordt en de rest geblokkeerd.
Dit kan voor de proxy, na de proxy of zelfs op de webserver zitten!

Hoe dat in plaatjes ingetekend wordt is als losse systemen, omdat het verschillende functies zijn. Maar dat wil niet zeggen dat het allemaal losse (fysieke) apparaten zijn. Veel wordt nu via software gedaan. En afhankelijk van de software kan die een of meerdere functies vervullen.

[mash_man02]

Spiral schreef op vrijdag 8 november 2024 @ 22:25:
Proxy: van binnen je netwerk naar buiten toe.
Reverse-proxy: van buiten je netwerk naar binnen toe.

Jep

Of proxy beveiligd clients en reverse-proxy beschermd servers.

[xsienix]

Dank jullie !

Probleem is -denk ik- dat ik in een fysiek apparaat denk.

Vanuit de router stuur je verkeer door (d.m.v. portforwarding) naar de reverse proxy, waarna de proxy a.d.h.v. regels bepaalt naar welke server de informatie gaat. Bijna net als een router dient de r. proxy als een intermediair en kan zich dus overal in het netwerk bevinden.

Er begint me wat te dagen.

[Compizfox]

xsienix schreef op zaterdag 9 november 2024 @ 13:09:
Dank jullie !

Probleem is -denk ik- dat ik in een fysiek apparaat denk.

Vanuit de router stuur je verkeer door (d.m.v. portforwarding) naar de reverse proxy, waarna de proxy a.d.h.v. regels bepaalt naar welke server de informatie gaat. Bijna net als een router dient de r. proxy als een intermediair en kan zich dus overal in het netwerk bevinden.

Er begint me wat te dagen.

Correct, maar een reverse proxy zit op een heel andere laag dan een router. Een router route IP packets (laag 3), terwijl een reverse proxy HTTP-verkeer proxiet (laag 7).

[Will_M]

Compizfox schreef op zaterdag 9 november 2024 @ 16:12:
[...]

Correct, maar een reverse proxy zit op een heel andere laag dan een router. Een router route IP packets (laag 3), terwijl een reverse proxy HTTP-verkeer proxiet (laag 8 ).

OSI L8 leeft AFAIK alléén bij HR en moet je ooit daar laten termineren

[Compizfox]

Will_M schreef op zaterdag 9 november 2024 @ 16:15:
[...]


OSI L8 leeft AFAIK alléén bij HR en moet je ooit daar laten termineren

Oeps, laag 7 inderdaad

[xsienix]

Routeren is misschien niet het juiste woord omdat dit op laag 3 gebeurd. Maar ik denk dat je het er mee kan vergelijken.

[xsienix]

Jef61 schreef op vrijdag 8 november 2024 @ 21:25:
Mijn 'reverse proxy', (nginx op een Raspberry Pi, met één fysieke interface) staat in een DMZ vlan. Poort 80/443 staat in de router open naar de Rapberry Pi.

Vanuit het DMZ-vlan staat voor de Pi poort 443 open naar het interne vlan waar de webservers draaien (vm's op een Debian server). Mocht de Pi dus overgenomen worden door een hack dan kun je nog steeds alleen via poort 443 naar het interne vlan.

Verder kan ik aan de hand van de domein naam het verkeer naar de juiste webserver sturen, ook al zitten ze achter het zelfde IP-nummer, dus a.nl gaat naar webserver-a en b.nl gaat naar webserver-b

Ik begrijp wat je bedoelt. Je servers krijgen een interne domeinnaam waardoor je niet 192.168.1.x hoeft te gebruiken, waarbij je ook kan communiceren via https verbinding. Dat is een mooie opzet.
In mijn beleving heb je meer regenkracht nodig om al het netwerkverkeer dat naar de r. proxy gaat in juiste banen te leiden toch?

[Jef61]

xsienix schreef op zondag 10 november 2024 @ 17:10:
[...]


Ik begrijp wat je bedoelt. Je servers krijgen een interne domeinnaam waardoor je niet 192.168.1.x hoeft te gebruiken, waarbij je ook kan communiceren via https verbinding. Dat is een mooie opzet.
In mijn beleving heb je meer regenkracht nodig om al het netwerkverkeer dat naar de r. proxy gaat in juiste banen te leiden toch?

Een reverse proxy is eigenlijk gewoon een webserver, bv nginx of apache, maar door middel van de configuratie handelt hij de verzoeken niet zelf af maar stuurt ze door naar de echte webserver (bv een intern IP-nummer) waar dus ook weer nginx of apache draait.

Ik kan wel even een vereenvoudige config van mijn reverse proxy (nginx) hier plaatsen, misschien dat het dan een beetje tastbaarder wordt wat er precies gebeurt.

[Bor]

Compizfox schreef op vrijdag 8 november 2024 @ 21:22:
Een reverse proxy is geen apparaat, maar een serverapplicatie. Een reverse proxy "heeft" dus geen NICs.

Ho ho, dat is echt te kort door de bocht en eigenlijk onjuist. Je kan diverse network applicances inzetten als reverse proxy. Deze hebben wel degelijk een of meerdere NIC's. In grote bedrijfsomgevingen is het gebruikelijk dat de reverse proxy een dedicated device / vm / instance is.

@xsienix
Heb je dit al gelezen? Wikipedia: Reverse proxy

[ Voor 10% gewijzigd door Bor op 10-11-2024 18:14 ]

[Will_M]

Bor schreef op zondag 10 november 2024 @ 18:09:
[...]


Ho ho, dat is echt te kort door de bocht en eigenlijk onjuist. Je kan diverse network applicances inzetten als reverse proxy. Deze hebben wel degelijk een of meerdere NIC's. In grote bedrijfsomgevingen is het gebruikelijk dat de reverse proxy een dedicated device / vm / instance is.

@xsienix
Heb je dit al gelezen? Wikipedia: Reverse proxy

Ik blijf maar even "F5'-en" hier

[Jef61]

Voorbeeld wat je thuis kunt bouwen:

Stel je hebt 2 domein-namen bij een provider
website-een.nl en website-twee.nl

Bij je provider maak je de volgende DNS records aan (naar bv 123.123.123.123)
website-een.nl -> 123.123.123.123
www.website-een.nl -> 123.123.123.123
test.website-een.nl -> 123.123.123.123

website-twee.nl -> 123.123.123.123
www.website-twee.nl -> 123.123.123.123
enz.

Op je router maak je port-forward van poort 80,443 naar het IP-nummer van de reverse-proxy bv 192.168.1.100. Dit kan bijvoorbeeld een RaspBerry Pi met de webserver nginx zijn in een DMZ-vlan.

De (essentiële) configuratie van nginx ziet er als volgt uit:

code:

#website-een.nl
server {
        listen 443 ssl;
        #Op de volgende DNS-namen reageren
        server_name website-een.nl www.website-een.nl;
        #Doorsturen naar echte webserver
        location / {
                proxy_pass https://192.168.2.101:443;
        }
}

#test.website-een.nl
server {
        listen 443 ssl;
        #Op de volgende DNS-naam reageren
        server_name test.website-een.nl;
        #Doorsturen naar echte webserver
        location / {
                proxy_pass https://192.168.2.102:443;
        }
}

#website-twee.nl
server {
        listen 443 ssl;
        #Op de volgende DNS-namen reageren
        server_name website-twee.nl www.website-twee.nl;
        #Doorsturen naar echte webserver
        location / {
                proxy_pass https://192.168.2.103:443;
        }
}

#Default server configuration (dit is op de Pi zelf)
server {
        listen 80 default_server;
        listen 443 ssl default_server;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name _;
}

#Er mist nu uiteraard van alles om het eenvoudig te houden :)

De echte web-servers draaien bv als VM op een Linux-server of NAS.
Op de reverse proxy kan je allerlei zaken regelen wat betreft beveiliging bv loginscherm wat alleen vanaf bepaalde IP-nummers mag worden aangeroepen, fail2ban enz. Certificaten staan op één plek, gemakkelijk met vernieuwen.

[Compizfox]

Bor schreef op zondag 10 november 2024 @ 18:09:
[...]
Ho ho, dat is echt te kort door de bocht en eigenlijk onjuist. Je kan diverse network applicances inzetten als reverse proxy. Deze hebben wel degelijk een of meerdere NIC's. In grote bedrijfsomgevingen is het gebruikelijk dat de reverse proxy een dedicated device / vm / instance is.

Natuurlijk kan je een dedicated fysieke machine inzetten als reverse proxy. Dat spreek ik nergens tegen. Maar het beginsel is een reverse proxy een rol/applicatie op HTTP-niveau. Dat hoeft dus geen fysieke machine te zijn; het kan zo simpel zijn als slechts iets wat je Apache of nginx laat doen.

[decramy]

Een proxyserver termineert het verkeer om het zelfstandig op te zetten naar een andere server; er vindt ontkoppeling plaats. Daarom is een proxyserver ook protocol-specifiek: er bestaan HTTP-proxy's, maar ook RDP-proxy's etc etc. Ze moeten het protocol ondersteunen om te begrijpen wat je wilt doen. Daarna praten ze veelal met hetzelfde protocol verder.

Een proxy kan, door de ontkoppeling, een aantal zaken die je niet met NAT op je firewall kunt doen. Zo kun je een website beschikbaar maken op IPv6, terwijl de webserver op IPv4 draait. Het HTTP-request wordt doorgezet, niet het TCP-pakket.

Je kunt een pool aan backend-servers definieren, waardoor een reverse proxy ook als loadbalancer ingezet kan worden.
Ook kun je SSL-offloading doen: HTTPS aan de voorkant, HTTP met de webservers. Daarmee hoef je het private deel van het certificaat niet over alle webservers te verspreiden, maar alleen op je proxy.
Doordat je SSL-offloading doet, kun je het pakket ook van binnen bekijken: WebApplication Firewall (WAF).

Legio toepassingen waarom je een reverse proxy wilt inzetten.


Over het hebben van 2 NIC's: een proxy heeft een voorkant en een achterkant. Dat kan dezelfde interface zijn. Dat noem je het 'on-a-stick'-principe. Ik snap je idee als je hem inline zet, maar hij moet dus op L7 inline zijn, niet perse op L3.