Waarom een scramble-regel in een .ovpn-profiel een gepatchte client vereist

Een profiel met een scramble-regel wordt in de officiële client geïmporteerd en faalt dan bij de handshake, of wordt geïmporteerd met de regel stilzwijgend verworpen en verbindt met niets. De richtlijn hoort bij een gepatchte build van OpenVPN in plaats van de oorspronkelijke functieset, dus een client die die patch niet draagt kan het resulterende protocol niet spreken. De regel aan een normaal profiel toevoegen voegt de implementatie niet toe. Compatibiliteit moet aan beide uiteinden bestaan voordat het bestand iets betekent.

Behandel het eerst als een protocolvraag en daarna als een appstore-vraag.

De optie is een wire-formaat, geen voorkeur

De scramble-patch verandert hoe de pakketten van de tunnel op de draad eruitzien, meestal door de payload met een gedeelde waarde te XOR-en. Dat verandert de bytes die beide peers moeten produceren en accepteren, waardoor het een formaatafspraak is en geen lokale instelling. Als de ene kant de transformatie toepast en de andere niet, ontstaat een sessie die authenticeert en daarna niets bruikbaars draagt. De instelling is alleen zinvol wanneer beide uiteinden hetzelfde gepatchte gedrag uitvoeren.

Twee producten kunnen allebei obfuscatie adverteren en toch incompatibele transformaties implementeren. De naam in een menu is geen specificatie; de werkelijke build van de operator is dat.

Het bestand importeren is geen compatibiliteit

Clients verschillen in wat ze met een onbekende richtlijn doen. Sommige weigeren het profiel ronduit, sommige waarschuwen en gaan door, en sommige laten de regel vallen en verbinden met een gewone handshake. Het laatste geval is het gevaarlijke, omdat de tunnel tot stand kan komen tegen een server die beide accepteert en dan alleen op het verkeer faalt. Een geslaagde import bewijst dus dat de parser de regel tolereerde, niet dat de verbinding zal werken.

Test met de client en build die de uitrol werkelijk vereist, tegen de server die de operator werkelijk draait.

De APK is een beslissing over de toeleveringsketen

Een gepatchte Android-build bestaat omdat iemand hem heeft gecompileerd, en het bestaan ervan zegt niets over wie hem nu onderhoudt. Voordat er een wordt goedgekeurd, moet de eigenaar van de uitrol de bronrevisie bekijken waaruit hij komt, hoe de patch is toegepast, de ondertekeningsidentiteit en het updatepad. Een VPN-applicatie verwerkt inloggegevens en al het gedekte verkeer, dus een niet-gerelateerde downloadpagina is geen aanvaardbare distributieautoriteit.

Vraag de dienstoperator om de ondersteunde clientcombinatie en het huidige installatiekanaal. Als dat kanaal niet meer bestaat, heeft de uitrol een onderhoudsprobleem dat een oud binair bestand niet oplost.

Obfuscatie is geen versleuteling of verhulling

Het zichtbare formaat van pakketten veranderen vervangt geen versleuteling, en het garandeert niet dat een netwerk de verbinding niet kan classificeren. Timing, de reputatie van het eindpunt en het omliggende verkeer dragen nog steeds informatie. Behoud de serveridentiteitscontroles waarop het profiel steunt, zoals certificaatverificatie tegen de verwachte naam, zelfs wanneer het doel van de extra laag is om het uiterlijk te veranderen.

Vervang tls-crypt of een proxy-instelling niet door de patch en noem het gelijkwaardig. Elk verandert een ander deel van de verbinding.

Vraag om een onderhouden paar

Het resultaat dat de moeite waard is, zijn twee uiteinden die onderhouden en expliciet compatibel zijn, met een gedocumenteerd updatepad aan elke kant. Als zo'n paar niet bestaat, evalueer een ondersteund servertransport of een ander toegangsontwerp in plaats van een bevoorrechte oude applicatie in leven te houden. Die beslissing hoort bij de diensteigenaar, niet bij wie de APK heeft gevonden.

Een werkend scramble-vakje op de client is een lokale capaciteitsobservatie. Het zegt niets over de server totdat een echte sessie verkeer draagt.