#64 Infrastruktur-Bingo: Forward-, Reverse-, SOCKS-Proxy, Load Balancing und gibt es einen Unterschied zwischen Load-Balancer und Reverse-Proxy?

Forward-Proxy, Reverse-Proxy, Bastion-Host, Load Balancer, SOCKS5-Proxy, Edge-Router, Zero-Trust, Geo-Balancing, ...

Haltet eure Buzzword-Bingo-Karten bereit. In dieser Episode beschäftigen wir uns mit der Frage "Was ist eigentlich der Unterschied zwischen einem Loadbalancer und einem Reverse Proxy?". Klingt einfach zu beantworten, ist es aber nicht. Zwei (oder sogar mehr) Welten treffen da aufeinander. Um der Antwort näher zu kommen, steigen wir Tief in das Thema ein und klären was eigentlich ein normaler Proxy ist, wo der Unterschied zu einem Reverse Proxy ist, was ein SOCKS5-Proxy kann, wozu Proxies heutzutage eingesetzt werden, was ein Bastion Host ist, wozu Edge Nodes gut sind, was Ihr für Tools einsetzen könnt und klären am Ende auch die Frage, was denn nun eigentlich der Unterschied zu einem Load Balancer ist.

Bonus: Ob Wein durch Schläuche schmeckt und was das Düsseldorfer Altbier mit Proxies zu tun hat.

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:00:50) Unterschied zwischen Loadbalancer und Reverse Proxies, störende und hippe Proxies und deren Relevanz

(00:06:31) Was ist ein (normaler) Proxy?

(00:13:52) Was ist ein Bastion Host?

(00:16:58) SOCKS5-Proxies

(00:19:59) Proxy-Anwendungsfall: Hotel W-LAN und die Deutsche Bahn

(00:21:14) Was ist ein Reverse Proxy?

(00:27:28) Anwendungsfälle für Reverse Proxy (Caching, Load balancing, SSL Terminierung)

(00:31:43) Wer braucht einen Reverse Proxy?

(00:35:49) Migration von Bildern in die Cloud mit Hilfe eines Reverse Proxies

(00:40:41) Was sind Edge Nodes?

(00:42:37) Was sind die Nachteile von (Reverse) Proxies?

(00:45:58) Neue Namen und alte Methoden: Welches Tooling gibt es auf dem Markt?

(00:47:09) Was ist der Unterschied zwischen einem Reverse Proxy und einem Load Balancer?

(00:52:31) Anwendungsfall Zero-Trust mit Proxies

(00:54:50) Die Kunst: Grundlagen kennen und Marketing-Lingo entschlüsseln

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:02 - 00:00:09)

So, haaproxy.org, the reliable high-performance TCP HTTP load balancer. So.

Wolfi Gassler (00:00:09 - 00:00:12)

Ja, aber der hat Proxy im Namen, der kann ja nicht sagen, der ist kein Proxy.

Andy Grunwald (00:00:13 - 00:00:15)

Ja, aber genau da wird's halt jetzt gerade echt schwierig.

Wolfi Gassler (00:00:17 - 00:01:04)

Hast du dich eigentlich auch schon einmal gefragt, wo der Unterschied zwischen einem Loadbalancer und einem Reverse-Proxy liegt? Gar nicht so leicht zu beantworten. Wir haben aber keine Kosten und Mühen gescheut und versuchen es einfach trotzdem. Und dabei begegnen wir auch den Nerfing-Proxys aus unserer Schulzeit, dem Forward-Proxy, Bastion-Hosts, SOX5 und SOX4-Proxys, Edge-Routern, CDNs, Zero-Trust-Environments und dem Geo-Balancing. Also auf in den Streifzug durch die Welt der Proxys. Ich würde jetzt eigentlich gern mit der Frage starten, was ist der Unterschied zwischen Load Balancer und Reverse Proxy? Aber nachdem wir uns ja schon nicht einig geworden sind und stundenlang fast gestritten haben zu diesem Thema, fange ich jetzt nicht mit diesem Thema und dieser Frage an.

Andy Grunwald (00:01:05 - 00:01:27)

Also stundenlang mit dir zu streiten, da ist mir meine Energie einfach zu schade für. Ich glaube, da setze ich mich lieber irgendwo ins Gewächshaus und schaue den Pflanzen beim Wachsen zu. Aber in der Tat, die Frage ist nicht ganz so einfach. Ich war die Tage in einem Düsseldorfer Brauhaus bei einem schönen Leckeressen und drei bis 25 Füchschen. Und da habe ich zwei ehemalige Arbeitskollegen, die schon seit fünf, sechs, sieben Jahren...

Wolfi Gassler (00:01:27 - 00:01:33)

Moment, Moment, Moment, Moment. Bei einem Lecker-Essen. Das heißt ein Leckeres-Essen.

Andy Grunwald (00:01:33 - 00:01:47)

Lecker-Essen. Fertig. Naja, auf jeden Fall saß ich da mit zwei Herren. Die beiden verdienen ihr Geld schon seit ein paar Jahren, ich glaub mal so fünf bis sieben, professionell mit DevOps und Cloud-Infrastruktur und SAE und wie man das jetzt heute alles nennt.

Wolfi Gassler (00:01:47 - 00:01:54)

Ich hab gedacht, DevOps ist kein Job, sondern ein Mindset. Wie können die damit Geld verdienen? Ja, mit Mindset kann man Geld verdienen. Okay, lass ich dir nochmal durchgehen.

Andy Grunwald (00:01:54 - 00:02:01)

Das ist korrekt, aber so funktioniert einfach die Industrie und da muss man jetzt, wir können jetzt hier in die Religionskriege abweichen, ja, wir können auch einfach die ganze Sache so akzeptieren, wie die ist.

Wolfi Gassler (00:02:01 - 00:02:03)

Aber du hast mit denen diskutiert ja.

Andy Grunwald (00:02:03 - 00:02:33)

Und dann ich hab nicht mit denen diskutiert ich hab die einfach gefragt okay was ist eigentlich der unterschied zwischen load balancer und reverse proxy da kam die aber ins schwitzen also wirklich ins grübeln und da ginge tief und dann war eine lustige diskussion das hat mir aber gezeigt auch leute, die sowas eigentlich tagtäglich und standardmäßig implementieren, haben Herausforderungen, diese beiden Begriffe, Tools, Applikationen, was weiß ich, wie man es nennt, zu unterscheiden. Und ich glaube, das hat uns eigentlich zu dieser Folge heute geführt.

Wolfi Gassler (00:02:33 - 00:03:27)

Und was ich auch extrem interessant gefunden habe, wenn ich mir so ein paar Gedanken über dieses Thema gemacht habe, ist, dass eigentlich, wenn ich mich so zurückerinnere, früher waren eigentlich diese Proxys immer nur im Weg. So mein erster Punkt, wo ich Proxys so erlebt habe, war irgendwie bei Firmen in offiziellen Netzwerken in Schule, keine Ahnung wo, wo immer diese dummen Proxys irgendwas geblockt haben, irgendein Dienst hat dann nicht funktioniert, man ist auf irgendeine spezielle Webseite nicht gekommen. Die haben irgendwie nur Probleme gemacht, das war so mein Verständnis von Proxys, die machen nur Probleme und heutzutage, wenn man sich überlegt, gibt es mittlerweile so viele Arten von Proxys, Reverse Proxys, Socks Proxys, überall gibt es Proxys und irgendwie sind Proxys hip geworden, sogar in der MySQL Welt mit Proxy SQL gibt es mittlerweile Proxys, also Was hat sich denn geändert, dass Proxys jetzt plötzlich gut geworden sind oder cool geworden sind?

Andy Grunwald (00:03:27 - 00:04:05)

Aber das ist wirklich ein interessanter Gedankengang, denn früher war es ja wirklich so, die Proxys gingen mir immer nur auf die Nüsse. In der Schule haben die mich nicht Counter-Strike spielen lassen oder ich konnte bei dem Test nicht schummeln, weil ich auf Wikipedia nicht raufkam oder oder oder. Und heutzutage baut man die freiwillig ein. Und das noch nichtmals, um Leuten irgendwas zu verbieten. Das ist ja das Lustige eigentlich. Also was ich mich jetzt aber auch frage, wenn wir sagen, früher waren die Proxys immer im Weg, ist das denn heute auch noch so in Firmen und in Schulen? Also die aktuellen Schüler an Berufskollegs oder im Abitur oder ähnliches, haben die genauso Herausforderungen mit dem lokalen Proxy wie wir.

Wolfi Gassler (00:04:05 - 00:04:16)

Also du meinst, sind wir jetzt einfach auf der anderen Seite, eher auf dieser Infrastrukturseite, wo wir dafür verantwortlich sind, eben diese ganzen Restriktionen in irgendeiner Form in unserem Stack einzubauen?

Andy Grunwald (00:04:16 - 00:04:46)

Ja, genau. Also sind wir einfach auf die, auf die, weiß ich nicht, böse, gute Seite? Naja, ist Perspektive, glaube ich hier. Aber ist das halt immer noch so ein Problem? Also kämpft man wirklich in, Firmen und den Schulen noch mit dem Proxy, der den Traffic kontrolliert, der rausgeht. Du müsstest das doch eigentlich wissen, du hast doch jahrelang an der Uni gelehrt und bestimmt im Informatikbereich, wie nennt sich das, Informatikstuhl? Ne, doch, Fachschaft, Fachschaft, Fachschaft Informatik, die werden doch bestimmt damit auch beauftragt, macht man die Infrastruktur hier, oder?

Wolfi Gassler (00:04:46 - 00:05:11)

Was die Fachschaft macht, macht doch keine Infrastruktur, die Fachschaft vertritt Studenten oder Studierende, besser gesagt. Aber wenn ich so zurückdenke, wir hatten eigentlich ein sehr offenes Netz an der Uni. Also es war eigentlich sehr, sehr cool, was wir alles machen konnten. Wir hatten da überhaupt keine Restriktionen. In Schulen könnt ihr das vielleicht schon anders anschauen, könnt ihr mir vorstellen heutzutage. Aber freut uns natürlich, wenn wir da irgendwie Rückmeldung bekommen von jemandem, der noch näher dran ist an dem ganzen Schulnetzwerkding.

Andy Grunwald (00:05:11 - 00:05:19)

Aber du hast eine interessante Frage aufgeworfen. Warum sind denn in modernen Infrastrukturen Proxys wieder so relevant?

Wolfi Gassler (00:05:19 - 00:05:58)

Also ich glaube grundsätzlich, dass sie einfach relevanter geworden sind, weil es jetzt mehrere Arten von Proxys gibt und die einfach sehr coole Dinge machen und Probleme lösen im Allgemeinen. Proxy SQL zum Beispiel gibt mir halt einfach ein Tool in die Hand, wo ich ganz komplexe Problemstellungen in größeren Datenbankumgebungen einfach lösen kann oder Migrationen und andere Dinge. Das heißt, Ich glaube, es gibt jetzt einfach coolere Proxys und mehr Proxys und die Infrastruktur wird ja allgemein komplexer, die Stacks werden komplexer. Mit Kubernetes und containerized environments brauche ich vielleicht einfach jetzt mehr diese zusätzliche Stufe von dem Proxy, den ich da zusätzlich noch reinhänge.

Andy Grunwald (00:05:58 - 00:06:04)

Ich stelle mir gerade die Frage, ob es diese zusätzlichen Stufen früher auch schon gab, doch wir hatten noch nie einen Blick dafür, weil wir noch wissenschaftlich noch nie so weit waren.

Wolfi Gassler (00:06:05 - 00:06:45)

Ja, grundsätzlich, wenn du dir manche RFCs und Standards und so weiter ansiehst, die sind schon teilweise sehr, sehr alt. Also es hat schon Technologien da früher natürlich auch gegeben, aber früher hast du einfach keinen Kubernetes-Stack gehabt. Du hast halt da einen Server gehabt, der hat eine IP-Adresse gehabt und fertig. Und vielleicht war da noch ein Loadbalancer davor, maximal. Aber da sind wir schon wieder beim Thema. Ist ein Loadbalancer nicht eh nur einfach ein Reverse-Proxy oder Proxy? Aber bevor wir da in die Diskussion jetzt einsteigen und bevor wir da wieder irgendwie abdriften auf einen Religionskrieg, wenn wir mal ganz vorne anfangen, was ist denn deiner Meinung nach ein Proxy? Wie definiert sich ein Proxy? Jetzt ganz ohne Reverse, nur Proxy an sich.

Andy Grunwald (00:06:45 - 00:06:57)

Der klassische Proxy, würde ich sagen, der ist ein Server vor einer Gruppe von Client-Geräten, der meiner Anfrage entgegennimmt. und ans Ziel weiterleitet, also so ein Weiterleitungsproxy oder Webproxy oder ähnliches.

Wolfi Gassler (00:06:58 - 00:07:07)

Also so wie dieses Schulbeispiel, oder? Also die Schüler sitzen hinter dem Proxy oder vor dem Proxy, je nachdem, von welcher Seite man das sieht, und alle Anfragen gehen durch den Proxy durch.

Andy Grunwald (00:07:07 - 00:07:55)

Genau, aus der Schulperspektive, so der Klassenraum hat jetzt 25 Rechner, der ganze Traffic im Internet wird dann alles über einen Proxy rausgeleitet und der hat dann eine Whitelist oder Blacklist von, weiß ich nicht, irgendwie irgendwelchen shady Webseiten, Facebook oder so. Ich dachte jetzt an was anderes, aber Facebook okay. Naja, auf jeden Fall übernimmt er halt die Anfrage des Klienten, also des Rechners, leitet sie weiter und holt sich natürlich auch die Response und gegebenenfalls schaut sich auch die Response an und leitet diese dann wieder zum Client zurück. Also der übernimmt eigentlich die Anfrage, kann man so sagen. Das bedeutet natürlich auch, dass dann 25 Rechner zum Beispiel mit einer IP-Adresse rausgehen oder immer mit der gleichen Art des Requestes. Wenn der Proxy zum Beispiel solche Header oder ähnliches dabei fügt, dann sind die natürlich von jedem, dann sind die natürlich bei jeder Anfrage dabei.

Wolfi Gassler (00:07:56 - 00:08:34)

Also um einerseits die Schüler zu schützen vor bösartigen Viren, Schadsoftware oder sonstigen Dingen, die da blockiert werden. Aber auf der anderen Seite auch der umgekehrte Weg, dass man das Internet vor den Schülern schützt. Okay, das klingt jetzt ein bisschen komisch. Eigentlich schützt man trotzdem die Schüler, wenn sie nicht auf Facebook gehen, auf die shady Webseite Facebook. Okay, also vielleicht ist es immer zum Schutz der Schüler, wenn man das so sieht. Aber auf der einen Seite geht es halt um, wo kommt man überall hin, auf welche Webseiten, wenn man nach draußen geht. Und auch wieder, was kommt zurück, wenn da Schadsoftware oder sowas dabei ist. Da könnte natürlich auch ein Antivirus irgendwie in dem Proxy noch drin sitzen zum Beispiel.

Andy Grunwald (00:08:34 - 00:08:44)

Früher ging es natürlich auch noch mal ein bisschen darum, Bandbreite zu sparen. Da, wo dann auch noch so eine Schule vielleicht im zweifachen ISDN-Kanal rausging oder ähnliches, weil DSL war ja noch gar nicht so weit.

Wolfi Gassler (00:08:44 - 00:09:20)

Also ich glaube sogar, dass das ein ganz großer Punkt war und ich kenne das noch von vielen Firmen, vielleicht ist es auch immer noch so, keine Ahnung, aber die gesagt haben, in einer großen Firma, das spart uns natürlich wirklich Bandbreite, weil wenn wir tausend Leute haben, die eh immer auf die gleichen Webseiten zugreifen und auf die gleichen Ressourcen, dann haben wir halt nur 10% des Traffics, als was wir sonst hätten. Keine Ahnung, ob das noch immer so relevant ist, ob das überhaupt möglich ist, so viel zu cashen. Alles wird dynamischer und personalisierter und individueller. Ich glaube, das Argument mit der Bandbreite ist wahrscheinlich heutzutage nicht mehr so wichtig. Da geht es dann schon mehr um die ganze Sicherheit.

Andy Grunwald (00:09:21 - 00:11:03)

Da würde ich widersprechen. Und zwar habe ich einen ehemaligen Arbeitskollegen, der hat eine ganze Zeit lang bei einem kleineren Video Broadcasting Startup gearbeitet, die genau das gemacht haben. Und zwar haben die so eine Art Proxy in das Firmennetzwerk gestellt, die das Video Broadcasting für die Clientrechner in irgendeiner Art und Weise geschadet hat, beziehungsweise im internen Netzwerk gehalten hat, oder wenn der Broadcast nach draußen ging oder von draußen reinkam, dass die Bandbreite nur einmal genutzt wurde und dann intern weiterverteilt wurde auf mehrere Klienten. Das läppert sich natürlich schon, je nachdem was für eine Videoauflösung da dran ist, wie viele Klienten in einem Gebäude hängen und so weiter und so fort. Und diese Startup wurde dann auch später von einer größeren Big Tech Firma gekauft und das war 2022. Also dieses Wandbreiten Thema, das gibt's immer noch. Ist halt nur natürlich jetzt alles ein bisschen spezieller und jetzt sehr wahrscheinlich nicht auf, Wikipedia oder so begrenzt, sondern eher so auf größere Streams und ähnliches. Aber Proxys werden natürlich jetzt auch gerade sehr, ja gehypt möchte ich nicht sagen, sondern eher notwendig, wenn man sich die politische Lage natürlich auf der Welt mal anschaut. Thema Überwachungen, wenn ich jetzt zum Beispiel nicht in Deutschland sitze, sondern in Russland, in Korea, teilweise in der Türkei, wo dann Internet-Traffic einfach eingestellt wird, viele Seiten wie Twitter und so gesperrt werden, da spielen natürlich Proxys eine ganz große Rolle. Speziell natürlich so was wie das Tor-Netzwerk, Bastion-Hosts und so weiter und so fort. Die sind ja dann notwendig zur freien Kommunikation. Und ich glaube, dass durch den technischen Fortschritt halt ... Also, ich mein, politische Probleme gab's natürlich immer, aber der technische Fortschritt ermöglicht das jetzt natürlich, durch die Anwendung von Proxys, dass diese Leute dann natürlich an Free Speech und so rauskommen?

Wolfi Gassler (00:11:04 - 00:13:13)

Also es kennt ja wahrscheinlich jeder dieses NodeVPN und so weiter, die Werbung, die wird ja überall gemacht in allen YouTube-Videos und von Influencern, das geht ja dann genau in diese Richtung. Also ich glaube auch, dass mittlerweile Proxys VPNs ersetzen, wenn es eben gerade darum geht, wie kann ich irgendwelche Sicherheitsmaßnahmen von Regierungen zum Beispiel umgehen. VPNs sind immer sehr teuer, sehr aufwendig, kompliziert einzurichten. Da ist natürlich ein einfacher Proxy, der aber dann eben nicht mehr in meinem Firmennetzwerk steht oder in meinem Netzwerk steht, sondern irgendwo weiter weg in der Welt. Zu dem connecte ich mich und dann route ich den ganzen Traffic über diesen Proxy, meistens einen SOCKS Proxy üblicherweise, weil der einfach mehrere Protokolle unterstützt. Ich kann dann alles darüber routen und kann dann irgendwelche Big Firewalls oder sonstige Dinge natürlich umgehen, wobei man natürlich auch sagen muss, dass Proxys selbst zur Überwachung verwendet werden. Gerade in Firmennetzwerken, wenn die MitarbeiterInnen Überwachung ein Thema ist und das ist unglaublich, in wie vielen Firmen das ein Thema ist, dass einfach dieser gesamte Traffic überwacht wird, sei es unter dem Deckmantel Sicherheit, wir müssen da herausfinden, was da übertragen wird, aber natürlich auch ganz ganz klassisch zur Mitarbeiterüberwachung und solange das bekannt ist, darf das ja auch gemacht werden und es wird in extrem vielen Firmen auch gemacht, muss man auch ganz klar sagen. Und da helfen natürlich Proxys auch als man in the middle, attack quasi zwischendrin zu sitzen. Und was auch wenige wissen, in ganz vielen Firmen ist es einfach Standard, dass dein SSL Traffic, der eigentlich verschlüsselt wird, in dem Router, in dem Proxy einfach entschlüsselt wird und gescannt wird, überwacht wird. Man hat dann einfach andere Route-Zertifikate in seinem Browser und es schaut alles sicher aus, aber eigentlich sitzt da ein Firmenrechner dazwischen, der den gesamten Traffic im Plaintext mitlesen kann. Und das wissen eigentlich ganz, ganz wenig Leute, dass das auch passiert. Natürlich unter dem Deckmantel Sicherheit üblicherweise. Wir wollen halt verhindern, dass da irgendwie Virus runtergeladen wird oder aber auch vielleicht ein internes PDF nach außen gelangt. Wird teilweise auch über Fingerprints gescannt. Aber es wird rein technisch der gesamte Traffic gescannt.

Andy Grunwald (00:13:13 - 00:13:51)

Du hattest gerade gesagt, okay, bei Tor-Netzwerken oder ähnliches hast du immer von Proxy Singular gesprochen oder NordVPN. Wenn du über sowas sprichst, dann sind da natürlich in der Regel nicht nur ein Proxy involviert, sondern du springst mit deiner Anfrage eigentlich von dir zu Hause auf den ersten Proxy. Der leitet das an den zweiten weiter und dritten und so weiter. Du machst also diverse Hops, die es natürlich dann hilft, die originale Location schon irgendwie ein bisschen zu verschleiern. Also da spielt natürlich eine ganze Menge eine Rolle, jetzt nicht nur einfach Proxys hintereinanderketten, sondern schon ein paar Verschlüsselungen und so weiter und so fort, aber da ist dann in der Regel mehr als einer involviert, mehr als ein Proxy involviert.

Wolfi Gassler (00:13:52 - 00:14:01)

Du hast am Anfang Bastion Hosts erwähnt. Kannst du das mal erklären für alle Nicht-Infrastruktur-Leute, die vielleicht mit dem regelmäßig arbeiten?

Andy Grunwald (00:14:01 - 00:14:52)

Bastion Hosts sind eigentlich, ich sag mal so, die Eintrittstür in ein zweites Netzwerk. Jetzt stell dir mal vor, du bist ein IT-Systemhaus und du maintainst die Infrastruktur von Siemens. Jetzt kannst du natürlich immer auf Siemens Gelände fahren und dich dann ins Büro da setzen und die Infrastruktur maintainen. Oder wir gehen einfach mal davon aus, dass die ganze Infrastruktur von Siemens nicht offen im Internet steht, dass sie nicht dieses Beyond-Corp-Modell von Google fahren, sondern eher eine zusätzliche Schicht, nämlich ihr Netzwerk drum haben, was dann eigentlich nicht im Internet steht. Was du dann machen kannst, ist, du kannst eigentlich einen Server davor setzen, sogenannten Bastion Host, auf den loggst du dich ein und Die interne Siemens-IT kann dann genau kontrollieren, welche Art von Traffic von diesem Server ins Netzwerk geht. Du hast also wirklich eine Eintrittstür und nicht 55, wie wenn du das Ding offensichtlich ins Internet stellst.

Wolfi Gassler (00:14:52 - 00:14:56)

Und was ist der Unterschied zu VPN? Also wäre der VPN-Gateway dann ein Pass-Gene-Host?

Andy Grunwald (00:14:57 - 00:15:19)

Wenn du... Kann man so sehen, obwohl natürlich ein VPN auch verschlüsselt sein kann, ja? Was dann beim Bastion Host natürlich nicht der Fall sein muss. Besonders wenn die Firewall dann die Packet Inspection hat oder ähnliches. Also du loggst dich ja beim VPN auch irgendwie an mit deinen Zertifikaten oder ähnliches. Das machst du ja beim Bastion Host ebenfalls. Du musst dich schon irgendwie authentifizieren und autorisieren, dass du dann da rein kannst. Und dann kommt's halt drauf an, was ist das für ein Bastion-Host?

Wolfi Gassler (00:15:19 - 00:15:37)

Und wenn ihr da jetzt einfach so einen Host habt, zum Beispiel jetzt in meinem, keine Ahnung, Kubernetes-Cluster, und ihr habt da irgendwie einen Host, zu dem connecte ich mich bei SSH, und dann bin ich dort eingeloggt, und von dem kann ich mich weiterconnecten bei SSH, würdest du das dann schon als Bastion-Host-Pattern sehen?

Andy Grunwald (00:15:37 - 00:15:47)

Ja, Bastion-Host wird auch oft, je nach Ausbaustufe natürlich, auch Jump-Host genannt, ja? Also, das bedeutet, du springst eigentlich über einen Server in ein anderes Netzwerk und Co.

Wolfi Gassler (00:15:47 - 00:16:29)

Aber es kann natürlich auch ein kompletter, flexibler SOCKS-Proxy sein, der wirklich jede Art von Protokoll mir weiterleitet und wo ich dann transparent eben weiterspringen kann. Weil das Problem ist ja an SSH, dass ich natürlich dann wieder einen SSH-Client auf diesem Rechner brauche und das funktioniert bei SSH noch ganz gut. Aber sobald ich dann andere proprietäre Protokolle habe, da habe ich natürlich dann üblicherweise keinen Client. Wenn ich mich jetzt zur Oracle-Datenbank verbinden will, dann bräuchte ich da wieder einen Oracle Datenbank Server oder müsste irgendwie die Ports durchschleifen oder die Connection durchschleifen über SSH. Das ginge natürlich alles, aber wenn ich eine SOCKS Proxy habe, dann leitet der mir natürlich meinen Oracle Traffic einfach weiter, wenn ich ihn auch so konfiguriert habe, weil der einfach unabhängig vom Protokoll alles weiterleiten kann.

Andy Grunwald (00:16:30 - 00:16:35)

Ja, ich meine prinzipiell, wie du deinen Jump Host, Bastion Host und Co. baust, da sind dir eigentlich keine Grenzen gesetzt.

Wolfi Gassler (00:16:36 - 00:16:40)

Also es geht da mehr ums Muster.

Andy Grunwald (00:16:40 - 00:16:57)

Genau, du kannst das Ding komplett zu locken, du kannst sagen nur auf dem einen Port darf kommuniziert werden, nur über dieses Protokoll, da sind wirklich keine Grenzen gesetzt. Du kannst das Ding auch irgendwie komplett offen machen, würde ich jetzt nicht empfehlen, aber kannst auch mehrere Schichten haben, dass da noch eine Hardware Firewall zwischen steht und so weiter und so fort.

Wolfi Gassler (00:16:58 - 00:17:47)

Ich habe gerade kürzlich selber mal, wie ich da so mit Kryptos und so weiter herumgespielt habe, da wird ja auch empfohlen, dass man über das Tor-Netzwerk geht, damit man da nicht seine IPs und so weiter irgendwie exposed. Und da habe ich das erste Mal selber SOX-Proxys eingesetzt, damit man ins Tor-Netzwerk überhaupt mal reinkommt. Und da habe ich gesehen, dass der SOX 5 Standard so der Standard schlechthin ist und dann habe ich mir heute mal gedacht, okay check mal, wann der überhaupt erstellt worden ist. Und dann habe ich gemerkt, dass der von 1996 ist. Also ich habe gedacht, das ist irgendwie eine neue, coole Entwicklung und dabei ist es einfach Uraltes Protokoll schon. Also man glaubt gar nicht, wie alt teilweise diese rudimentären Dinge sind, die Basisdinge, die jetzt aber teilweise auch wieder hip werden und gut funktionieren. Und dann sieht man einfach, dass das Ding eigentlich schon fast 30 Jahre alt ist.

Andy Grunwald (00:17:47 - 00:18:10)

Jetzt muss man dazu sagen, Socks, ist die Abkürzung für Socket und dieses 5 steht eigentlich für Version 5, also es gibt auch Socks 4. Der Unterschied zu Socks 4 und Socks 5 ist zum Beispiel, dass in Socks 5 TCP und UDP unterstützt wird, in Socks 4 nur TCP. Jetzt sagst du 1996, was haben wir da auf dem Buckel, fast 30 Jahre, 27 Jahre gerade.

Wolfi Gassler (00:18:10 - 00:18:10)

Genau.

Andy Grunwald (00:18:10 - 00:18:49)

Du wirst lachen, in vielen Sachen ist es aber noch gar nicht so drin. Ein aktuelles Beispiel, was ich auch auf der Arbeit habe, wusstest du, die de facto AWS-Client-Library für Python nennt sich BOTO. BOTO selbst hat zum Beispiel keine SOCKS5-Support. Jetzt kannst du dir fragen, wieso braucht eine Cloud-Client-Library SOCKS5-Support? Jetzt haben wir gerade drüber gesprochen. Proxys in größeren Enterprise-Environments, könnte das schon sinnvoll sein. Obwohl das Ding 27 Jahre am Start ist. Und da gibt es auch ein Ticket und es wird auch hochgewertet und allem drum und dran. Aber nur weil es alt ist, heißt das ja nicht, dass es bereits überall implementiert ist oder genutzt wird oder ähnliches. Es ist schon ein sehr spezieller Anwendungsfall, den in der Regel halt Corporates haben.

Wolfi Gassler (00:18:50 - 00:19:59)

Und also nur noch mal zur Klarstellung. 1996 ist wirklich der SOX 5 Standard erstellt worden, also wirklich Version 5. Und ich glaube, da sieht man einfach auch, dass ganz viele Technologien gerade so in dem Bereich super lang brauchen, bis sie implementiert werden. Wenn ich mich zurück erinnere, was wir an der Uni noch so gelernt haben, auch so zur Staukontrolle in TCP, IP, Stack und was es da für Möglichkeiten gibt, Und was damals so in der Forschungswelt und in der Standardisierungswelt gerade so langsam hochgebobbt ist, da sind wir immer noch nicht. Und wir verwenden immer noch eigentlich fast überall die alten Protokolle. Also diese ganze Grundinfrastruktur im Internet und diese Basisdinge, die entwickeln sich einfach ganz, ganz langsam. Und zwar ist der Hauptgrund halt einfach der, dass du da auf einem tiefen Level bist und jeder Hop im Internet, also jeder Provider, jeder Router, müsste das jeweilige Protokoll implementiert haben. Und daher ist natürlich die Adoptionsrate sehr langsam, weil es muss halt die ganze Welt sich entscheiden, wir machen jetzt irgendwas, wir springen auf diesen Zug auf, damit überhaupt was passiert. Weil wenn das halt nur ein Router kann und sonst keiner, dann hilft dir das halt am Ende sehr wenig.

Andy Grunwald (00:19:59 - 00:20:07)

Mir ist gerade noch der Klassiker im Proxy Anwendungsfall eingefallen, im Hotel. Wenn ich meinen Laptop im Hotel aufmache.

Wolfi Gassler (00:20:07 - 00:20:10)

Dann funktioniert es eigentlich zu 99 Prozent nicht.

Andy Grunwald (00:20:10 - 00:20:15)

Ja, was mich immer sehr traurig macht, ist, dass dann oft ein unverschlüsseltes WLAN da ist. Ja, das macht mich immer sehr traurig.

Wolfi Gassler (00:20:16 - 00:20:34)

Das wäre eigentlich das Beste. Ich weiß nicht, warum man immer alles verschlüsseln muss. Das wäre einfach das Einfachste. Und das würde funktionieren. Oder ein simples Passwort. Aber dann kommen da irgendwelche Login-Webseiten, die nie funktionieren, die in deinem Browser nicht funktionieren, aus den 90er Jahren sind, irgendwelche abgelaufenen Zertifikaten und schlag mich tot.

Andy Grunwald (00:20:34 - 00:20:53)

Gut, da hängt man jetzt natürlich noch so ein Radius-Authentifizierungs-Server dran und so weiter und so fort, aber im Endeffekt ist das eigentlich ein Proxy. Der Proxy ist den Hotel-Traffic der Gäste irgendwie raus. Also für Leute, die schon ein bisschen länger aus den Schulen raus sind und euer Hotel-Internet klassischer Proxy angezählt. Vielleicht ist das auch der neue Anwendungsfall aus der Schule, ich weiß es nicht.

Wolfi Gassler (00:20:53 - 00:21:10)

Oder in der Bahn zum Beispiel, Deutsche Bahn, wenn du dich einloggst, wird höchstwahrscheinlich, ich weiß nicht, wie es genau funktioniert, aber höchstwahrscheinlich deine IP-Adresse, MAC-Adresse freigeschalten und dann darfst du raus. Wobei natürlich das auf Router-Ebene mit der MAC-Adresse wahrscheinlich funktioniert und weniger über den Proxy.

Andy Grunwald (00:21:10 - 00:21:32)

Wenn die route den internet hat das ist natürlich ein anderes problem bei der deutschen bahn aber nur gut jetzt haben wir die ganze zeit über proxys gesprochen jetzt sind aber proxys ja nicht der der der hippe scheiß in der modernen cloud native szene sondern reverse proxys wolfgang jetzt habe ich mal kurz bei wikipedia nachgeguckt und der wikipedia eintrag zum thema reverse proxy ist auch von 2006.

Wolfi Gassler (00:21:32 - 00:21:41)

Das andere war 96, Moment, das sind 10 Jahre dazwischen. Weil 2006 ist ja noch super modern eigentlich. Also dem war der erste Eintrag 2006 zu dem Thema.

Andy Grunwald (00:21:41 - 00:21:53)

Aber 17 Jahre, das kann das ja nicht sein. Also, bevor wir jetzt da reinsteigen, warum Reverse-Proxys der neue heiße Scheiß sind, so wie geschnitten Brot, erklär doch mal bitte, was ein Reverse-Proxy eigentlich ist, wenn man schon die ganze Zeit über Proxys gesprochen hat.

Wolfi Gassler (00:21:54 - 00:23:44)

Also grundsätzlich würde ich mal sagen, dass es gar keinen Unterschied gibt. Also ein Forward-Proxy, wenn man die anderen dann so kategorisieren will, und ein Reverse-Proxy sind beides immer noch Proxys. Die bekommen eine Anfrage rein und leiten die weiter. machen vielleicht irgendwas mit der Anfrage, aber schalten sich dazwischen. Und wir haben ja zuerst zum Beispiel einen Forward Proxy erwähnt, der dazu genutzt werden kann, um jetzt zum Beispiel die Big Firewall in China zu umgehen. Der sitzt ja auch wo ganz woanders irgendwo im Netz draußen und leitet es dann weiter an die jeweiligen Rechner, die das betrifft. Auch ein Reverse-Proxy sehe ich so, der sitzt halt bei einem Cluster zum Beispiel, bei einem großen Kubernetes-Cluster, sitzt vor diesem Cluster, bekommt alle Anfragen rein und leitet die dann dementsprechend weiter an die einzelnen Knoten, an die zuständigen Bots, Container, was auch immer im Kubernetes-Cluster. Also ich sehe da gar nicht so viel Unterschied rein von der technischen Seite, aber natürlich, wenn man von Reverse-Proxy spricht, dann spricht man üblicherweise von diesem Einsatz, dass dieser Proxy vor Servern sitzt, also nicht vor Clients wie bei der Schulklasse, sondern auf der anderen Seite vor den eigentlichen Diensten, Servern und entscheidet dann, wenn eine Anfrage von einem Schüler zum Beispiel dann am Ende reinkommt, Welcher Server sollte ich betrachten, diese Anfrage bearbeiten? Will ich den Schüler irgendwo umleiten zu einem anderen Server, der näher zum Beispiel bei dir in Deutschland sitzt oder bei dem Schüler in Deutschland sitzt? Oder kann ich vielleicht aus meinem Cache direkt was ausliefern? Braucht ihr die Anfrage gar nicht weitersenden zu meinem Server? Also der einfach intelligent. vor einer Gruppe von Servern sitzt, vor Diensten und entscheidet, was mit der Anfrage passiert. Und darum Reverse-Proxy, weil es halt auf der anderen Seite ist als ein klassischer Proxy, der eben bei der Schulklasse sitzt.

Andy Grunwald (00:23:44 - 00:23:51)

Also eigentlich kannst du sagen, okay, die Clients sind jetzt in der Regel keine Menschen, sondern Server, wenn man aus Proxysicht jetzt mal guckt.

Wolfi Gassler (00:23:51 - 00:24:18)

Ja, wobei natürlich der Schüler, die Schülerin immer noch zum Proxy kommt als Client und die Server ja selten mit dem Proxy sprechen. Also damit die Server nach draußen kommen in die Welt, gehen die selten über den Proxy. Also der Proxy ist schon immer noch für die User da und die Anfragen kommen von den Clients, von den Usern, aber dahinter sitzen eben dann die Server und keine Client-Rechner. Also Computer, die die Anfrage bearbeiten und nicht lossenden.

Andy Grunwald (00:24:18 - 00:24:31)

Und du hast jetzt ziemlich viel Kubernetes erwähnt. Kubernetes ist jetzt nur ein Beispiel. Das kann aber auch eigentlich nur eine Server-Farm sein. Das können eigentlich Docker-Container sein. Das kann fünf Raspberry-Pi sein oder das kann auch nur ein Raspberry-Pi sein, richtig?

Wolfi Gassler (00:24:31 - 00:24:53)

Oder ein Container, genau. Und ich glaube eben, dass es das früher auch schon gegeben hat, aber früher hat man einfach Load-Balancer dazu gesagt. Und nachdem Loadbalancer aber irgendwie sehr spezifisch sind und Reverseproxys irgendwie flexibler und noch mehr können, hat man dann irgendwann Reverseproxy dazu gesagt. Aber meiner Meinung nach ist ein Loadbalancer genauso auch ein Reverseproxy.

Andy Grunwald (00:24:53 - 00:25:07)

Ja, den Streit beginnen wir jetzt gleich mal. Aber eins, ein essenzieller Unterschied zu einem Weiterleitungsproxy und einem Reverseproxy ist ja auch, dass man nie mit dem Ursprungsserver selbst kommuniziert. Also man kommuniziert ja immer mit dem Proxy. Richtig?

Wolfi Gassler (00:25:08 - 00:25:26)

Genau. Auf der Forward-Seite ist der Proxy die Vertretung der Schüler, der Clients. Und auf der anderen Seite beim Reverse-Proxy ist der Proxy die Vertretung der Server sozusagen. Und nach außen hin in das Public-Netz sieht man immer nur die IP von dem Proxy. Egal ob Forward-Proxy oder Reverse-Proxy.

Andy Grunwald (00:25:26 - 00:25:44)

Und das gibt mir als Infrastruktur-Mensch natürlich die Freiheit, dass ich meine interne Struktur jeden Tag umschweißen kann, richtig? Solange ich die Reverse-Proxy-Konfiguration anpasse, kann ich hintendran machen, was ich möchte, weil ich ja meine internen Serverstrukturen, Containerstrukturen und Co., die gebe ich ja nicht nach außen preis. Das sind ja sozusagen Implementierungsdetails, oder?

Wolfi Gassler (00:25:44 - 00:26:55)

Und genau das ist eigentlich der große Vorteil, dass du komplette Flexibilität hast hinten. Und das war ja zum Beispiel auch ein klassischer Anwendungsfall von dem Proxy SQL. Wenn ich hinten zum Beispiel meine Datenbank austausche oder einen zweiten Datenbank-Server dazu stelle, dann kann ich, wenn ich einen Proxy davor habe, das transparent hinten machen, wie ich will. Ich kann das schaden. meine SQL-Versionen updaten, upgraden, merchen, schaden, alles was ich eigentlich machen will, solange davor dieser Proxy ist, der dahinter die Infrastruktur versteht. Und man kann natürlich sogar nur weitergehen, dass man das Ganze dynamischer sieht, weil diese Dinger können dann natürlich auch dynamisch entscheiden, welcher Server sind gerade ausgelastet. Da sind wir ja beim Load Balancer Case. An welcher Server sende ich dieses Request? Ist es ein Write Request? Ist es ein Read Request bei Datenbanken? An welchen Server sende ich das Ganze? Ist ein Server gerade irgendwie im Maintenance-Mode, wird der gerade abgegradet, dann darf ich da keine Requests hinsenden. Also es geht gar nicht darum, baue ich meine Infrastruktur um und kann dann jeweils die Sachen manuell umstellen, sondern teilweise halt wirklich pro Sekunde, pro Millisekunde wird dynamisch entschieden am Proxy, was wird gemacht mit dem Request hinter dem Proxy.

Andy Grunwald (00:26:56 - 00:27:13)

Wenn wir uns jetzt mal anschauen, wofür so ein Reverse-Proxy eigentlich genutzt wird, dann teilt er ja schon manche Anwendungsfälle mit dem klassischen Proxy. Also ich denke da so Schutz vor Angriffen oder Caching. Wir hatten das gerade mit Reduzierung der Bandbreite beschrieben. Das sind ja zwei Elemente, die der Proxy ganz klassisch mit dem Reverse-Proxy auch teilt.

Wolfi Gassler (00:27:14 - 00:27:28)

Nur halt jeweils für den anderen Use Case. Also der schützt halt die Server oder der macht Caching, damit weniger Bandbreite bei den Servern gebraucht wird oder Rechenkapazität und der Forward-Proxy macht es eben auf der Client-Seite, genau.

Andy Grunwald (00:27:28 - 00:27:36)

Was ist denn der ein oder andere Anwendungsfall, wo der Reverse-Proxy in der Regel angewandt wird, wo der klassische Proxy eigentlich relativ wenig mit zu tun hat?

Wolfi Gassler (00:27:36 - 00:28:25)

Also um das mal davor zu verallgemeinern, es geht ja wirklich darum, um ganz transparent, so dass es die Leute eben nicht mitbekommen, irgendwas mit dem Traffic macht. Ich kann den Traffic einfach abändern, anpassen, was ich da auch immer machen will, egal auf welcher Seite, egal ob Forward-Proxy oder Reverse-Proxy. Und ich glaube, da erweitern sich die Szenarien gerade auch ganz, ganz stark. Also auch auf beiden Seiten. Früher hätte man sich ja nicht denken lassen, dass man auf dem Forward-Proxy SSL entschlüsselt, scannt und das alles noch in Realtime, um irgendwie bösartige Sachen zu finden oder zu checken, ob irgendwie Mitarbeiter in ein internes PDF irgendwo hochladen, in eine Public Cloud oder so. Also das hätte man ja früher vor 20, 30 Jahren hätte man sich das ja nie gedacht, dass das sinnvoll möglich ist, auch mit der Geschwindigkeit.

Andy Grunwald (00:28:25 - 00:28:29)

Ja, aber was sind denn jetzt klassische Anwendungsfälle von Reverse Proxies?

Wolfi Gassler (00:28:29 - 00:29:12)

Also der ganz klassische Anwendungsfall ist meiner Meinung nach der Load Balancing. Anwendungsfall. Das heißt, ich terminiere die SSL-Verbindung, die verschlüsselte Verbindung, am Rand meines Netzwerkes, meiner internen Infrastruktur und entscheide dann, wohin sende ich das Request zu welchem Server. Round-Robin-Verfahren zufällig immer abwechselnd zu den hinteren Servern oder ich habe irgendwie intelligentere Algorithmen da. Aber das ist eigentlich so der Standard-Anwendungsfall, würde ich mal sagen, dass man einfach den Traffic annimmt, terminiert, die SSL-Verschlüsselung terminiert, nach hinten weiterleitet und die Server beantworten dann die Anfragen und vielleicht mache ich noch ein Caching am Weg. Das ist so der absolute Default-Fall, meiner Meinung nach.

Andy Grunwald (00:29:12 - 00:29:24)

Na ja, da schmeißt er ja schon natürlich zwei Features jetzt in einen Raum, ja? Loadbalancing hat erstmal nichts mit Verschlüsselung zu tun, meines Erachtens nach. Deswegen, du kannst auch Loadbalancing machen mit verschlüsseltem Traffic oder mit nicht verschlüsseltem Traffic, ja?

Wolfi Gassler (00:29:24 - 00:29:34)

Aber Loadbalancer haben klassisch auch immer SSL terminiert. Muss natürlich nicht sein, aber die klassischen Loadbalancing-Softwaren, die können natürlich auch SSL-Terminierung, üblicherweise.

Andy Grunwald (00:29:35 - 00:29:47)

Ja, aber warum wird das überhaupt gemacht? Also ist das nicht viel besser, wenn ich meinen verschlüsselten Traffic bis zu meiner Applikation, bis zu meiner Node führe, Das erhöht doch die Sicherheit auch in meinem internen Netzwerk, oder? Ich meine, Attacken von intern sind ja real.

Wolfi Gassler (00:29:47 - 00:30:32)

Also meiner Meinung nach ist der Hauptgrund einfach Komplexität. Wenn du einen zentralen Eingangsserver hast, dann machst du Dot-Determinierung, du brauchst das Zertifikat nur dort haben für deine verschiedenen Domains, du brauchst die Zertifikate nicht verteilen auf die einzelnen Nodes und alles wird zentral gemacht. Und bisher war ja eigentlich sehr oft eher die Sicht, dass du in deinem internen Netzwerk keine Verschlüsselung da mehr brauchst. Heutzutage geht es natürlich mehr in die Richtung, dass du SSL auch bei deinem internen Netzwerk hast und überall HTTPS verwendest, auch wenn es nur intern ist, einfach aus Sicherheitsgründen. Also man geht eh in diese Richtung, aber auch trotzdem wird dominiert auf deinem Gateway, auf deinem Reverse-Proxy. Und dann wird eine neue HTTPS-Verbindung aufgebaut zu den einzelnen Nodes, wenn du wirklich intern auch SSL hast.

Andy Grunwald (00:30:32 - 00:30:53)

Der Grund, der in meiner Karriere immer sehr oft angeführt wurde, sind halt CPU-Cycles, beziehungsweise die Rechenpower zur Entschlussung der ganzen Geschichte. Weiß ich jetzt nicht, wie relevant das heutzutage noch ist bei modernen CPUs. Genauso wie mit den ARM-CPUs, wenn die jetzt gerade im ganzen Cloud-Bereich auch günstiger zu kriegen sind. Aber das ist das, was mir so oft immer genannt wurde.

Wolfi Gassler (00:30:54 - 00:31:43)

Ich glaube, dieses Argument wird eigentlich immer weniger, würde ich mal sagen, weil erstens die Infrastruktur stärker wird. Und auch die Frage ist, wie viel Prozent von deinen CPU-Cycles wird dann wirklich für SSL-Terminierung verwendet? Am Ende musst du es ja sowieso irgendwo terminieren. Das heißt, irgendwo brauchst du die CPU-Cycles. Und bei den meisten Anwendungen, glaube ich zumindest, ist es eher so, dass die Anwendung viel, viel mehr CPU-Cycles braucht. Also selten sind es ja Anwendungen, wo du nur eine Datei raussendest, weil das wird dann sowieso weggecashed. Sondern es geht halt wirklich um komplexere Berechnungen, Datenbank-Connections und so weiter. Und da ist halt dann die Frage, wie viel kostet mich SSL-Terminierung wirklich am Ende auch noch. Und wenn ich dann in den Bereich komme, dass du SSL-Everywhere hast, dann brauchst du sowieso immer die Terminierung, auch dann halt nur, wenn es intern ist.

Andy Grunwald (00:31:43 - 00:31:49)

Aber jetzt kommen wir mal wieder zur Praxis. Jetzt holen wir dich mal wieder aus deiner Uni da raus. Wer braucht denn überhaupt ein Reverse-Proxy? Brauche ich einen?

Wolfi Gassler (00:31:50 - 00:31:58)

Ja, natürlich brauchst du eine Reverse-Proxy. Du hast wahrscheinlich bei deinen ganzen Side-Projects irgendwo Reverse-Proxys, oder? So ein Traffic zum Beispiel.

Andy Grunwald (00:31:58 - 00:32:03)

Ja, habe ich. Aber primär einfach nur, weil ich zum Beispiel auch Zertifizierungen nicht bei mir einbauen möchte.

Wolfi Gassler (00:32:03 - 00:33:26)

Aber genau darum geht's. Ich glaube, diese Reverse-Proxys nehmen dir extrem viel ab. Und in den heutigen Stacks, wenn man sich das so anschaut, ganz klassisch hast du ja mehrere Container. Und da setzt man dann ganz gern einfach eine Reverse-Proxy davor, der die SSL-Terminierung macht. der das Auflösen der Domain vielleicht macht, der vielleicht auch so Sachen macht wie hängen irgendwelche Tracing-IDs an jedes Request dran, damit die Container dann, die dahinter laufen oder die Server, die dahinter laufen, die Web-Server, die dahinter laufen, schon eine eindeutige Tracing-ID mitbekommen von dem zentralen Gateway oder Reverse-Proxy, wie man es auch immer nennt. Das heißt, das sind so Kleinigkeiten natürlich, die man auch anders lösen kann, aber die sind halt extrem praktisch mit einem Reverse-Proxy. Und nachdem das Deck ja immer aufgeteilter wird, modularer wird, also früher hattest du irgendwie einen fetten Apache, der hatte ein PHP-Module drin, der hat einfach alles erledigt und heute geht es ja eher in die Richtung Du hast mehrere Container, du hast einen Reverse-Proxy vorne dran, dann wird das weitergesendet an den richtigen NGINX dahinter zum Beispiel und der NGINX ist dann connected mit einem PHP-Container, der dann nur das PHP-Handling macht und so machst du das ja viel, viel modularer und üblicherweise hast du dann vorne dran eben irgendeinen Reverse-Proxy, der das Request dann auflöst und zum richtigen Bot sendet oder zum richtigen Server sendet, der dahinter sitzt.

Andy Grunwald (00:33:27 - 00:33:53)

Ja, aber in der Tat. Also mein Reverse-Proxy, ich nutze da Traffic in den Zeitprojekten, der macht, der holt sich automatisch ein Wildcard-Zertifikat von Let's Encrypt, aktualisiert das automatisch, löst die Domain auf, macht ein bisschen Basic out, spuckt mir sogar Prometheus-Metriken raus, wie viel Traffic über welche Routen geht, Ingress, Egress und so weiter und so fort. Ist schon sehr bequem und war deutlich schneller, als hätte ich das selbst programmiert. Aber bedeutet das, dass irgendwie jeder Web-Stack jetzt früher oder später so ein Ding braucht?

Wolfi Gassler (00:33:53 - 00:35:49)

Ich würde sagen ja, weil gerade durch die ganze Virtualisierung und Container... Wie heißt denn das auf Deutsch? Containerization? Containerisierung. Das ist ein schweres Wort. Ist ja das viel öfter der Fall, dass du einfach ganz viele Services auf einem Rechner hast und die müssen halt einfach dementsprechend orchestriert werden und der Traffic muss orchestriert werden und weitergeleitet werden. Das heißt, da sitzt irgendein Loadbalancer davor und ich würde mal sagen, eben das ist der Reverse-Proxy mittlerweile. Und es gibt ja ganz selten den Anwendungsfall, da steht eine Bare-Metal-Kiste mit einer IP-Adresse und der User kommuniziert direkt mit dieser einen IP-Adresse. Dieser Fall wird ja immer, immer kleiner, dieser Anwendungsfall. Und nachdem die Infrastruktur komplexer wird und alles modularisiert wird, in kleinen Modulen aufgeteilt wird, brauchst du irgendwas, das die Module zusammenhängt in irgendeiner sinnvollen Form. Und darum glaube ich, dass früher oder später jeder irgendwo ein Reverse-Proxy einsetzen muss fast, beziehungsweise es einfach ganz viel vereinfacht und erleichtert und die Modularisierung ist ja auch super, weil irgendwann kommt vielleicht ein stärkere Reverse-Proxy raus, Traffic ist ja so ein Beispiel, der viel vereinfacht, vielleicht in einem Jahr gibt es irgendein cooles neues Projekt und dann brauche ich natürlich nur dieses Modul austauschen, meinen Reverse-Proxy in meinem Stack und habe vielleicht dann schon wieder einen Mehrwert gewonnen. Also zum Beispiel, wo ich begonnen habe vor einigen Jahren mit meinem Cluster, da habe ich noch einen Nginx selber aufgesetzt, habe mir eigene Skripte geschrieben, die da die Let's Encrypt Zertifikate holen und dann abspeichern und das ganze Routing machen zu den richtigen Services. Und mittlerweile gibt es halt einfach Traffic. Out of the Box funktioniert genau gleich, holt sich die Zertifikate, macht das Routing, super einfach zu handhaben, ist ein Befehl. Der ersetzt mir das natürlich jetzt. Und umso modularer, umso einfacher bin ich natürlich auch mit dem Ersetzen bzw. dem Hereinbringen von sinnvolleren Technologien am Ende.

Andy Grunwald (00:35:49 - 00:37:25)

Eine Story kann ich zu gutem geben. Und zwar hat uns mal so eine Reverse-Proxy auch mehr oder weniger sehr viel Arbeit erleichtert. Und zwar hatten wir den Fall, dass wir mehrere Terabyte Bilder hatten. Bei Trivago war das, weil ich meine, wer bucht ein Hotel ohne Bilder? Jeder möchte zumindest mal das Badezimmer sehen und die Aussicht vom Balkon. Auf jeden Fall hatten wir etliche Terabyte Bilder auf lokalen Festplatten und Das Storage-System war jetzt nicht mehr das performanteste. Auf jeden Fall kam eine klassische Anfrage rein. Wir haben hochauflösende Bilder gekauft, Millionen Stück, und die müssen jetzt resized werden. Was baut man da klassisch? Okay, man lädt die runter, packt die irgendwo hin und baut eine Art Queue-System und versucht, das in die Breite zu verteilen. Haben wir dann auch gemacht. Ich weiß nicht, drei, vier, fünf Worker-Nodes hatten wir da. Dann haben wir ausgerechnet, wir bräuchten mehrere Monate, um die paar Millionen Bilder zu resizen. Kannst dir vorstellen, das Management war jetzt nicht so happy. Was haben wir gemacht? Wir haben die ganze Sache nach Amazon S3 geschoben, auf EC2 Instanzen einmal in die Breite skaliert. Dann hatten wir aber das Problem, dass wir ein paar Bilder in der Cloud liegen hatten und ein paar Bilder immer noch lokal unten auf dem Storage. Da hat uns ein Reverse-Proxy natürlich den Arsch gerettet, weil immer wenn eine Anfrage zu einem Bild an den Reverse-Proxy ging, hat er erst nachgeguckt, okay, ist das Bild hier unten auf meinem lokalen Storage vorhanden? Nein, ist es nicht. 404, zweite Stufe, ist das Bild da oben bei Amazon S3 vorhanden? Ja, retunier. Also das war wirklich, wir konnten die Implementationsdetails, wo die Bilder liegen, ändern wie wir wollten und hatten so eine Art Try-and-Error-Verfahren und der Reverse-Proxy hat sich die ganze Sache natürlich dann gecached. Super luxuriös.

Wolfi Gassler (00:37:26 - 00:38:12)

Es ist ganz interessant, weil dieses Projekt hat ja eines meiner Teams damals geerbt und wir hatten ja probiert, es dann noch auf die nächste Stufe zu bringen, ein paar Jahre später und dynamisches Image Resizing zu machen. Das heißt, wenn ein Image nicht verfügbar ist, on the fly, sofort in der Cloud auf Lambda ein neues Image zu erzeugen mit der richtigen Größe und es dann auszuliefern. Leider hat es am Ende nicht funktioniert. Lambda war einfach zu langsam, weil die Boot-Up-Time von Lambdas einfach zu unpredictable war. Das hat teilweise einfach zu lange gedauert. Und ich habe jetzt gerade neulich gelesen, dass es mittlerweile Lambda-at-Edge-Functions gibt, die wirklich auf Edge-Nodes ablaufen. Und da wäre das wahrscheinlich jetzt wieder möglich, weil die mehr in diese Richtung laufen, dass man on the fly ganz schnell was berechnet.

Andy Grunwald (00:38:13 - 00:38:33)

Naja, auch im Sektor Lambda gibt es natürlich jetzt eine unglaublich große Entwicklung. Also es gibt verschiedene Lambda-Funktionen, du kannst hier mehr Memory nehmen und so weiter und so fort. Also ich glaube, zwischen dem Zeitpunkt, wo du das da angewandt hast und heutzutage, da sind inzwischen noch mal ein paar Welten dazwischen. Also gegebenenfalls brauchst du auch gar keine Lambda-Add-Edge-Funktion, sondern ganz normal Lambda wird vielleicht auch schon reichen, aber... Ja, das Problem.

Wolfi Gassler (00:38:33 - 00:38:44)

Ist die Bootup-Time von der Lambda. Die kannst du nicht hundertprozentig sicher vorhersagen. Und wenn du Requests in Real-Time behandeln willst, ist Lambda einfach, die Garantie, die du von Lambda bekommst, einfach zu klein.

Andy Grunwald (00:38:45 - 00:39:07)

Ja, aber es wird mit hoher Wahrscheinlichkeit irgendwelche Mechanismen geben, um komplett immer pre-warm was vorzuhalten und ähnliches. Zumindest eine gewisse Anzahl von Funktionen. Ein ganz klassischer Anwendungsfall, ein Architekturanwendungsfall, ist ja auch von Amazon. Du hast eine API-Gateway vorne dran und jeden Request feuerst du über deine Lambda-Funktionen ab. Da kannst du mir ja nicht erzählen, dass es da keine Pre-Worm-Funktionen gibt, weil sonst wären ja manche Webseiten einfach tierisch langsam.

Wolfi Gassler (00:39:07 - 00:39:45)

Die hat es natürlich damals auch schon gegeben, aber damals war Lambda nicht für das ausgelegt. Und ich glaube auch, dass zum Beispiel GCP da anders arbeitet, weil die natürlich auch darauf ausgelegt sind oder das jetzt klassisch bewerben, dass du da ja wirklich eine API davor hängst und die auch dementsprechend schnell reagieren. Aber wenn du natürlich da wirklich in Millisekunden antworten musst, da geht es halt wirklich um, wie gesagt, jede Millisekunde in so einem Anwendungsfall und das war dann zumindest zum damaligen Zeitpunkt leider nicht möglich, aber wie gesagt auf Edge ist es wahrscheinlich jetzt möglich und ich glaube Edge Compute Nodes sind eigentlich auch Reverse Proxys, wenn man es ganz genau nimmt, oder?

Andy Grunwald (00:39:46 - 00:40:40)

Schwierig, schwierig, schwierig, weil in der Regel ist es ja auch Compute Power. Also ich würde sagen Edge Nodes generell könnte man in einem sehr generellen Bild als Reverse Proxies bezeichnen. Ob jetzt Edge Compute Nodes Reverse Proxies sind, weiß ich nicht. Also vielleicht ist das die nächste Stufe von Reverse-Proxys, dass die dann auch simple Lua-Skripte oder ähnliches ausführen können und dann gar nicht mehr zu der Infrastruktur dahinter gehen, also das Proxy-Element von Reverse einfach weglassen, weil dann proxyen die ja eigentlich nicht mehr, sondern führen die Logik eigentlich auch aus. Schwierig, weil ich meine, kommt natürlich dann mit einer ganzen anderen Tüte von Problemen mit rein, so nach dem Motto, du hast dann mehr oder weniger deine Ausführungslogik an mehreren Stellen in der Applikation, bisschen was auf der Edge. Also weiß ich nicht, ob ich da jetzt mit der Definition mitgehen würde, dass Edge Computing auch Reverse Proxys sind.

Wolfi Gassler (00:40:41 - 00:42:37)

Also vielleicht zur ganz schnellen Erklärung, was überhaupt Edge Nodes sind. Edge Nodes sind, wie der Name schon sagt, Knoten, die am Rand sitzen, und zwar am Rand von einem sogenannten CDN, Content Delivery Network, und diese Knoten sitzen üblicherweise möglichst nahe an dem Client. Das heißt, Wenn der Andi jetzt zum Beispiel auf irgendwas zugreift, dann gibt es da wahrscheinlich einen Knoten in Düsseldorf, der irgendwo sitzt und die Daten möglichst schnell an den Andi ausliefert. Und wenn man jetzt von Compute Edge Nodes spricht, dann spricht man von Software, die man auf all diese Knoten in einem CDN ausliefert und dieser Source Code, dieses Programm, läuft dann jeweils auf dem Knoten, der möglichst nahe am User ist. Also zum Beispiel beim Andi um die Ecke auf diesem Knoten in Düsseldorf wird dann jeweils der Code ausgeführt, der zum Beispiel irgendwas mit dem Bild macht oder irgendwas adaptiert von dem Traffic. Zuerst wird mal gecheckt, okay, welcher Knoten ist am nähesten am Andi, wo ist der Andi gerade und der Knoten, der dann am nähesten beim Andi sitzt, wird beauftragt mit der Bearbeitung von dem Request und wenn man da ein kleines Programm auch noch drauf hat, dann ist es eben so ein Compute-Edge-Node und dort wird das Programm dann lokal bei Andi um die Ecke ausgeführt. Und diese Programme agieren halt oft auch so wie Reverse-Proxys, die haben zum Beispiel irgendwas gecached, aber wenn sie keinen Cache haben, also keine gecachete Version von dem angeforderten Objekt, von der Webseite zum Beispiel, von dem Bild, dann fragen die zum Beispiel dahinter nach, holen sich dieses Bild und liefern das dann in der richtigen Form an den Andi aus. Also auch so Knoten, die dazwischenhängen oder Software, die dazwischenhängt, so ähnlich wie ein Reverse-Proxy, würde ich mal sagen. Und nachdem Reverse-Proxys ja auch gerne cachen oder für Caching verwendet werden, sind die natürlich so ähnlich wie CDN-Knoten, die ja auch das Caching übernehmen. Also ich würde sagen, vom Pattern her, vom Muster her agieren sie in einer ähnlichen Form, auch wenn es natürlich auf der technischen Seite schon nochmal leicht was anderes ist, würde ich sagen.

Andy Grunwald (00:42:37 - 00:42:40)

Wir verkaufen jetzt Reverse-Proxys aber irgendwie wie geschnitten Brot.

Wolfi Gassler (00:42:40 - 00:42:44)

Ja, es ist alles nun mal ein Proxy. Ich sage ja, Proxys sind hippe, neue, coole Dinger.

Andy Grunwald (00:42:45 - 00:42:53)

Also kannst du mir sagen, da muss ich in mein Steak schmeißen und dann löbt alles. Also ich kann mir jetzt nicht vorstellen, dass es da keine Nachteile gibt. Kann das Brot schimmlig werden zum Beispiel?

Wolfi Gassler (00:42:54 - 00:44:05)

Ja, meiner Meinung nach der größte Nachteil, wie bei all diesen Dingen, ist natürlich die Komplexität. Umso mehr bewegliche Teile sind sie eigentlich nicht. Teile ich in meinem System habe, aber sie arbeiten natürlich auch, sind irgendwo beweglich, kann natürlich auch was schiefgehen. Und damit steigt die Komplexität, weil ich muss halt einfach, wenn mein Stack zehn Layer hat und durch zehn Schichten ein Request durch muss und ein Request schlägt fail, muss ich natürlich auch in zehn Ebenen oder Schichten checken, wo liegt das Problem. Und eine Schicht davon ist halt der Reverse-Proxy. Das heißt, die Komplexität erhöht sich natürlich, das Debugging ist einfach schwieriger, weil alles verteilt ist. Klassisch Microservice-Architektur ist ja auch sowas, wenn ich ganz viele kleine Module habe, ganz viele Server, ganz viele Reverse-Proxys dazwischen. Alles wird schwieriger, jeder Proxy hat irgendwie Regeln, vielleicht sogar der Forward-Proxy von den Schülern hat auch noch einzelne Regeln und am Ende weiß ich nur, der Schüler hat irgendwie ein Problem und kann auf die Webseite nicht zugreifen und dann muss ich halt rausfinden, wo in diesen zehn Schichten passiert wirklich diese Fehler. Also das ist, glaube ich, der größte Nachteil, dass die Komplexität natürlich irgendwo erhöht wird. Aber das ist natürlich mit jeder Schicht. Durch die modulare Zusammenbauweise habe ich dieses Problem der Komplexität.

Andy Grunwald (00:44:05 - 00:44:44)

Damit geht natürlich einher, dass man natürlich auch gegebenenfalls Knatsch im Team kriegt. So nach dem Motto, oh, wo packe ich die Logik denn jetzt hin? Packe ich die in meinen HTTP-Router in meinem React oder packe ich die in eine Reverse-Proxy? Und da muss man natürlich ganz klar aufpassen, dass du dann nicht so eine, ist jetzt nicht wirklich ein Split-Brain-Problem, aber dass du halt ein Teil der Routinglogik im Reverseproxy hast, ein Teil der Routinglogik in deiner App. Also da kann es natürlich schon sehr schwierig werden und besonders wenn du noch ein bisschen Fluktation in dem Team hast, dann weiß halt gar nicht mehr einer, okay, wieso kommt mein Request gar nicht an und der wird einfach quer einfach mal, vielleicht sogar im Kreis in deinem Netzwerk geroutet, weil irgendwie der eine Reverseproxy mit dem anderen Reverseproxy spricht oder so. Also alles schon gesehen.

Wolfi Gassler (00:44:45 - 00:45:58)

Auch beim Proxy SQL in MySQL zum Beispiel, wenn da natürlich klassische Datenbank-Administratoren dahinter sitzen und irgendeine Magic machen und deine Datenbank-Requests umleiten und du hast ein Problem in deiner Software als reiner Entwickler, du siehst natürlich gar nicht, was da abgeht und weißt es vielleicht auch gar nicht. Das heißt, du musst wieder die Leute fragen, okay, was ist da ein Problem? Wo entsteht dieses Problem, ich greife nur auf die eine IP zu, das ist für mich ein MySQL-Server und dahinter sitzen aber vielleicht 100 MySQL-Server, wo irgendein Sharding passiert und sonstige Magic. Und das macht es natürlich auch aus Developer-Sicht viel, viel schwieriger. Und da ist natürlich auch wichtig, wenn man dann sowas hat wie das Tracing, was ich kurz zuerst schon angesprochen habe, dass zum Beispiel der erste Reverse-Proxy vielleicht so eine Tracing-ID dranhängt an jedes Request. und alle in die Schichten dahinter verwenden wieder diese Request-ID und speichern in den Logs immer die Request-ID mit, weil dann kannst du halt mit einer guten Logging-Herangehensweise und einem zentralen Logging vielleicht auch ganz schnell rausfinden, okay, dieses Request schlägt fehl, wo kommt denn das überhaupt vor, in welchen Schichten, wo wird was gemacht, wo gibt es einen Fehler und so weiter. Also da sind halt dann so Herangehensweisen wie eine Tracing-ID sehr, sehr hilfreich in so einem verteilten System.

Andy Grunwald (00:45:58 - 00:46:04)

So, und ich hab immer das Gefühl, immer wenn etwas hip ist, dann muss jeder einen neuen Begriff dafür erfinden.

Wolfi Gassler (00:46:04 - 00:46:09)

Haben wir ja schon Reverse-Proxy. Früher war's der Loadbalancer oder der Proxy, jetzt haben wir den Reverse-Proxy.

Andy Grunwald (00:46:09 - 00:46:23)

Ja, da geh ich nicht mit, da schreiten wir gleich noch ein bisschen drüber. Aber was ich so denke, wenn ich jetzt Reverse-Proxy eingebe bei Google, was find ich da? Ich find den NGINX, ja? NGINX ist für viele Leute immer noch ein klassischer Webserver, so wie Apache. Dann gibt's den ... Ja, man könnte.

Wolfi Gassler (00:46:23 - 00:46:25)

Jetzt sagen, Reverse-Proxy ist auch ein Webserver.

Andy Grunwald (00:46:26 - 00:47:35)

Könnte man auch. Dann gibt's aber noch den Traffic. Der bezeichnet sich selbst als Edge-Router. Dann gibt's einen Envoy. Ein Envoy bezeichnet sich als Edge- und Service-Proxy. Dann gibt's diese ganze Cloud-Thematik. Google Cloud Platform, Amazon Web Service, Microsoft Azure. Da gibt's dann das Amazon API Gateway, kann dafür genutzt werden. Oder du machst eine Kombination aus Amazon Cloudfront und AWS Lambda at Edge. Ja, da sind wir beim Edge-Computing. Bei Azure heißt das Service Fabric. Bei GCP ist dann doch der klassische Cloud-Load-Balancing, kann auch irgendwie so Reverse-Proxy-Features. Dann suchst du nach Load-Balancing-Features und landest beim HA-Proxy. Und dann bist du noch gar nicht bei den Service-Meshes wie LinkerD oder Istio. Also ich hab wirklich das Gefühl, dass es inzwischen immer, immer schwieriger wird, die ganz klare Trennung zwischen Reverse-Proxy, Load-Balancer, Service-Mesh zu finden. zu definieren, weil irgendwie jeder sich so, ich sag mal so, Features von den anderen klaut, um vielleicht sogar Market Share zu kriegen, weiß ich nicht. Aber wirklich so ein Service Mesh kann ja teilweise auch Sachen von einem Load Balancer und kann ja teilweise Sachen von einem Reverse-Proxy.

Wolfi Gassler (00:47:35 - 00:47:58)

Du wirst dich ja jetzt nur unserer Diskussion entschlagen, ob Load Balancer auch Reverse-Proxys sind. Und weil du jetzt gerade HA-Proxy auf Int hast, bei Trivago hatten wir ja ... HA-Proxy auch lange im Einsatz, wenn ich das richtig im Kopf habe. Und ich glaube ja sogar, wie ich damals angefangen habe und mit dir mal darüber gesprochen habe, hast du mir erklärt, der HA-Proxy ist unser Loadbalancer.

Andy Grunwald (00:47:58 - 00:48:03)

Stehe ich auch immer noch zu. Wird HA-Proxy inzwischen auf der Webseite als Reverse-Proxy rausgehauen?

Wolfi Gassler (00:48:03 - 00:48:08)

Keine Ahnung, aber dann... dann hast du ja schon den Beweis, der hat im Namen Proxy und ist ein Loadbalancer.

Andy Grunwald (00:48:08 - 00:48:16)

So, haaproxy.org, the reliable high-performance TCP HTTP Loadbalancer. So.

Wolfi Gassler (00:48:16 - 00:48:19)

Ja, aber der hat Proxy im Namen, der kann ja nicht sagen, der ist kein Proxy.

Andy Grunwald (00:48:19 - 00:48:48)

Ja, aber genau da wird's halt jetzt gerade echt schwierig, ja, und ich glaube, deswegen rattern wir beide auch immer aneinander in der Definition, wo ist denn jetzt der Unterschied von einem Reverse-Proxy und einem Loadbalancer. Und ich schmeiß noch gar nicht diese Edge und Service Proxys und Service Meshes und so weiter mit rein, sondern ich denke, wenn man sich das jetzt so nur von den Begriffen anschaut, ich glaube, dann ist das so eine Philosophie-Frage. Wenn du dich aber knallhart auf zwei Applikationen stürzt und dann wirklich ein Feature-Vergleich machst, ich glaube, dann wird es einfacher.

Wolfi Gassler (00:48:49 - 00:48:58)

Also ich würde ja sagen grundsätzlich, bei Proxy können wir ja mitgehen mit der Definition, oder? Proxy hängt sich irgendwie dazwischen, leitet was weiter. Soweit sind wir d'accord.

Andy Grunwald (00:48:58 - 00:49:00)

Ja gut, das macht ja ein Loadbalancer auch.

Wolfi Gassler (00:49:00 - 00:49:19)

Genau. Und meiner Meinung nach ist ein Loadbalancer einfach ein Spezialfall eines Proxys, weil der proxyt irgendwie den Traffic und macht es halt noch intelligenter, indem er Loadbalancing betreibt, dass er das hinten weiterleitet. Also das ist ein Spezialfeature in einem Proxy, aber er ist definitiv ein Proxy.

Andy Grunwald (00:49:20 - 00:49:23)

Ah, ja und nein. Das ist wirklich eine interessante Geschichte.

Wolfi Gassler (00:49:23 - 00:49:45)

Wobei, vielleicht um das noch zu spezifizieren, also ein HTTP-Loadbalancer, weil es gibt natürlich auch andere Loadbalancer und du kannst Loadbalancing auch über DNS machen und das ist dann natürlich ganz was anderes, aber es ist immer noch Loadbalancing. Aber ein HTTP-Loadbalancer ist meiner Meinung nach ein Proxy mit dem speziellen Feature, dass er eben Loadbalancing auch noch macht.

Andy Grunwald (00:49:45 - 00:49:52)

Ja, aber wir haben die ganze Zeit von dem Proxy und Reverse-Proxy gesprochen, dass ein Kernfeature unter anderem Content-Caching ist. Und das sehe ich halt bei Loadbalancern in der Regel nicht.

Wolfi Gassler (00:49:52 - 00:49:55)

Ja, aber HAA-Proxy kann natürlich genauso Caching.

Andy Grunwald (00:49:55 - 00:49:59)

Macht der Content-Caching? Macht der Response-Caching? Ist eine gute Frage, weiß ich jetzt gerade nicht. HAA-Proxy...

Wolfi Gassler (00:49:59 - 00:50:01)

Wenn ich das richtig im Kopf habe, schon.

Andy Grunwald (00:50:01 - 00:50:02)

Response-Caching.

Wolfi Gassler (00:50:02 - 00:50:15)

Das kann doch heutzutage jeder coole Loadbalancer, oder? Okay, um diese Diskussion irgendwie zu beenden, ich glaube, es ist schwierig. Wir einigen uns einfach drauf, dass wir nicht einer Meinung sind. Ist vollkommen okay.

Andy Grunwald (00:50:15 - 00:51:06)

Also, ich glaube, was man sagen kann, dass die Masse an Loadbalancern Support für Layer 3 bis 7 hat, und dass die Masse an Reverse-Proxys sich primär auf HTTP spezialisiert. Es gibt ... Reverse-Proxys für speziellere Anwendungsfälle, SQL-Proxys, es gibt den Tramp-Proxy, der das für Memcache macht, es gibt auch ein Memcache-Proxy inzwischen, Tramp-Proxy macht das auch für Redis und so weiter. Also, wenn du dir jetzt einen ganz klassischen Nginx nimmst, der spezialisiert sich auf HTTP, wo du hingegen bei fast jedem Software-Loadbalancer Layer 3, 4, 5, 6, 7, für die Leute, die gerade die Ausbildung haben, ich rede von den OSI-Layern, OSI-Referenzmodell, ISO-OSI, Schöne Nummer. Ich glaube, jedem geht gerade so ein bisschen Gänsehaut über den Arm.

Wolfi Gassler (00:51:07 - 00:51:35)

Aber da würde ich sogar mitgehen. Also wenn man heutzutage das einfach mal so in den Raum wirft, Reverse-Proxy, verstehen die meisten HTTP darunter. Das stimmt schon. Oder zumindest auf einer Applikationsebene. Also auch der Proxy SQL ist ja kein IP-Proxy, sondern ist ja eigentlich auch auf der Applikationsebene von dem MySQL-Protokoll. Also das würde ich auch noch unterschreiben, dass üblicherweise im Sprachgebrauch das so verwendet wird. Ja, ganz klar.

Andy Grunwald (00:51:35 - 00:52:10)

Zusätzlich würde ich sagen, dass Loadbalancer, die wirklich auch als Loadbalancer ausgezeichnet sind, deutlich besser im Bereich Loadbalancing sind. Was meine ich damit? ich meine wirklich wie sie die last verteilen und was für möglichkeiten sie haben also dass sie nicht nur ganz klassische round robin machen sondern vielleicht sogar auch auf dns ebene ja global anycast load balancing und so weiter und so fort und da fängt es dann an bei klassischen reverse proxys ein bisschen an zu bröckeln wenn es an wenn es an wirklich ich sag mal sophisticated load balancing use cases rangeht Es gibt natürlich auch.

Wolfi Gassler (00:52:10 - 00:52:37)

Ganz klassische Hardware-Loadbalancer, aber es gibt auch Hardware-Proxys, vor allem früher natürlich. Aber wie gesagt, es ist schwierig zu unterscheiden. Ich glaube, wir müssen da auch nicht eine Definition finden. Vor allem solche Begriffe entwickeln sich ja auch immer und wie sie dann eben klassisch verwendet werden, was gerade am Markt ist, das ändert sich ja natürlich auch, muss man auch ganz klar sagen. Gibt es noch irgendeinen Anwendungsfall, den wir vergessen haben, wo du sagst, das ist auch noch so ein Klassiker, was Proxys so machen?

Andy Grunwald (00:52:37 - 00:52:52)

Ich glaube, die ganze Schiene von Security, also wirklich so Zero Trust, Authentication, Authorization, das haben wir jetzt noch nicht angesprochen, beziehungsweise nur so ein bisschen, aber ich glaube, das ist noch so einer der größeren Anwendungsfälle, warum Proxys einfach davor gesetzt werden.

Wolfi Gassler (00:52:53 - 00:54:44)

Also das geht ja auch sehr stark in diese Richtung, dass man eben wieder sagt, man hat diese Modularisierung und man hat vielleicht dann die Authentifizierung nicht mehr im Haupt-Stack drinnen. Das heißt, die Applikation selbst muss die Authentifizierung gar nicht mehr durchführen, sondern ihr habt dann einen Proxy davor sitzen, einen Reverse-Proxy, der auch mit einem zentralen Authentifizierungs-Server z.B. checkt, ist der User, der jetzt gerade auf diese Applikation zugreifen will, auf diese Webseite zugreifen will, ist der schon authentifiziert und kann ich den auch autorisieren, also darf der auf diese Ressource, auf dieses Programm zugreifen. Und in Zero-Trust-Environments ist das ja wirklich ein Hauptelement, dass du immer solche Proxys davor hast. Das heißt, es wird grundsätzlich niemandem vertraut, auch wenn derjenige User zum Beispiel gerade im VPN ist und du würdest sagen, okay, Der hat im VPN nur Zugriff, wenn er eben da das richtige Passwort eingegeben hat und die könnte den jetzt schon freigeben. In Zero Trust wird trotzdem nicht vertraut und der User muss sich auch im VPN zentral authentifizieren, bei einem zentralen Authentifizierungsserver. Und jede Applikation hat dann noch so sicherheitshalber so einen Proxy davor sitzen, der checkt, ist der User authentifiziert und darf da auf die Ressource zugreifen. Und die Applikation ist dann einfacher gestaltet. weil die muss sich eben nicht mehr um dieses ganze Zeug, Authentifizierung und Autorisierung kümmern. Im Windows-Bereich, NTLM ist so ein Klassiker dafür, aber da gibt es natürlich auch, wie gesagt, im Zero-Trust-Environment, was ja so das neue Passwort ist von Google, diese Identity-Aware-Proxys, die dann eben dementsprechend davor sitzen. Aber grundsätzlich kann man das genauso mit einem Radioserver oder sonst irgendwas realisieren. Aber das sind so Bereiche, wo ich eigentlich eh wenig Ahnung habe. Und wer sich da mal interessiert, hört am besten den Wartungsfenster-Podcast. Die sprechen die ganze Zeit über solche Dinge, wo ich mir immer denke, okay, ich habe eigentlich wenig Ahnung, was so überall abgeht in diesem ganzen Authentifizierungs-Windows und sonstigen Kram.

Andy Grunwald (00:54:45 - 00:55:20)

Ja, bei Zero Trust weiß ich jetzt gar nicht, ob sich da nicht schon wieder die Industrie ein bisschen dreht. Also wer im Cloud-Native-Bereich unterwegs ist, speziell im Kubernetes-Bereich, Service-Mesh-Bereich. Der wird vielleicht Open Policy Agent was sagen. Da geht es natürlich dann auch sehr viel um Policy-Based-Control-Mechanismen für Cloud-Native-Environments. Also ich glaube, so langsam habe ich hier meine Buzzword-Bingo-Karte schon voll. Vielleicht kommt da auch einfach nur neues Wort zu Reverse-Proxys ins Spiel, so wie Edge-Router, Service-Proxy und so weiter. Also gefühlt haben wir ja hier, wenn man zwei Schritte zurückgeht, 25 verschiedene Wörter für ein und dasselbe.

Wolfi Gassler (00:55:21 - 00:56:09)

Aber ich glaube, das ist ja auch die Kunst, dass man eben diese Grundlagen, diese Technologien kennt und das dann auch entschlüsseln kann und dieses Marketing-Lingo runterbrechen kann auf das, was es eigentlich ist. Und das ist ja oft wirklich ganz, ganz wichtig, dass du dann eigentlich merkst, okay, das ist nichts anderes als ein Reverse-Proxy und der checkt auch noch, ob der User authentifiziert ist. Und das geht mit NTLM genauso. Und man braucht jetzt keine hyperneue Technologie von Google. Und ein Identity-Aware-Proxy ist auch nichts anderes als ein Reverse-Proxy mit einem Modul drinnen, der halt checkt, welche Identität greift gerade darauf zu. Also das ist schon ein Skill, den man sich angewöhnen sollte, dass man eben sich nicht zu blenden lässt von diesen Sales-Webseiten, sondern halt wirklich das runterbricht auf die Technologie und vielleicht dann auch andere Wege findet, wie man das umsetzen könnte.

Andy Grunwald (00:56:09 - 00:56:18)

Also lasst euch am besten in eurem täglichen Job nicht so blenden von diesen ganzen neuen Begriffen, alles alter weine, neuen Schläuchen, weil irgendein Marketing Mensch muss ja auch ein bisschen was zu tun haben.

Wolfi Gassler (00:56:19 - 00:56:32)

Ja, aber wenn es alter Wein ist, ist es eh besser, oder? Umso älter, umso besser. Ich würde nie einen Wein aus dem Schlauch trinken. Aber keine Ahnung, was du da so machst. Wenn du in so eine Düsseldorfer Absteige gehst, um da mit deinen DevOps-Freunden wieder ein Bier zu trinken, da kommt wahrscheinlich alles aus Schläuchen.

Andy Grunwald (00:56:33 - 00:56:38)

Naja, ich glaube, so Dessertwein, so Eiswein, ich glaube, der wird nicht besser, wenn der älter wird. Ich glaube, der kann auch kippen.

Wolfi Gassler (00:56:39 - 00:56:41)

Ja, aber süßer Wein ist sowieso ein Untigen.

Andy Grunwald (00:56:41 - 00:56:45)

Deswegen bleibe ich ja beim Brauhaus. Viel Spaß beim Proxy implementieren. Bis zur nächsten Episode. Tschüss!

Wolfi Gassler (00:56:46 - 00:56:52)

Und schaut vorbei natürlich in der Community und sagt uns, ob Loadbalancer Proxy sind. Würde mich unbedingt interessieren. Bis nächste Woche. Tschau!