CN101136834B

CN101136834B - SSL VPN based link rewriting method and apparatus

Info

Publication number: CN101136834B
Application number: CN2007101632225A
Authority: CN
Inventors: 薛明; 梁鹏; 韩小平
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: New H3C Technologies Co Ltd
Priority date: 2007-10-19
Filing date: 2007-10-19
Publication date: 2010-06-02
Anticipated expiration: 2027-10-19
Also published as: CN101136834A

Abstract

The method includes following steps: SSL VPN gateway receives request for accessing incomplete absolute link (IAL) from remote host; SSL VPN gateway rewrites IAL; SSL VPN gateway sends redirected pageincluding rewritten IAL. The invention also discloses a SSL VPN gateway device. The invention makes SSL VPN gateway possible to guide browser to obtain correct page even in condition of unable to rewrite 'IAL' returned by remote host. The invention reduces intensity of parsing web page language by SSL VPN gateway, lowers difficulty for developing and maintaining product so as to make SSL VPN gateway possess stronger fault tolerant capability.

Description

SSL VPN-based link rewriting method and device

Technical Field

The invention relates to the technical field of networks, in particular to a link rewriting method and device based on SSL VPN.

Background

The SSL VPN is a VPN (Virtual Private Network) technology that realizes remote access by using SSL (Security Socket Layer) encryption connection. The function of SSLVPN is shown in fig. 1. Wherein,

SSL connection is established between the remote host and the SSL VPN gateway, and messages are transmitted on the Internet in an encryption mode; the SSL VPN gateway terminates the SSL connection, establishes a TCP (Transmission Control Protocol) connection with the server in the intranet, transmits a request sent from the remote host in a plaintext manner, and sends a response from the server to the remote host through the SSL connection.

The URL link types in the page include:

(1) and (4) fully linking.

A full link refers to a link that contains a protocol, a hostname, and a path in the link, for example:

the statement represents: http for transport protocol, www.h3c.com for host, and/tech/index.

By including the address of the host to be accessed by the full link, clicking on such a link, the browser will establish a new connection with the designated host www.h3c.com and request the corresponding page from the host.

(2) Incomplete absolute linking.

Incomplete absolute links mean that the link does not contain transport protocols and host addresses, but only absolute paths relative to the root directory of the site.

For example: < a href [ "/portal/Home/Login" ]

Note: the "/" at the beginning of the path indicates the root directory.

The incomplete absolute link does not have a transport protocol specified, and the browser defaults to using the transport protocol of the current web page. If the current webpage uses the http protocol, accessing the link also uses the http protocol; if the current web page uses the https protocol, accessing the link also uses the https protocol.

In addition, incomplete absolute links also do not specify a destination host, and the browser defaults to the source host using the current page. Access to this link will initiate a connection to the source host of the current page. Only the directory and page to be accessed are illustrated in the link, which is "/portal/Home/Login".

(3) Incomplete relative linking.

Incomplete relative links are similar to the incomplete absolute links described above, in that the links do not contain transport protocols and host addresses, except that the path contained is not the root directory of the web site, but rather a path relative to the current web page.

For example: < a href./Login >

Note: "at the beginning of the path indicates the parent directory of the current page.

In this example, if the path of the current page is "/portal/Home/index. htm", the path represented by "./log" is "/portal/Home/log".

When the accessed intranet server is a Web server, the SSL VPN can realize the access of the remote host to the intranet Web site by adopting a Web agent mode. The process is shown in figure 2. Wherein, the box in the figure represents the returned message; WS1 represents the IP address of Web server 1; on the SSL VPN gateway, it is assumed that all connections are mapped under the "/svpn/" directory.

As shown in fig. 2, the process of accessing the intranet Web site in the Web proxy mode is as follows:

step s201, the SSL VPN gateway maps each accessible intranet web resource address to a virtual path on the SSL VPN gateway. A mapping table of a form similar to the following is maintained by the SSL VPN gateway:

/svpn/web1/

http://www.abc.com/xyz/

/svpn/web2/

http://www.efg.com/xyz/uvw/

/svpn/web3/http://www.abc.com/hij/rst/

this table is hereinafter referred to as the "virtual-real path mapping table".

Step s202, the user logs in the SSL VPN gateway through the Web browser using the https protocol to obtain a list of accessible Web sites.

The links in the list all point to the SSL VPN virtual gateway path corresponding to the resource. For example:

step s203, the user clicks these links, the remote host establishes SSL links with the SSL VPN gateway, and sends an Http request pointing to the virtual path, for example:

GET/svpn/web1/HTTP/1.1

Host：x.x.x.x

wherein "x.x.x.x" is the address or domain name of the SSL VPN gateway, followed by GET is the path where the Web page is located. "HTTP/1.1" is a version of the protocol. Other fields in the Http request are not related to the working process of the SSL VPN gateway and are not described here.

The remote host can only send a request to the SSL VPN gateway because only the device has a public network address, and the intranet server does not have a public network address, and the remote host cannot directly access the SSL VPN gateway.

Step s204, SSL VPN gateway terminates SSL connection, converts Http request,

and the SSL VPN gateway can find the real URL corresponding to the virtual path according to the virtual path mapping table, modify the relevant fields in the http request and then forward the fields. For example, the request in step s203 is modified to:

GET/xyz/HTTP/1.1

Host：www.abc.com

the translated request will be sent to server "www.abc.com" requesting a page under the "/xyz/" directory.

And step s205, the Web Server1 returns the page of the response to the SSL VPN gateway.

The page contains links of the form: (there are many forms of representing links in html pages, and only the href field is used as an example in the following)

a)<a href＝″http://www.abc.com/xyz/123/a.htm″>

b)<a href＝″http://www.efg.com/xyz/uvw/456/b.htm″>

c)<a href＝″http://www.abc.com/hij/rst/″>

d)<a href＝″/abc/789.htm″>

e)<a href＝″/abc/efg/lmn.htm″>

f)<a href＝″../uvw/opq.htm″>

Links a), b) and c) are "full links" and all point to an intranet server address, and such links are not accessible on the extranet.

Links d) and e) are "incomplete absolute paths" and point to a fixed directory on the origin server. These directories are not virtual directories on the SSL VPN gateway, and if the user directly requests such a path from the gateway, the SSL VPN gateway cannot find the corresponding intranet resources, and thus cannot process correctly.

Link f) is an "incomplete relative path", without overwriting, that is to the relative path with respect to the current web page. If the current path is a virtual path on the correct SSL VPN gateway, the path is still directed to a virtual path on the SSL VPN gateway.

And step s206, according to the mapping table, the SSL VPN gateway rewrites the URL of the page returned by the intranet, so that the original http link is changed into the https link, and the original links pointing to the intranet server are all mapped into the path on the SSL VPN gateway. The links of the page in step s205 should be rewritten into the following form:

a)<a href＝″/svpn/web 1/123/a.htm″>

b)<a href＝″/svpn/web2/456/b.htm″>

c)<a href＝″/svpn/web3/″>

d)<a href＝″/svpn/web1/abc/789.htm″>

e)<a href＝″/svpn/web1/abc/efg/lmn.htm″>

f)<a href＝″../uvw/opq.htm″>

links a), b), c) replace the directory corresponding to the link with the virtual path on the SSL VPN gateway according to the virtual-real path mapping table. The original 'complete link' is rewritten into the 'incomplete link', so that the link inherits the transmission protocol type of the current page, and the transition from http to https is realized.

Links d) and e) are rewritten by determining the corresponding virtual path root directory to be "/svpn/web 1/" according to the address of the intranet server.

Link f) is not modified.

And step s207, the SSL VPN gateway returns the rewritten page to the remote host.

In the above implementation, URL rewriting is critical. The SSL VPN gateway must rewrite the URL link in the intranet return page to point to the SSL VPN gateway and change the transport protocol from http to https. Otherwise, the user in the external network can not obtain the page of the internal network through the SSL VPN gateway.

At present, most of Web pages are dynamically generated, many links on the pages are spliced by expressions of javascript, and the direct searching and replacement by a mode matching method are difficult to adopt. And thus URL rewriting is difficult to implement.

For a "full link," if such a link is not overwritten, the user clicks on and the browser will establish a link directly with a host such as "www.abc.com," which is an intranet server address and thus inaccessible. For such problems, the SSL VPN gateway has no remedial measures.

For "incomplete relative linking", no overwriting is required.

For the incomplete absolute links, when the user clicks the links, the request is still sent to the SSL VPN gateway, and although the SSL VPN gateway cannot find the corresponding virtual path, the SSL VPN gateway may give a correction according to some mechanism, and send a redirection message to the browser of the user to guide the browser to access the correct path.

At present, most SSL VPN products adopt a syntax analysis method to carry out syntax analysis on html pages and javascript scripts and rewrite all places related to URL links. However, because the html language and the javascript language are relatively complex, the difficulty of parsing the html language and the javascript language is large, and the html language and the javascript language are difficult to process perfectly.

For example, the following is a script for an intranet server to dynamically generate a page for sending to a remote host:

<！--

infoTree＝new dTree(′infoTree′)；

infoTree.config.useCookies＝false；

var menuCode＝″IPD″；

if(menuCode＝＝′RND-005-001′||menuCode＝＝′RND-006-001′||

menuCode＝＝′RND-006-002′ || menuCode＝＝′RND-007-001′ ||

menuCode＝＝′RND-008-001′)

{

info Tree.add(0，

-1，

′IPD ′，

′/jsp/process/outline.doparam＝IPD′，

null，

″leftFrame″)；

}

else

{

infoTree.add(0，

-1，

′IPD ′，

′/jsp/process/outline.doparam＝IPD′，

null，

″mainFrame″)；

}

the dynamic page is a page generated by executing a script by a browser. In the script, info tree.add () is a script function defined by a user, and a menu item can be dynamically generated, so that a link pointed by the menu item is also dynamically generated, for example,'/jsp/process/output included in the script of the page. .

When such a page passes through the SSL VPN gateway, the SSL VPN gateway cannot identify where the links are according to html syntax, for example, '/jsp/process/outline. doparam ═ IPD' in the above example is the link of the menu item, and these links are used as info tree. URL rewriting of such dynamically generated pages by the SSL VPN gateway is very difficult. In addition, because the Web technology is developed quickly, new standards and new page elements are continuously generated, html and javascript languages are continuously changed, and the realization version of the SSL VPN gateway is required to be continuously upgraded.

Based on the above analysis, the SSL VPN gateway cannot perform effective rewriting on some incomplete absolute links in the page sent to the remote host according to syntax parsing and the virtual-real path mapping table on the gateway, so that when the remote host tries to access the links on the page that are not effectively rewritten, an effective link cannot be found to obtain correct content.

Disclosure of Invention

The invention provides a link rewriting method and equipment based on SSL VPN (secure socket layer virtual private network), which are used for ensuring that a remote host can still acquire a correct page when the remote host requests to access an incomplete absolute link which is returned by an intranet server and cannot be rewritten correctly.

In order to achieve the above object, the present invention provides a link rewriting method based on SSL VPN, comprising the following steps:

the SSL VPN gateway receives a request of a remote host for accessing an incomplete absolute link, wherein the incomplete absolute link is a link which cannot be effectively rewritten before passing through the SSL VPN gateway;

the SSL VPN gateway rewrites the incomplete absolute link, and specifically, the SSL VPN gateway determines whether a refer field exists in a request of the remote host to access the incomplete absolute link;

when the judgment result is yes, the SSL VPN gateway acquires a virtual gateway path carried by a Referer field of the request, judges whether the virtual gateway path carried by the Referer field is correct, and replaces a corresponding path in the request by using the virtual gateway path carried by the Referer field when the virtual gateway path carried by the Referer field is correct;

when the judgment result is negative, the SSL VPN gateway acquires a virtual gateway path corresponding to the request by using a virtual gateway path which is stored in advance and is associated with the SSL link of the request, and replaces the path corresponding to the request by using the virtual gateway path;

the SSL VPN gateway sends a redirection page including the rewritten incomplete absolute link to the remote host.

Wherein, before the step of receiving the request of the remote host to access the incomplete absolute link, the SSL VPN gateway further comprises:

the SSL VPN gateway directly sends the incomplete absolute link which is not rewritten to the remote host when the incomplete absolute link which is sent to the remote host by the intranet server cannot be rewritten according to the corresponding relation between the local virtual gateway path and the intranet server resources;

the receiving, by the SSL VPN gateway, a request for accessing the incomplete absolute link by the remote host specifically includes:

the SSL VPN gateway receives a request by the remote host to access the incomplete absolute link that is not overwritten.

The step of determining whether the virtual gateway path carried by the refer field is correct specifically is:

judging whether a virtual gateway path corresponding to the virtual gateway path in the refer field exists in the corresponding relation between the local virtual gateway path and the intranet server resource or not, or whether a superior directory of the virtual gateway path corresponding to the virtual gateway path in the refer field exists or not, and if so, continuing;

and judging whether the requested path is located under the intranet site path corresponding to the virtual gateway path in the refer field, if so, judging that the virtual gateway path carried by the refer field is correct.

Wherein, before the step of obtaining the virtual gateway path corresponding to the request by using the virtual path associated with the SSL link stored in advance, the method further comprises:

for a correct page request, the corresponding virtual gateway path is saved and associated with the SSL link that received the request.

The redirection page is an http protocol 307 number-based response message including the rewritten incomplete absolute link, or a redirection page based on an http protocol.

The present invention also provides an SSL VPN gateway device, configured to rewrite an incomplete absolute link requested to be accessed by a remote host, where the incomplete absolute link is a link that has not been rewritten before passing through an SSL VPN gateway, and the SSL VPN gateway device includes:

a remote host interface for sending a request for the remote host to access the incomplete absolute link to the link rewriting unit; sending the redirection message which is generated by the redirection message generation unit and comprises the rewritten link to the remote host;

the link rewriting unit is used for rewriting the incomplete absolute link which is received from the remote host interface and requested to be accessed by the remote host, and sending the rewritten link to the redirection message generating unit;

a redirection message generating unit, configured to generate a redirection message according to the rewritten link sent by the link rewriting unit, and send the redirection message to a remote host interface;

the link rewriting unit further includes: the judging subunit is used for judging whether a refer field exists in a request of the remote host sent by the remote host interface, and if the refer field exists, sending the request to the first link rewriting subunit; otherwise, sending the data to a second link rewriting subunit; a first link rewriting subunit, configured to replace a corresponding path in the request with a virtual gateway path carried by the Referer field in the request; the second link rewriting subunit is used for replacing the corresponding path in the request by using the virtual gateway path which is stored in advance by the SSL link association storage subunit and is associated with the SSL link of the request; and the SSL link association storage subunit is used for saving the corresponding virtual gateway path for the correct page request and is associated with the SSL link receiving the request.

Wherein, still include:

and the resource configuration unit is used for establishing a corresponding relation between the virtual gateway path and the intranet server resources so as to be used by the link rewriting unit when the link is rewritten.

Compared with the prior art, the invention has the following advantages:

in the case of "incomplete absolute link" returned by the SSL VPN gateway before the remote host requests access, which cannot be rewritten effectively, the SSL VPN gateway can still guide the browser to get to the correct page. Therefore, the strength of analyzing the web page language by the SSL VPN gateway is reduced, the difficulty of product development and maintenance is reduced, and the SSL VPN gateway has stronger fault tolerance capability.

Drawings

FIG. 1 is a functional schematic diagram of a prior art SSL VPN;

FIG. 2 is a schematic diagram of a prior art Web proxy and URL rewrite;

FIG. 3 is a flow chart of a link rewriting method based on SSL VPN in the present invention;

FIG. 4 is a flowchart of obtaining a virtual gateway path corresponding to a request according to a refer field in the present invention;

fig. 5 is a schematic structural diagram of an SSL VPN gateway device according to the present invention.

Detailed Description

The core idea of the invention is to provide a link rewriting method based on SSL VPN, which rewrites the 'incomplete absolute link' returned by the intranet server which the remote host requests to access according to the relevant content in the request message, so that even if the link of the 'incomplete absolute link' is not effectively rewritten by the gateway for some reason before, the requested access content can be finally returned to the remote host.

Fig. 3 shows a link rewriting method based on SSL VPN, which includes the following steps:

step s301, the SSL VPN gateway receives a request for access by a remote host to an incomplete absolute link.

Specifically, the incomplete absolute link requested to be accessed by the remote host is a link that cannot be rewritten effectively before passing through the SSL VPN gateway, and the reason why the incomplete absolute link cannot be rewritten may be as described above, so that the SSL VPN gateway cannot rewrite the incomplete absolute link sent by the intranet server to the remote host according to the correspondence between the local virtual gateway path and the intranet server resource. The SSL VPN gateway then sends the incomplete absolute link that is not overwritten directly to the remote host. While the remote host may access those links in later operations that were not previously validly rewritten through the SSL VPN gateway.

And step s302, the SSL VPN gateway rewrites the incomplete absolute link.

The rewriting method may be two methods:

(1) if there is Referer field in the request head, the correct gateway virtual path is extracted from the request head, and the corresponding path in the original request is replaced according to the virtual-real path mapping table, so as to generate the correct gateway virtual path.

(2) And if the header of the http request does not have a refer field, taking the previously stored correct gateway virtual path associated with the SSL link as the gateway virtual path of the request, and replacing the corresponding path in the original request, thereby generating the correct gateway virtual path.

Step s303, the SSL VPN gateway sends a redirection page including the rewritten incomplete absolute link to the remote host.

The embodiments of the present invention will be described in further detail below with reference to the drawings and examples.

First, a case where a refer field is present in the request header will be described. For the http request including the refer field in the request header, a correct SSL VPN path may be extracted from the refer field in the http request header, and then the correct SSL VPN path may be obtained by adding the path of the http request. According to the Http protocol, the refer field records the page from which the requested link originates, and the access path of the page should be a correct SSL VPN virtual gateway path, otherwise the page cannot be acquired.

In the embodiment of the present invention, it is assumed that the http request header format sent by the client to the gateway device is as follows:

GET/xyz/home/login/HTTP/1.1

Accept：*/*

Referer：https://x.x.x.x/svpn/web1/

Accept-Language：zh-cn

Accept-Encoding：gzip，deflate

User-Agent：Mozilla/4.0(compatible；MSIE 6.0；Windows NT 5.1；SV1；.NET CLR 1.1.4322)

Host：x.x.x.x

Connection：Keep-Alive

for the http request, a method for obtaining a correct virtual gateway path corresponding to the http request according to the refer field is shown in fig. 4, and includes the following steps:

and step s401, acquiring the virtual gateway path carried by the refer field.

In the http request header, the virtual gateway path carried by the refer field is: "https:// x.x.x.x/svpn/web 1/", where x.x.x.x is the address of the SSL VPN gateway.

And step s402, judging whether the virtual gateway path carried by the refer field is correct, if so, performing step s403, otherwise, not performing any operation.

Specifically, there are various implementation methods for determining whether the SSL VPN virtual gateway path extracted from the refer field is correct, and the following only exemplifies the feasibility of the method.

For example, a method of longest string matching is adopted, a virtual gateway path in the refer field is matched with a virtual path in the virtual-real path mapping table, and whether a virtual path corresponding to the virtual gateway path in the refer field exists in the virtual-real path mapping table or whether an upper directory of the virtual path corresponding to the virtual gateway path in the refer field exists is determined. If the path of the Referer is found to be correct, otherwise, the request is rejected.

For the Referer field "https:// x.x.x.x/svpn/web 1/" in this embodiment, it is assumed that such an entry can be matched in the "virtual-real path mapping table" maintained locally by the gateway device:

/svpn/web1/http://www.abc.com/xyz/

the virtual gateway path of the Referer is determined to be correct.

And s403, acquiring a site path corresponding to the virtual gateway path carried by the refer field.

In this embodiment, according to the virtual-real path mapping table, it is determined that the source page of the http request comes from the site path: http:// www.abc.com/xyz/, i.e. "/xyz/" directory at www.abc.com site.

And step s404, judging whether the path of the http request is positioned under the station path, if so, performing step s405, otherwise, not performing any operation.

The path of the http request in this embodiment is "/xyz/home/login/", and is located under the destination path "/xyz", and therefore, is located under the site path corresponding to the path carried by the refer field.

And step s405, replacing the corresponding path in the http request by using the virtual gateway path carried by the refer field.

In this embodiment, the virtual gateway path carried by the Referer field is used to replace a corresponding path in the http request, that is, "/xyz/home/login/", so as to obtain a corresponding virtual gateway path: "/svpn/web 1/home/login/".

For the http request without the refer field in the request header, the correct virtual gateway path stored previously and associated with the SSL link may be used as the virtual gateway path of the http request, and a method similar to the steps s401 to s405 may be adopted to generate the correct virtual gateway path.

Specifically, for links such as pictures or videos embedded in html pages, when the browser opens the pages, the objects are automatically downloaded. The header of the http request issued at this time has no refer field. The correct virtual path can be obtained by the following method:

according to the proposal of the Http 1.1 protocol, in order to improve the transmission efficiency, a normal connection is adopted when the embedded object is downloaded in the process of opening the page, and the original TCP connection (SSL connection) is kept disconnected. Multiple Http requests and their replies may be transmitted over one common connection.

For each correct page request, the corresponding virtual gateway path is saved and associated with the SSL link that received the request. And acquiring a correct virtual gateway path by using the correct request path at the last time.

Thus, http requests received from the same SSL connection are all destined for the same host. Therefore, after the virtual path of the html page is saved, if no Referer field exists in the subsequent Http request, the saved virtual path can be used to obtain the virtual gateway path corresponding to the request. The method for modifying the path is similar to step s405, and the previously saved virtual gateway path is used to replace the corresponding path in the http request.

For example: take an example that a remote host acquires a page named about, htm, which includes a picture image001. png. The browser first sends the following http request to the intranet server,

GET/svpn/web1/about.htm HTTP/1.1

Accept：*/*

Referer：https://x.x.x.x/svpn/web1/common/logo.jsp

Accept-Language：zh-cn

Accept-Encoding：gzip，deflate

Host：pal

Connection：Keep-Alive

Cookie：JSESSIONID＝FADAA0664DE15F231C57382909782BC1

because the requested URL is the correct virtual path on the gateway, the SSL VPN gateway can find the corresponding intranet URL, at this time, "/svpn/web 1/about. htm" is recorded as the URL which is stored in the SSL link and is accessed correctly last time, and then the request is forwarded to obtain about. htm page and returned to the far end.

Htm page in return embed a link to picture image001. png:

it is assumed that the link is not rewritten as a gateway virtual path due to complexity. And after the browser obtains the about page, the browser can automatically obtain the picture according to the picture link in the page. Then a request to get the picture is sent to the SSL VPN gateway, but without the refer field:

GET/xyz/about/about.files/image001.png HTTP/1.1

Accept：*/*

Accept-Encoding：gzip，deflate

Host：pal

Connection：Keep-Alive

Cookie：JSESSIONID＝FADAA0664DE15F231C57382909782BC1

the picture link involved in the request is "/xyz/about. files/image001. png", and the gateway does not rewrite the picture, so the request does not contain a gateway virtual path, and the request does not contain a refer field. At this time, the address "/svpn/web 1/about. htm" saved when the about. htm page was obtained in the previous step may be used as a refer field, and "/xyz/about. files/images 001. png" is rewritten with reference to the steps described in s401 to s404, so that the corresponding virtual gateway path is "/svpn/web 1/about. files/images 001. png".

Finally, for the corrected path, the gateway sends the path to the browser in a redirection message to guide the browser to access the correct virtual gateway path. The purpose is as follows: the browser is enabled to use the correct virtual gateway path in order to apply cookie and the like techniques.

The method for realizing redirection is various, the invention only exemplifies the following method, and the feasibility of realization is illustrated:

HTTP/1.1307 Temporary Redirect

Server：SSL VPN PROxY

Location：https://192.168.111.88/svpn/web1/images/ed_word.gif

Pragma：no-cache

Cache-Control：no-cache

Content-Type：text/html

Content-Length：278

<META HTTP-EQUIV＝″REFRESH″CONTENT＝″0；URL＝

https://192.168.111.88/svpn/web1/images/ed_word.gif″>

<TITLE>SSL VPN PROxY</TITLE>

</HEAD><BODY>

<A href＝″https://192.168.111.88/svpn/web1/images/ed_word.gif″>urlmoved</A>

</BODY></HTML>

in the above messages, the 307 number response message of the Http protocol is adopted for redirection, and an html redirection page is added, wherein a refresh method of the Http-EQUIV attribute of the META element is used to request the browser to refresh the page according to a specified path, thereby ensuring that redirection can be performed when the 307 number response message is not supported by the client browser. Assuming that the address of the SSL VPN gateway is 192.168.111.88, the request "GET/xyz/images/ed _ word. gif" is redirected to "192.168.111.88/svpn/web 1/images/ed _ word. gif", and the browser accesses the updated link through the response message number 307 or redirection interface.

By using the method of the invention, under the condition that the SSL VPN gateway returns 'incomplete absolute link' which cannot be effectively rewritten before the remote host requests access, the SSL VPN gateway can still guide the browser to acquire the correct page. Therefore, the strength of analyzing the web page language by the SSL VPN gateway is reduced, the difficulty of product development and maintenance is reduced, and the SSLVPN gateway has stronger fault-tolerant capability.

The invention also provides SSL VPN gateway equipment which is used for rewriting 'incomplete absolute link' in the page returned to the remote host from the intranet server. The structure of the SSL VPN gateway device is shown in fig. 5, and includes:

a remote host interface 10, connected to the link rewriting unit 30 and the redirection packet generating unit 40, for sending a request for accessing the incomplete absolute link from the remote host to the link rewriting unit 30; and sends the redirection message including the rewritten link generated by the redirection message generation unit 40 to the remote host.

The resource configuration unit 20 is connected to the link rewriting unit 30, and is configured to establish a "virtual-real path mapping table," which includes a corresponding relationship between the virtual gateway path and the intranet server resource, and is used by the link rewriting unit 30 when rewriting the link.

The link rewriting unit 30 is connected to the remote host interface 10, the resource configuration unit 20, and the redirection message generating unit 40, and is configured to rewrite an incomplete absolute link requested to be accessed by the remote host received from the remote host interface 10 according to the configuration of the resource configuration unit 20, and send the rewritten link to the redirection message generating unit 40.

And a redirection message generating unit 40, connected to the remote host interface 10 and the link rewriting unit 30, and configured to generate a redirection message according to the link when receiving the rewritten link sent by the link rewriting unit 30, and send the redirection message to the remote host interface 10.

Wherein the link rewriting unit 30 further includes:

a determining subunit 31, configured to determine whether a refer field exists in a request of the remote host sent by the remote host interface, and if so, send the request to the first link rewriting subunit 32; otherwise to the second link adaptation subunit 33.

And the first link rewriting subunit 32 is configured to replace the corresponding path in the request with the virtual gateway path carried in the refer field in the request.

And a second link rewriting subunit 33, configured to replace the corresponding path in the request with the virtual gateway path associated with the SSL link of the request, which is stored in advance by the SSL link association storage subunit 34.

The SSL link association storage subunit 34 is configured to save, for a correct page request, a corresponding virtual gateway path, and is associated with the SSL link that received the request.

By using the SSL VPN gateway device of the invention, the SSL VPN gateway can still guide the browser to acquire the correct page under the condition of 'incomplete absolute link' which is returned by the SSLVPN gateway and cannot be effectively rewritten before the remote host requests access. Therefore, the strength of analyzing the web page language by the SSL VPN gateway is reduced, the difficulty of product development and maintenance is reduced, and the SSL VPN gateway has stronger fault tolerance capability.

The above disclosure is only for a few specific embodiments of the present invention, but the present invention is not limited thereto, and any variations that can be made by those skilled in the art are intended to fall within the scope of the present invention.

Claims

1. A link rewriting method based on SSL VPN is characterized by comprising the following steps:

2. The SSL VPN based link adaptation method of claim 1, wherein the SSL VPN gateway receiving a request from a remote host to access an incomplete absolute link further comprises:

3. The SSL VPN-based link rewriting method of claim 1, wherein the step of determining whether the virtual gateway path carried in the refer field is correct specifically is:

4. The SSL VPN based link rewriting method of claim 1, wherein before the step of obtaining the virtual gateway path corresponding to the request by using the pre-saved virtual path associated with the SSL link, the method further comprises:

5. The SSL VPN-based link rewriting method of claim 1, wherein the redirection page is an http protocol 307 number-based response packet including the rewritten incomplete absolute link, or an http protocol-based redirection page.

6. An SSL VPN gateway device for overwriting an incomplete absolute link requested for access by a remote host, the incomplete absolute link being a link that previously failed to be overwritten validly when passing through an SSL VPN gateway, comprising:

7. The SSL VPN gateway device of claim 6, further comprising: