Rama 0.4: Systeemproxy en PAC-ondersteuning

Rama 0.4 is uitgebracht en brengt ondersteuning voor systeemgeconfigureerde proxy's naar clients (rama-net), inclusief PAC-ondersteuning (rama-pac) aangedreven door JavaScript binnen een WASM-runtime (rama-js). Daarnaast is de gRPC-ondersteuning uitgebreid en is er ondersteuning toegevoegd voor ttRPC, een lichtgewicht alternatief voor gRPC dat direct bovenop TCP draait.

Release van Rama 0.4

Zes weken na de release van versie 0.3 — precies binnen het beloofde window van twee tot acht weken — zijn we trots en blij dat we Rama 0.4 hebben kunnen leveren. Ik ben zeer tevreden met deze release; we konden niet alleen talloze kleine verbeteringen doorvoeren, maar ook werken aan items die al lange tijd op onze backlog stonden.

Let op: Ben je nieuw bij Rama? Lees dan eerst de introductie in de project-README en bekijk daarna eventueel de blogserie "Rama 101".

Voor technische details kun je het volledige CHANGELOG raadplegen — inclusief de release notes voor Rama 0.4 — op https://github.com/plabayo/rama/blob/main/CHANGELOG.md. Een overzicht van de ondersteunde protocollen en functies in Rama is altijd te vinden op https://ramaproxy.org/#features.

Systeemproxy-configuratie

Rama ondersteunt al lange tijd HTTP, HTTP over TLS (HTTPS) en SOCKS5-proxy's. De eenvoudigste manier om deze te configureren is direct via ProxyRoute(s) (voorheen direct ingevoegd als een ProxyAddress). Binnen applicaties kunnen deze hardcoded zijn of via instellingen worden blootgesteld, vergelijkbaar met hoe een browser of editor een proxy configureert via een instellingenbestand of GUI. Meer informatie over deze aanpak is te vinden in het hoofdstuk "Application Proxies" van het Rama-boek.

Applicaties ondersteunen vaak ook de omgevingsvariabele HTTPPROXY. Vanwege CGI-redenen gebruikt curl de variant in kleine letters (httpproxy), een conventie die we nu standaard volgen bij het gebruik van de ProxyEnvLayer. Daarnaast worden nu ook andere gangbare omgevingsvariabelen ondersteund via de ProxyEnvLayer en NoProxyEnvLayer, zoals:

  • ALL_PROXY
  • HTTPS_PROXY
  • NO_PROXY (gebruikt voor bypass-regels, om bijvoorbeeld te zorgen dat bepaalde (sub)domeinen niet via een proxy gaan).

Daarnaast maken besturingssystemen het mogelijk om een proxy systeembreed te configureren. Hier kunnen HTTP-, HTTPS- en SOCKS5-proxy's worden ingesteld, evenals bypass-regels. Hoewel niets een app dwingt om deze systeeminstellingen te respecteren, is dit met Rama 0.4 nu "out of the box" ondersteund via de SystemProxyLayer. Meer informatie hierover staat in het hoofdstuk "System Proxies" van het Rama-boek.

PAC (Proxy Auto Configuration)

Systeeminstellingen maken het ook mogelijk om dynamisch een proxy te selecteren met behulp van een JavaScript-bestand. Dit staat bekend als Proxy Auto Configuration, of kortweg PAC. Hiervoor is een JavaScript-runtime nodig, wat Rama vóór versie 0.4 niet leverde.

Met rama-js ondersteunen we nu het draaien van een JavaScript-runtime binnen een WASM-runtime (met gebruik van wasmtime, de runtime die we ook in de toekomst zullen gebruiken voor rama-wasm). Dit is essentieel voor isolatie: als de JavaScript-runtime crasht, neemt deze niet het hele proces mee. Waar applicaties zoals Google Chrome hun JavaScript-engine in een apart OS-proces draaien, hebben wij binnen het Rama-framework gekozen voor een WASM-runtime. Dit biedt dezelfde isolatie, zonder dat elke applicatie die met Rama is gebouwd een apart proces hoeft te bundelen of uit te voeren.

Rama beschikt nu over PAC-ondersteuning via de rama-pac crate. Hiermee kun je:

  • Een PAC-runtime gebruiken om PAC-scripts te evalueren.
  • Gemakkelijk scripts genereren voor scenario's waarbij domeinen X naar proxyregels Y moeten worden gerouteerd.

Voor wie met deze nieuwe mogelijkheden wil experimenteren, is dit eenvoudig te doen via onze command-line applicatie (CLI):

  • De send-commando's ondersteunen dit standaard (tenzij overschreven door omgevingsvariabelen of een commando-argument).
  • Er zijn nieuwe rama pac subcommando's toegevoegd waarmee je een PAC-script kunt genereren of een PAC-script kunt evalueren via een REPL.

ttRPC en gRPC

Op protocolniveau ondersteunt Rama nu ook ttRPC via de nieuwe rama-ttrpc crate. Dit kan worden gezien als een lichtgewicht alternatief voor gRPC dat direct op een transportprotocol zoals TCP draait, maar nog steeds gebruikmaakt van een protobuf (proto) contract.

Daarnaast is er de rama-grpc-macros crate geïntroduceerd. Hiermee kan Rama client- en server-side gRPC-code genereren zonder dat er een enkele regel proto geschreven hoeft te worden. In plaats daarvan wordt er vertrouwd op eigen codecs, optioneel aangedreven door Serde (zie define_service). Dit is ideaal voor gebruikers die al gRPC gebruiken en volledige controle hebben over hun stack.

HAR WebSockets

Uit onderzoek bleek dat HAR (HTTP Archive) ondersteuning heeft voor WebSocket-data. Deze toevoeging in Rama 0.4 kwam aan het licht via een commerciële partner. Het is een obscure functie: het is enkele jaren geleden aan Chrome toegevoegd, maar weinig andere applicaties hebben het overgenomen. Daarom hebben we Chrome als leidraad gebruikt voor de implementatie.

Deze functionaliteit is nu ondersteund. Bovendien realiseerden we ons dat onze vorige HAR-export-implementatie te veel data in het geheugen hield voor consistentie en volgorde. Dit is nu opgelost; we kunnen alle HTTP- en WS-data efficiënt naar schijf streamen zonder de volledige stream eerst in het geheugen te bufferen.

Het send-commando van de Rama CLI ondersteunt nu ook het exporteren van een HAR-bestand van de uitgevoerde HTTP/WS-gesprekken via het argument --har.

Overige wijzigingen en verbeteringen

Er zijn verschillende breaking changes en talrijke verbeteringen. Voor de volledige lijst kun je het changelog raadplegen. Enkele belangrijke punten zijn:

  • Peekers: De peekers (gebruikt voor protocolinspectie) kunnen nu sneller falen zodra een byte niet meer voldoet aan de heuristieken. Ook zijn er kleine bugfixes doorgevoerd. De HTTP peek router kan nu optioneel veelgebruikte "method"-namen overslaan die verward kunnen worden met HTTP-headerregels (zoals PING), om te voorkomen dat de peeker-logica onnodig wacht tot de timeout.
  • Apple Network Extension: Er zijn verbeteringen doorgevoerd voor de ondersteuning van Apple Network Extensions, wat nuttig is voor het bouwen van L4- en L3-proxy's voor Apple-platformen.
  • Connection Services: De trait-signature van (client) connection services is licht gewijzigd, wat zorgt voor betere foutafhandeling en slimmere beslissingen (bijvoorbeeld wanneer een actie opnieuw geprobeerd moet worden of definitief moet falen).
  • Proxy-routes: In functie van PAC kun je nu meerdere proxy-routes (adressen) invoegen in je input extensions, die in de opgegeven volgorde worden geprobeerd. De bestaande proxy DB-functionaliteit maakt hier standaard gebruik van, hoewel de oude willekeurige selectie van één proxy nog steeds optioneel beschikbaar is.

Dankwoord

We willen deze release gebruiken om iedereen te bedanken die Rama mogelijk heeft gemaakt en blijft maken: onze contributors, de projecten waarop we bouwen of die we hebben geforkt, het bredere Tokio- en Rust-ecosysteem, onze sponsors en natuurlijk onze commerciële partners.

We kijken met veel enthousiasme uit naar de toekomstige releases.

***

Tips:

  • Benieuwd? Neem een kijkje bij onze milestones.
  • Je kunt je abonneren op de RSS-feed van deze blog of op onze eigen nieuwsbrief (geschreven door ons, met privacy-bewuste opslag in ons eigen systeem gemaakt met Rama).
  • Bouw je iets met Rama, alleen of met je organisatie? Deel het met ons via e-mail of Discord.

Be empowered. Be the change.

Bron: https://github.com/plabayo/rama/discussions/1130