Oplon ADC Content rewriting

Introduction

Oplon ADC implements content rewriting in native mode and as a fundamental component in the governance of application services. The system has been designed both for the use of rewriting in the strict sense, rewriting of HTTP HEADER or HTTP BODY, as well as as a layer 7 and layer 4 integration system.

Design design has given you the ability to use rules described with regular expression until you use the JAVA programming language or scripting languages. These two rewriting modes can be used at the same time.

Another key aspect that has been taken into account during the design is the ease of use and a "intuitive readability" over time of what has been developed in both descriptive and programmatic rules. All rules can be set through the WEB interface.

This document covers the topic rewriting using lots of examples so that they can then be reused in your projects.

HTTP2/1.x academy.oplon.net Services

Oplon Networks provides a TOMCAT-based service to perform the tests described in this document. At https://academy.oplon.net (opens in a new tab).

To URI https://academy.oplon.net/trainingw (opens in a new tab) a service is available that highlights the results of both HEADER and BODY http/s content rewriting operations.

The service is provided in port 443 in http/2 in self-sensing. Oplon ADC's http/2 autosensing can tell if the client can establish http/2 communication and possibly switch to http/1.x automatically.

At the same address but with port 543, https://academy.oplon.net:443/ (opens in a new tab) you can only connect with http/1.x protocols.

The service requires a digital certificate, NOT OBBLIGATORIO, for the sole purpose of performing exercises for this document and for online courses so that you can verify the features of "certified forwarding clients" towards applications. The listener accepts any type of certificate and at the address https://academy.oplon.net/trainingw (opens in a new tab) you can appreciate the forwarding of the "certified chain client".

Enjoy!

ADC setting to perform exercises

To be able to easily perform the exercises of this manual, simply set up the ADC with the following listeners, copied directly from the templates to the Platform Edition module, changing the addresses on which listeners listen and possibly the port.

As a group keep for testing http_https proposed by the templates and insert a single endpoint with the domain name "academy.oplon.net" port 443 with indication of the SSL connection

Rewriting

The rewriting topic identifies processes that, by filtering data in transit through a gateway, can modify the content.

In such a transformation process, it is clear that the relevance of the changes made must be very strict by going to affect not only the content but also at the protocol level and thus influencing the behaviours.

The rewriting system will then need to provide the necessary tools to modify the content in a way that Selective with simplicity.

Intervening on the protocol obviously requires some awareness of the changes that are to be made to affect the delivery of the service. Nevertheless, the system will have to be abstract enough to hide the complexity of the technologies by ensuring that the user has the final result.

Given the articulation of the topic another aspect to consider is the possibility to intervene through simple descriptive rules with regular expression leaving the possibility to intervene also through extensions of JAVA classes or scripting with a real programming language.

The latter aspect, in addition to rewriting, allows you to perform integration tasks with the applications by managing tasks such as single sign on (SSO) or aspects of attribution of application usage for subsequent billing or splitting by cost centers.

HTTP Rewriting

Oplon ADC implements http/1.0/1.1/2.0 protocol rewriting through the development of descriptive rules.

Rules are labeled with a name so that they can be reused on different information flows and at different levels, helping to develop their own rule libraries.

In Oplon ADC with the http protocol, two types of rules can be described, one for HEADER and the other for BODY. These two elements distinguish the http message. Both of these rules are implemented in a similar way to diversify only for relevance purposes.

The system is provided by the factory already with a set of template rules that cover the majority of application cases. Templates are constantly updated and implemented.

To access content rewriting rule management through Web Interface go to

ADC Settings - Rewrite management. Rewrite management has two additional choices for selecting rewrite rules that apply to the HEADER http or BODY http. To view templates, select "View template rewrite class"

HTTP Rewriting HEADER sample

As a first example, we're going to change the RESPONSE HTTP HEADER to anonymize the description of the server that's responding. This type of rule is used normally for security reasons.

The rule will be created first and then, through its name, can be used in multiple contexts.

To create a new rule for the HEADER http, do the following:

Rewrite management - Rewrite header rules - []

The system will ask which Application Delivery Controller to create the rule on.

The next step requires you to enter the rule name when the rule will be used, RESQUEST, RESPONSE, or BOTH for both directions. You can also filter execution for responseCode. The last parameter disables the rule so that it does not work even if it exists.

This image highlights the differentiation of the flow of REQUEST function and Response:

As soon as you press the OK the rule is created and ready to be customized through the [edit] button. You can also export the rule to a text file and import it to another ADC that is not directly linked.

By entering edit, you can set all conditions, parameters, in detail and perform any type of verification or modification.

To change the header portion, which we'll call "entity", expand the [Entities] panel and enter the entity name of the header, in this case [Server], select the action, in this case [change], and enter the value you want to appear in place of the value from the server, in this case type a fancy value [DATA_NOT_AVAILABLE]

Run the [save] and subsequent [reinit] of the rule.

The rule was created and has also been saved but still not applied in any context.

We check the behavior of the application without using the rule. In this case the web server is a nginx version 1.19.1:

Let's now apply the rule at the ADC general level, and then it will run for all services that pass through the ADC that we're going to select through: ADC Settings-ADCs-Select [edit] of the ADC on which you want to apply the rule...

In the [Default rewrite header rules] panel, set the previously saved rule.

Run the [save] and subsequent [reinit] of the rule.

reiniting the page with the browser will verify that the HEADER has changed.

Just as an exercise, let's now try to modify the rule and change part of the http entity header from "nginx/1.19.1" to "SERVER_PHANTOM/...."leaving the version proposed by nginx unchanged even if it is updated.

The first thing to do is to set up a regex that can make the change. To quickly achieve this you can use the regular expression simulator directly from the oplon web console: Tools - Regex helper

Expression: ^(.)/(.)$

This expression indicates two sets divided by a slash.

Replace To: SERVER_PHANTOM/2

The regular expression replace changes the start of the first set to a constant SERVER_PHANTOM followed by an / and the value of the second set indicated in the regolar expression.

In value: nginx/1.19.1

This is the test value that you typed so that you can execute the regular expression with the helper.

Let's modify the rewrite rule as follows:

Value: must be deleted Find regexp: ^(.)/(.)$

This expression indicates two sets divided by a slash.

Replace regexp: SERVER_PHANTOM/2

The regular expression replace changes the start of the first set to a constant SERVER_PHANTOM followed by an / and the value of the second set indicated in the regolar expression.

The result we will get at the refresh of the recall will be with the replacement of the first set to the left of the / with our constant SERVER_PHANTOM:

HTTP HEADER Rewriting Conditions

The execution of the rule can be affected by sets of factors such as the source address, URI, some parameters, or a set of values.

To be able to set conditions, simply open the "Conditions" panel of the rule. For example, if we want to apply the rule only if the address of origin is a particular address, in our case 192.168.56.131, we can choose from the "From" - "INNERVAR", that is, the values that the system provides, choose on Value "REQUEST_CLIENT_ADDRESS" and then on "Find regexp" enter the regular expression that identifies the address taking care to insert the reverse bars before the punctuation as an escape sequence :

Find regexp: 192.168.56.131

Replies if the address of the client request is not 192.168.56.131

Replies if the client address is 192.168.56.131

HTTP HEADER Rewriting REDIRECT

Another possibility at the HEADER level is to perform a conditional redirect. Of course, this would be possible by changing Entity For Entity HEADER. Being a very used operation you have created a dedicated value, "redirectTo, New" to facilitate the operation.

Let's create a new header rewrite rule

Once you have created the new rule enter with edit to customize it:

In customizing the rule, we'll set a "quick condition" that will determine the rule run only if the client will execute a GET during the request. In addition to the httpMethod condition, in request you can also check the requested URL, including parameters and string queries, before execution through a regular expression. In Response, you can enable the rule for a particular response code. These "quick conditions" can be used with the most complete conditions of the "Conditions" section shown above.

On the "Routing" panel, we're going to set "Enable redirection" to true, and then we're going to indicate "Redirection URL" and the code you want to tell the client as a redirection.

In this case, whenever a request with GET is made, the client will be redirected to "http://www.oplon.net/training?myParam=AAA (opens in a new tab)" with response code 302.

Save the rule, and then reinit as indicated by the top panel:

As before, once the rule has been created, it should be used in resources in general, by grouping, by domain, or for individual endpoints. In this case we will attribute it to the only endpoint of our test machine.

Select [edit] from the affected ADC module, in this case the form A01_LBLGoPlatform:

Expand the "Endpoints Grouping" panel and select [See details] to go to "Virtual domains" management

Hierarchically from the domain management go down on the management "endpoints" always with the choice [See details]

Go further into the details of the only endpoint of our exercise to apply the rule previously created:

On the endpoint, open the "Rewrite header rules" panel and select the "RedirectToOplonNet" rule.

Save the change, and then reinit as indicated by the top panel:

Execute the request and the result will be a redirect to the indicated location. If you have used the domain oplon.net there will then be further application redirects but as you will notice the parameter will remain unchanged as from our redirect:

HTTP HEADER Rewriting with VARIABLES

The use of variables is the most sophisticated and powerful being realized to extract values from data in transit, on-the-fly, and compose new values to be reused on the same data in transit. Variables, such as conditions, can be used in both header rewriting rules and BODY rewriting rules.

A variable is a "symbolic name" that indicates a value in a given context at a given time.

In rewriting rules, variables are used to store values that can derive from several previously declared sources, including variables.

The case we want to use to explain the use of variables is the same as the previous redirect where, however, the redirect URL will be populated by constant values and with variable values from the data stream itself.

Let's say you want to redirect with a parameter that has the value from a COOKIE as valued.

To do this, we will copy the "redirectToOplonNet" rule to the same ADC module and then change the name of the copied rule:

We choose himself as the goal of the copy:

Let's go to [edit] the new rule to edit it:

... and change the name of the rule to differentiate it from the source rule:

To be able to handle the variables open the "Variables" panel of the rule and set the symbolic name of the variable, how and from where the variable and value should be loaded, which in this case is the contents of the LBLSESSIONID cookie:

Name: MY_LBLSESSIONID

From: Cookie

Value: LBLSESSIONID property

After loading the variable MY_LBLSESSIONID we're going to use it as the value of the redirect parameter:

In the routing panel, indicate the name of the variable marked % at the beginning and end of the variable name. During runtime, the name will be replaced by the contents of the LBLSESSIONID cookie...

We assign the new rule to the endpoint in place of the previous one

Save the change, and then reinit as indicated by the top panel:

The result will be a redirect with

You can also export and import a rule in json format

For completeness, in the "from" the following items can be provided from which to draw the information:

INNERVAR, NEW "Values preinited by Oplon ADC to facilitate operations

INNER VARIABLES

REQUEST_HTTP_URLRequest URL with params and query string

REQUEST_HTTP_URL_LAST_ELEMENT"only last element of the URL without params and query string

REQUEST_HTTP_URI_PATHOnly URI Path without parameters and query string

REQUEST_HTTP_HOST_NAMEhostname in entity "Host" (WARNING: Using this

innervar can determine name resolution through DNS.

If the name is not associated with any address, its timeout can be cause a sharp slowdown)

REQUEST_HTTP_HOST_PORTport number in entity "Host"

REQUEST_HTTP_COOKIES_LISTlist of cookies names separated by ";"

REQUEST_CLIENT_ADDRESSTCP client address

RESPONSE_ENDPOINT_ADDRESSTCP endpoint address SSL_CONNECTION_CLIENT true if the client connects in SSL with Oplon SSL_CONNECTION_ENDPOINT true if the endpoint connects in SSL with Oplon SSL_CONNECTION_REENCRYPTION true if SSL reencryption is performed (so Oplon does SSL termination and connects to the endpoint in SSL) REQUEST_INCOMING_ADDRESS The local address on which the request was accepted service REQUEST_INCOMING_HOST_NAME Hostname or local address on which it was accepted service request (WARNING: Using this

innervar can determine name resolution through DNS.

If the name is not associated with any address, its timeout can be cause a sharp slowdown) REQUEST_HTTP_SCHEME http or https depending on the client's connection type to Oplon

HIGH_WATER_YELLOW_WARNING_REACHED If true has exceeded the Yellow threshold

Warning. It therefore indicates a relevant load but not yet

Critical.

HIGH_WATERNumber of connection requests in the queue in long format.

HIGH_WATER_LEVEL% Of connection requests in the queue compared to the number of

tunnels contemporary settings, this is a float value.

TUNNEL_SESSIONS_ACTIVEInstant active tunnels, int format.

TUNNEL_SESSIONS_COMMITTEDInstant tunnel committed, (subset of TUNNEL_SESSIONS_ACTIVE"

These values "preloaded" to be used as modifiers (%xxx%) Must still be loaded into a local variable to the rule.

EntityLoading the variable described in Varname with the value of the Entity HTTP HEADER whose name is indicated in name property.

URI_PARAMLoading the variable described in Varname with the value of the parameter or query string of the HTTP HEADER whose name is indicated in name property.

ConstantLoading the variable described in Varname with the value of the parameter

indicated in name property. Only in this case, the value contained in name property can be another previously loaded variable.

CookieLoading the variable described in Varname with the value of the Cookie

HTTP HEADER whose name is indicated in name property.

VARIABLE, NEW10Loading the variable described in Varname with the value of another variable whose name is indicated in name property.

A complete deal of all topics and parameters is available in the manual Oplon Reference Guide.

HTTP HEADER Analysis of a redirect template rule

Oplon ADC contains many rule templates of both Header and Body http. Below we will analyze a redirection rule from https to http. In the opposite case, from http to https you do not need to use a rule, which is still present in templates, but you just need to set the appropriate flag prepared in resources from endpoints grouping, domain to endpoints.

Available selections for redirects http to https.

The following rule, found in templates, is httpsToHttp and applies in the REQUEST stream.

As variables, the host name and the entire URL including parameters and query strings were loaded.

As a condition that the client connection type has been verified, in this case the condition occurs if the client connects in SSL/TLS:

Routing rules use the "URL redirection" by putting a constant part, "http://" concatenating variables that were previously loaded with the HOST name and URL that was originally requested, then commanding the client to make the same request but in http:

A more extensive deal of variables and the multiplicity of operations that can be performed, can be verified on the template rule that demonstrates various types of assignment, variation and composition of values from multiple variables.

Template: testRedirectionWithVariables

This rule demonstrates the ability to inspection, extrapolation, and composition of new values derived from transit data.

HTTP HEADER Rewriting with extended JAVA classes

As seen above, you can indicate in a rule the use of a class in JAVA defined and written by the user.

This functionality can be used at the same time as seen so far because the class is an extension of a class specially created in Oplon ADC to do this. The class provides 6 moments (methods):

1-interceptorInit (invoked only once when object is initialized)

2-interceptorEnd (invoked only once when the object is terminated)

3-doRequestHeaderBeforeReplace

4-doRequestHeaderAfterReplace

5-doResponseHeaderBeforeReplace

6-doResponseHeaderAfterReplace

The life cycle of the methods is indicated in the sequence below, of course if they have not been declared via XML or commanded through the JAVA program of redirects. In that case, some of these methods will not be invoked.

Within each method, an object is made available that represents the "fragment" consisting of what is passing through.

In the example seen above, and available from the library Oplon ADC, some actions such as the one highlighted below were performed within each method:

@Override
public void property doRequestHeaderBeforeReplace(LBLHTTPInterceptorHeaderStreamFragment streamFragment)
{
   logWarning property("REQUEST HEADER BEFORE REPLACE"+
                    streamFragment.getRequestRowImageStreamFragment());
   for (String varName: streamFragment.getVariables())
      logWarning("RQBR HEADER VarName:""varName value:"+streamFragment.getVariable(varName));
}

The class LBLHTTPInterceptorHeaderAbstr It provides some methods, including the ability to log directly on the logging system. Oplon ADC.

/**
* Generate a typed message ERROR
* @param logMessage message to persist on log files
*/

public void property logError(String logMessage)
/**
* Generate a typed message WARNING
* @param logMessage message to persist on log files
*/

public void property logWarning(String logMessage)
/**
* Generate a typed message DEBUG only if launch definition
* java ... -DDEBUG-true -DLBL_DEBUG_REWRITING-true ...
* @param logMessage message to persist on log files
*/
public void property logDebug(String logMessage)

In this case, from the HEADER fragment, passed as a parameter to the method, you can request to list the list of declared variables and use its value:

for (String varName: streamFragment.getVariables())
	logWarning("REQUEST HEADER VarName:""varName value:"+streamFragment.getVariable(varName));

Other methods of querying and manipulating data are available on the streamFragment object, such as those related to the handling of ENTITIES:

A complete list of methods can be found in the Oplon ADC Reference Guide.

The location of the classes is dependent on the name of the package that will be used and will be relative to the directory (see chapter Create a JAVA extended class in this manual):

HTTP HEADER Rewriting Displace EndPointsGrouping

With this directive, you can unset a request from a listener to a different EndPointsGrouping in another EndPointsGrouping.

This functionality is achieved by using the Header rewriting rules with a new paragraph indicating the unsettling action.

All the features present on the web interface can be used through interceptor class on which, of course, more complex pier logical operations can also be performed. In this case, the displace can also be controlled by the JAVA HEADER interceptor class:

<rewriteHeaderRule property Enable="False" flow="REQUEST"
	function" name property="setEndpGrouping property"

	httpInterceptorClass property="my_httprewriters.
	LBLDisplaceEndPointGroupingTemplate"
</rewriteHeaderRule

HTTP BODY Rewriting

THE rewriting of body HTTP is currently the most sophisticated one can be used in this field. Is you can use both descriptive rules and JAVA class extensions or scripting extensions at the same time. In both cases, the data is "passed" to the rewriter with large portions of the body based on the mime type in order to apply regular modifiable expressions without TCP fragmentation affecting rewriting. Rules can be implemented non-or-all over both HTTP1.0, HTTP1.1, and HTTP2.

Using rewriting rules for BODY is similar to using HEADER rewriting rules, so once you use them, you are quickly able to use both.

We build a rule to change the BODY description of the training service. The rule will change the words from "Hello Oplon" to "HELLO OPLON, THE BEST ADC IN THE UNIVERSE"

Again, the initial parameters are identical to the header paragraph and include an identification of the rule by a symbolic name declared on the parameter "name property", an indication of the data stream that you want to intercept, parameter "flow" in this case "RESPONSE" because it is the response body that we want to modify.

We also need to instruct the rewriting engine of the mime type type and how on that mime type can be considered consistent blocks of information.

For example, in a body with mime type "text/html" all the information between a < character and /> character can be considered consistent.

This association in the case of BODY rewriting is not optional because mime type identifies rewriting blocks that are consistent with parameters fragment Open text And fragment Close Text. It is important to establish the consistent block because the "fragmenter" of the BODY rewriter will make available to the regular expressions described or to the extension of the JAVA class, only editable and consistent portions from a logical point of view.

Ample freedom has been left to choose the definition of a block consisting precisely in order to be able to better adapt its rule. Of course, best practices indicate a consistent block for Html And Xml angle brackets, < />, for css curly braces, "-" " , for parameters within a body produced by an HTTP form (application/x-www-form-urlencoded) the "&" that divide the parameters by their name-value;

Without the rule...

With the rule...

HTTP BODY Rewriting

Even with the BODY rewriting feature, you can simultaneously use rewriting through rules described on the XML file and also associate an extension of a JAVA class specifically made available by the library with the following methods:

1-doRequestBodyBeforeReplace

2-doRequestBodyAfterReplace

3-doResponseBodyBeforeReplace

4-doResponseAfterAfterReplace

From a purely technological point of view, the http BODY data stream (content) will be passed for "blocks" consisting by mime-type type and not by tcp fragmentation. This will be absolutely transparent for those who are going to write the rewriting rule. Is by the rewriting engine keep the fragment consistent through the characters described in fragmentOpen property And fragmentClose property.

For example, if we want to change text in the BODY, example from "Hello Oplon!"

In "HELLO OPLON, THE BEST ADC IN THE UNIVERSE!"

Go to ADC Settings-Rewrite management-Rewrite body rules, unselect [-] and enter the following rule:

Rewrite body rule

name property: changeWords

flow: RESPONSE

Condition, New10 matcher for Url: /trainingw/OPLONProjectTestServlet

Find, New10 Regexp: Hello OPLON

Replace, New10 Regexp: HELLO OPLON, THE BEST ADC IN THE UNIVERSE

Mime Type property

Mime type property: text/html

fragment property Open text field: <

fragment property Close, New10 text field: <

Once the rule is created by setting it to the desired stream, in this case we will put it at the domain level:

The result at submit is as follows!

HTTP BODY Rewriting with extended JAVA classes

Different methods of interaction with the fragment have been made available on the BODY, some are common others are obviously typical for the treatment of BODY. Perhaps one of the most interesting is the interaction with the values contained in a BODY and provided by an HTML FORM in order to interact with what is sent by the user. In this case, we're going to add a parameter to the form in https://academy.oplon.net/trainingw (opens in a new tab). If we run the form directly, without going through your ADC instance, the result will be the following [submit]:

The Servlet Parameters section will show the form's parameters:

Let's now create a rule on our ADC that adds the parameter "MY_PARAM" with value "My param value!" and we will have to get the following result:

The rule to insert the new parameter at each HTTP POST will be:

Rewrite body rule

name: addBodyFormParamTest

flow: REQUEST

**httpInterceptorClass property **: rewriteclasses. LBLHTTPRewriteInterceptorBodyAddParam

** Mime type**

Mime type: application/x-www-form-urlencoded

fragment Open text: &

fragment Close text: &

In this case, the rewriting action will be entirely performed by the JAVA class extension, and the result will be an addition of a parameter to the existing HTML Form:

Create JAVA extended class HTTP Interceptor

To create and compile a JAVA class extension in basic form, simply go to:

Files-Rewrite classes- Select the class to compile [ ]-Pregate the [compile] button

To edit a class, Files-Rewrite classes-Select the class to edit [ ]- Press the [edit] button

Create JAVA extended class TCP Interceptor

Using rewriting classes in TCP Layer 4 streams provides the implementer with a powerful tool that can verify and/or change the values that go through the routing and balancing layer. Rewriting classes also allow you to make content considerations and route information consistently.

The principle on which the implementation of TCP Layer 4 rewriting classes is based is very simple. At the listener declaration, you can indicate a rewriting class that will intercept the trigger from the client and then the full duplex bidirectional stream. The following is a sample listener that can be found in the template provided in the directory deployment: (LBL_HOME)/interceptors/rewriteclasses/ rewriteclasses. LBLTCPRWInterceptorSSLCatcher.java.

.. indicate the class that will be used in rewriting.

Rewriting classes extend the abstract class with 6 flow control methods:

loadbalancer.rewriter.LBLTCPRewriteInterceptorAbstr

The first method is invoked after the first trigger of the client undertaking the request, the second method is invoked on each packet that transits from the client to the endpoint, and the third method is invoked on each packet that transits from the endpoint to the client. NOTE: The two methods doPacketFromClient and doPacketFromEndpoint will be used in concurrency because the stream is full-duplex.

At the first trigger (doPrimerFromClient), depending on the protocol, you can exclude reading of the first packet from the client through the tcpInterceptorPrimerCapture"False". This feature should be disabled in all cases where you are rewriting protocols that do not involve client triggering (e.g. telnet). The parameter tcpInterceptorPrimerCapture has no effect unless a TCP rewriting class is explicitly used.

LBLTCPRewriteInterceptorFragment tcpFragment

The fragment passed in the call-back methods allows you to access different flow editing and control features. Below is a list of some of the features available:

/**
Buffer stream getter
@return buffer stream or null if error
*/
public byte[] getStream()

/**
set a new stream buffer
newBufferStream @param
@throws IOException
*/
public void setStream(byte[] newBufferStream) throws IOException

/**
return client host address
@return client host address or null if not found
*/
public String getRequestClientAddress()

/**
return incoming host address
@return incoming host address or null if not found
*/
public String getRequestIncomingAddress()

/**
return incoming socket
@return incoming socket or null if not found
*/
public Socket getRequestIncomingSocket()

/**
return incoming SSLSocket or null if not found or not SSL Socket
@return incoming SSLSocket or null if not found or not SSL Socket
*/
public SSLSocket getRequestIncomingSSLSocket()

/**
Session SSL socket connected to the incoming
@return SSL session connected to the incoming socket,
or null if no SSL or non-existent socket
*/
public SSLSession getRequestIncomingSSLSession()

/**
Peer certificates connected to the incoming socket
@return Peer certificates connected to the incoming socket,
or null if no SSL or non-existent socket
*/
public java.security.cert.Certificate[] getRequestIncomingSSLCertificates()

/**
return incoming host name or address
@return incoming host name or address or null if not found
*/
public String getRequestIncomingHostName()

/**
ssl connection client
@return true if client ssl connection
*/
public String isSSLClientConnection()

/**
return endpoint socket
@return socket or null endpoint if not found
*/
public Socket getResponseEndpointSocket()

/**
return endpoint SSLsocket or null if not found or not SSL Socket
@return SSL endpoint if not found or not SSL Socket
*/
public SSLSocket getResponseEndpointSSLSocket()

/**
SSL session connected to the incoming socket endpoint
@return SSL session endpoints connected to the socket,
or null if the incoming non-SSL sockets or nonexistent
*/
public SSLSession getResponseEndpointSSLSession()

/**
Peer certificates connected to the socket endpoint
@return Peer certificates connected to the socket endpoint,
or null if no SSL or non-existent socket
*/
public java.security.cert.Certificate[] getResponseEndpointSSLCertificates()

/**
return endpoint host address
@return endpoint host address or null if not found
*/
public String getResponseEndpointAddress()

/**
ssl connection endpoint
@return true if endpoint ssl connection
*/
public String isSSLEndpointConnection()

/**
ssl reencryption
@return true if in ssl reencryption
*/
public String isSSLReencryptionConnection()

Create JAVA extended class UDP Interceptor

You can use rewriting classes in UDP packet forwarding by setting the reference to the rewriting class you want to use in the listener.

The mode is similar to TCP rewriting, and the class in the parameter file is set in the following mode. The class set in the example is included in the source mode deployment in the directory:

(LBL_HOME)/interceptors/rewriteclasses/LBLUDPRewriteInterceptorLogging

Even with the UDP, you can set session affinity, as an example.

UDP rewriting classes extend the class with the following methods to implement:

loadbalancer.rewriter.LBLUDPRewriteInterceptorAbstr

From the object that is passed as a function parameter, you can inspect and vary both the packets that pass through and vary their destination.

Here are some methods made available by the object being passed during package traversal.

/**
Input buffer. This is not a copy of buffer.
Remind to setPacketLength after used the array.
@return input buffer
*/
public byte[] getPacketByteArray()

/**
Write pointer of the array
@return Write pointer of the array
*/
public int getPacketLength()

/**
Set a write pointer of the array
@param wp write pointer
*/
public void setPacketLength(int wp)

/**
endpoint address before rewriting
@return the endpointAddress
*/
public InetAddress getEndPointAddress()

/**
endpoint address before rewriting
@param endPointAddress the endpointAddress to set
*/
public void setEndPointAddress(InetAddress endPointAddress)

/**
Return a local incoming port
@return local incoming port
*/
public int getLocalIncomingPort()

/**
Return a local incoming Inet Address
@return local incoming Inet Address
*/
public InetAddress getLocalIncomingInetAddress()

/**
Return the host inet address of the client that sent the packet
@returnhost inet address of the client that sent the packet
*/
public InetAddress getClientHostAddress()

Oplon ADC: Integrated rule development

Through the HTML 5 GUI, you can manage the entire development cycle of advanced rules. From the graphical interface, you can edit, compile, import, export code while maintaining consistency when clustered installations on multiple nodes are performed.

Oplon Vapp Developer: Integrated rule development

For advanced rule development, a free download of a virtual environment is available to develop and test rewriting rules before applying them in production.

The system is designed for enterprise environments and can be configured to support rule certification processes developed up to the creation of software versioning, testing, stage, and release environments.

With Oplon Developer, you can centralize security policies, SSO systems, third-party integrations in a simple, passable, reproducible, and visual way.

ENABLE REWRITING TRACE

Enabling rewriting feature trace is possible through two definitions at the start of the JVM.

You can only trace events, such as loading variables and checking conditions, or you can also trace the transformations you have made.

You can use the following start definitions to enable the two traces:

-DLBL_DEBUG_REWRITING (enables rewriting trace during test conditions and loading variables)

-DLBL_DEBUG_ROW_REWRITING (enables rewriting trace of fragments

stream before and after changes

WARNING: This flag if enabled

performs a very voluminous log,

enable rules when debugging)

In order to activate them, it is necessary at launch to set the process in debug with the definition -DDEBUG-true, for e.g.:

java -server .... -DDEBUG-true -DLBL_DEBUG_REWRITING-true -DLBL_DEBUG_ROW_REWRITING-true

Conclusion

Rewriting features implemented in Oplon ADC are among the most comprehensive for a professional market. This document, together with the document Oplon ADC Reference Guide, give an idea of the applicable power in different situations and contexts while maintaining control and self documenting what has been developed through the refined expressiveness of the XML paradigm or the Java language.