JP5982706B2 - Secure tunneling platform system and method - Google Patents

Description

[Cross-reference of related applications]
This application claims priority from US Provisional Patent Application No. 61 / 559,460, filed November 14, 2011, the entire contents of which are hereby incorporated by reference. This application is hereby incorporated by reference in its entirety: US Provisional Patent Application Nos. 61 / 559,460, filed Nov. 14, 2011, and Dec. 30, 2010. No. 13 / 339,807, filed Dec. 29, 2011, claiming priority of US Provisional Patent Application No. 61 / 428,620, filed on Dec. 29, 2011.

  The present application relates generally to network bandwidth sharing, and more specifically to secure tunneling as well as identifying users.

  Band sharing, such as Wi-Fi, is a practical solution that has the advantages as described in US Pat. No. 7,924,780 issued April 12, 2011, the same assignee as this application, The entire content of this document is incorporated herein by reference. Users accessing a communication network such as the Internet via Wi-Fi often share a public internet protocol (“IP”) address. For example, individual Internet service providers (“ISPs”) provide Internet access with one or a limited number of IP addresses. Internet bandwidth can be utilized via Wi-Fi access points. User A operates iPod touch to search for and access a Wi-Fi service in order to access a web page on the Internet. User B operates the laptop computer to find the same Wi-Fi service to access different web pages on the Internet. Devices operated by user A and user B share one and the same public IP address provided by the ISP. In this example, it is impossible to determine which user (user A or user B) has accessed which Internet web page because both users share the same public IP address. .

  In the above example, two users operate different computing devices and access two different web pages simultaneously. Unfortunately, the ISP can only detect one IP address shared by both accessing users. Therefore, individual users cannot be identified.

  Apparatus, computer readable medium and system for providing a virtual tunnel on the Internet for user communication using a user device such as a handheld wireless device or a smart phone or other wireless or wired device and clearly identifying the user , Methods, and means for performing the methods are disclosed.

  Systems and methods are provided for identifying individual users accessing a communications network via Wi-Fi or other band sharing, even when both users share the band simultaneously. Systems and methods in accordance with the teachings herein further use individual bandwidths provided by Wi-Fi services, including bandwidth provided by one or a limited number of shared public IP addresses. Provide user identification and disclosure.

  The method according to the present disclosure includes a user sending a request for authentication by the user's device, a remote web server authenticating the user's credentials, and a random one for authorizing the user if successful. Sending an HTTP redirect request to the user's browser on the user device, including sending a time password hash. The user's browser then sends an authorization request containing a password or password hash to the configured router's captive portal via HTTP, and the configured router communicates with the user's device on the user premises. Authorization establishes an L2TP tunnel to the primary system layer 2 tunneling protocol network server (LNS) in the Internet service provider data center, and the configured router permits PPP to the LNS via the established L2TP tunnel Send a request, the request contains a password, the LNS sends a grant RADIUS request to a remote centralized data center remote from the ISP data center premises, the remote data center approves the grant, and the LNS router With accepting the PPP tunnel, it assigns a private IP address to the PPP session for the user.

  Thus, Internet access for authenticating a user proceeds by the user sending a request over the Internet through a configured router on the user's premises, and the request is encapsulated within an established PPP tunnel. At this point, the LNS translates the private IP address and port to a public IP address using, for example, port address translation (PAT). The PAT log can be stored on a different server or the same server, eg, a public server, the LNS forwards Internet requests, receives replies, reverses IP translation, and the LNS A response is returned to the configured router via the tunnel, which allows the reply to be forwarded to the user's device.

  The present application includes a network tunneling platform that provides user identification over a communications network even when the user or the user's computing device is behind one or more NAT (Network Address Translation) services The router is configured to The registered user identification information is received and stored in one or more databases. Thus, network users are subscribers and can therefore be clearly identified. For example, a user is authenticated by presenting a username and password, and is allowed to share other users' network bandwidth at no additional charge or for a small fee, depending on the user's authentication status May be. The teachings herein provide for associating a user's connection IP address and TCP / UDP port with the user's authentication information (eg, username and password) to identify the user.

  The user identification function provided by the teachings herein provides compliance with the security policies and legal requirements of even the most stringent Internet service providers.

  The user identification information is presented at least in part by the PPP session via a Layer 2 Tunneling Protocol (“L2TP”) tunnel. Each user session is established via an L2TP tunnel, thereby providing an independent Internet Protocol (“IP”) address for each PPP tunnel and thus for each user. For example, user credentials and individual session IP addresses are logged by a remote authentication dial-in user service (“RADIUS: Remote Authentication Dial In User Service”) server that may also support an authentication and accounting process.

  The tunneling solution according to the teachings herein further provides an environment where limited IP addresses can be used. By assigning each user a private IP address, public IP address savings can be provided. In this embodiment, individual private IP addresses are translated into one or more public IP addresses, for example by one or more network address translation (“NAT”) servers, before network traffic reaches the Internet. In one embodiment, multiple private IP addresses are network address translated with a single public IP address (also called PAT or NAT overload). Providing a NAT accounting log provides a clear user identification.

  Although many of the examples herein relate to IP savings, in embodiments that do not provide or support NAT translation to support a limited or reduced number of IP addresses, private IP addresses are translated by NAT. Instead of sharing one or more public IP addresses, it can instead be simpler and cheaper by simply assigning independent public IP addresses to users connected at any given time.

  Also, the infrastructure in one embodiment substantially provides availability depending on, for example, the redundancy of the data center and communication provider. Further, for example, by adding a network device that terminates a tunnel with a configured router, scalability to support, for example, hundreds to thousands of concurrent users is substantially supported. If the number of concurrent users is smaller, the system and platform costs can be adjusted to scale appropriately with respect to functionality and cost.

  In one embodiment, a configured router in accordance with the teachings herein sends a RADIUS request to the system's RADIUS proxy server from which, for example, a whitelisted domain, a welcome page uniform resource locator (“URL”). ), Configuration profile information including details of the L2TP server (“LNS”) and the like are acquired. The system's RADIUS proxy sends the configuration profile to the configured router. When a user sends a Hypertext Transfer Protocol (“HTTP”) request to a domain that the user is authorized or authorized to access (“white-listed” domain), the configured router forwards the request to the user. This translates the traffic with the router's public IP address by NAT and forwards it to the Internet. An HTTP response is sent to the user's browser.

  If the user attempts to access a domain that is not whitelisted, the configured router's captive portal intercepts the request and goes to the user's browser, eg, to a hypertext markup language (“HTML”) welcome page. Send an HTTP redirect. The user's browser requests a welcome page, and a secure (“HTTPS”) welcome page is provided to the user. In one embodiment, the user enters his credentials (eg, username and password) on the welcome page. One or more web servers perform the authentication process by accessing user credentials in the system database. If the authentication is successful, the web server sends an HTTP redirect request including a random one-time password hash used in the authorization phase to the user's web browser software application. The user's browser sends an authorization request via HTTP to the configured router's captive portal, which contains the one-time password.

  Once authenticated, the configured router establishes an L2TP tunnel to its primary system LNS, for example, if the tunnel has not yet been established by a previous connection. If the connection to the primary LNS fails, the configured router preferably attempts to connect to the secondary LNS. The configured router sends a PPP authorization request to the LNS over the L2TP tunnel, which can include a one-time password. In response, the LNS sends an authorization RADIUS request to, for example, a system RADIUS proxy at the ISP. In one embodiment, the ISP is affiliated with the provider or owner of the system and method according to the teachings herein.

  Continuing with this embodiment, the ISP's RADIUS proxy provides an authorization request via an encrypted virtual private network (“VPN”) established between the DCR routers to the system and method provider according to the teachings herein. Or forward to a RADIUS server provided or managed by the owner, which may be anywhere in the world. If authorization is successful, the RADIUS proxy provided by the system returns an access-accept to the ISP's RADIUS proxy via the encrypted VPN. The ISP's RADIUS proxy then forwards the access grant packet to the LNS, thereby accepting the PPP tunnel and assigning a private IP address to the PPP session.

  In one embodiment, captive portal authentication is supported. For example, the configured router transmits a RADIUS permission request including the one-time password to the ISP's RADIUS proxy. The RADIUS request is forwarded to a RADIUS proxy server provided or managed by the provider or owner of the system and method according to the teachings herein. The credentials are preferably the same as those used to authorize the PPP tunnel above, so the request is expected to be accepted. The access grant packet (s) is sent to the system RADIUS proxy, which may be anywhere in the world, and then transmitted to the configured router. The access grant packet preferably includes the user's network profile. The configured router then provides Internet access to individual users, including the private IP address assigned to the PPP session by the LNS and the user's device with a dynamic host control protocol (“DHCP”) by the configured router. Static network address translation ("NAT") between private IP addresses assigned to

  Once the user is authenticated, the user sends a request to the Internet through the configured router. The request is encapsulated within the PPP tunnel described above. The LNS performs port address translation (“PAT”) on the request to translate the private IP address and port number in the request into a public IP address (which may be a different port). Thereafter, the PAT log is stored in the public server. Requests are forwarded over the Internet to individual servers, such as HTTP servers, from which responses are sent over the Internet towards another PAT process. The IP (and port) is effectively reversed and the LNS transmits the response to the configured router via the PPP tunnel. The configured router forwards the response to the user's software application.

  Thus, and as described in connection with the exemplary embodiment above, the teachings herein provide a user connection flow that includes whitelisted domains and whitelisted. Domain authentication and user authentication and authorization, including web server authentication, tunnel authorization, and captive portal authentication.

  In one embodiment, an integration of at least three session accounting is included. One is PPP session accounting by one or more RADIUS servers managed or maintained by the owner of the teachings herein. The second is captive portal session accounting, also generated by the system's RADIUS server (s). The third is NAT accounting provided by the LNS router. PPP session accounting may include at least the user's session start time, stop time, and the IP address of the individual LNS at which the PPP session ended. Also, the CPE (customer premises equipment) translates (NAT) the wide-area network (“WAN”) IP address of the configured router, so that PPP session accounting is also the IP source of the CPE that is the tunnel IP source An IP address can be included. Other information included in PPP session accounting includes the private IP address assigned to the router configured by the LNS for the PPP session, the user's username, the type of accounting packet, and the FON-specific session identifier (identical to that of the captive portal session). ).

  In one embodiment, the captive portal manages user authorization and accounting at the configured router. Captive portal session accounting preferably includes user session start time, session stop time, user username, user device type (such as a smartphone) and media access control (“MAC”) address, user CPE MAC address , Including one or more of the IP address of the user's computer device (smartphone or the like) assigned by DHCP by the configured router, and the unique session identifier (same as that associated with the PPP session as described above).

  The NAT translation session accounting is generated by the LNS router, and includes the translation creation time, translation deletion time, accounting type (for example, NAT creation or NAT deletion), layer 4 communication protocol (UDP or TCP), PPP session IP address. (Internal address) and port, LNS public IP address and port used for translation, and Internet IP address and port aimed by the user.

  Thus, individual session accounting provides user tracking and identification. For example, the user's public IP address, TCP or UDP port, and time frame are known in advance. The teachings herein use that information to identify the private IP address assigned to the PPP session, which is for a single PPP session if the time frame is appropriate (ie, 24 Given a time frame of time, there may be several PPP sessions sharing the same private IP address at different times). Further, the PPP session IP address can be used to specify the PPP session accounting for the IP address, and the user name and CPE address of the user can be specified.

  Also, if additional information (ie, the MAC address of the user device) is needed, a unique session ID can be obtained and a captive portal user session with the same unique session ID can be identified. Therefore, the MAC address of the user device and the MAC address of the configured router can be specified.

  Furthermore, the teachings herein provide a “Live Platform” with a modular design to facilitate ensuring scalability and redundancy. In one embodiment, the LNS subplatform terminates an L2TP PPP tunnel that originates from a configured router. The LNS sub-platform also assigns a private IP address to the user's session, translates the private IP address to a public IP address, generates NAT accounting and forwards it to an external Syslog, and uses the RADIUS protocol The user's session can be authenticated and session accounting can be generated using the RADIUS protocol.

  Information technology ("IT") that includes one or more configured routers / firewalls that may provide an encrypted tunnel (Gre / IPSec) with the platform of the system for secure RADIUS authentication and other transactions ) Service sub-platforms can also be provided. The IT service platform can also implement one or more firewall functions to protect servers installed in the data center. The IT service platform may further include a RADIUS proxy server, which, in one embodiment, centralizes RADIUS authentication and accounting and provides information about it to the system and method provider according to the teachings herein. Or forward to a system RADIUS proxy maintained or managed by the owner, which may be anywhere in the world. In addition, a monitoring server can be included, which checks the health status of network devices and server devices and maintains or manages that information by the provider or owner of the systems and methods according to the teachings herein. Can be configured to transfer to a centralized monitoring platform. In addition, a public server can be included, which stores information necessary for public actions (RADIUS logs, NAT accounting, etc.) and provides a secure web interface for data extraction.

  In addition to the LNS sub-platform, the platforms described herein are configured to aggregate traffic from the LNS and IT services sub-platforms by border switches and provide IP connectivity with the ISP aggregation platform. And further configured to provide inter-data center connectivity for redundancy.

  This application is further described and explained with reference to the appended Appendix A and Appendix B, the entire contents of which are hereby incorporated by reference. In Appendix B, for example, PPP and L2TP are replaced with PPPoE technology. Furthermore, the combination of the second router device (eg, “Fonera” device) and “CPE” has been replaced with a single customer device (eg, “CPE” device) provided by the ISP. This embodiment is more efficient and less costly because, for example, equipment is reduced.

  In accordance with the teachings herein, systems and methods are provided for identifying individual users accessing a communications network via Wi-Fi or other shared bandwidth. Individual users of Wi-Fi service via shared public IP address (s) can be identified and disclosed to administrative authorities, for example.

  Other features and advantages of the present invention will become apparent from the following description of the invention which refers to the accompanying drawings.

2 is an example of a user connection flow diagram and an overview of the main structure of a system according to one aspect of the present disclosure. FIG. 2 is an example of a user connection flow diagram and an overview of the main structure of a system according to one aspect of the present disclosure. FIG.

3 is an example of a layer 2 tunneling protocol according to an aspect of the present disclosure.

FIG. 3 is an example of a layer 2 tunneling protocol tunnel and PPP session diagram according to an aspect of the present disclosure.

3 is an example of a live platform map representing an IP connection and a system module in a data center according to an aspect of the present disclosure.

2 is an example of a layer 2 live platform map showing link connections between a system platform and an ISP data center according to one aspect of the present disclosure. 2 is an example of a layer 2 live platform map showing link connections between a system platform and an ISP data center according to one aspect of the present disclosure.

FIG. 4 illustrates an example structure of a data center module of a system according to one aspect of the present disclosure. FIG. FIG. 4 illustrates an example structure of a data center module of a system according to one aspect of the present disclosure. FIG.

Fig. 4 illustrates an example of equipment placement in a rack in two data centers according to one aspect of the present disclosure. Fig. 4 illustrates an example of equipment placement in a rack in two data centers according to one aspect of the present disclosure.

FIG. 6 illustrates an example of an IP connection for an out-of-band monitoring network in an ISP data center and a centralized data center according to one aspect of the present disclosure. FIG. 6 illustrates an example of an IP connection for an out-of-band monitoring network in an ISP data center and a centralized data center according to one aspect of the present disclosure.

FIG. 4 is an example of a layer 2 OBSN platform map representing an example of link connections in an ISP out-of-band monitoring network platform and interconnection with the ISP platform according to one aspect of the present disclosure. FIG. 4 is an example of a layer 2 OBSN platform map representing an example of link connections in an ISP out-of-band monitoring network platform and interconnection with the ISP platform according to one aspect of the present disclosure.

6 is a flowchart illustrating an example of a process flow according to an aspect of the present disclosure. 6 is a flowchart illustrating an example of a process flow according to an aspect of the present disclosure. 6 is a flowchart illustrating an example of a process flow according to an aspect of the present disclosure.

FIG. 6 is a schematic diagram of an example of EAP in a tunneling approach according to one aspect of the present disclosure.

FIG. 6 is a schematic diagram of another example of EAP in a tunneling approach including on-demand tunneling, according to one aspect of the present disclosure.

FIG. 6 is a schematic diagram of an example of a tunneling technique when a server is configured with three elements, according to one aspect of the present disclosure.

FIG. 2 is an example of a supplicant / authenticator / server model using supplicant-to-authenticator EAP messaging and EAPOL communication.

FIG. 3 is a schematic diagram of an example of tunneling when a server has two elements and uses UAM for transferring PAP messages according to one aspect of the present disclosure.

FIG. 3 is a schematic diagram of an example of EAP without tunneling in a server having two elements according to one aspect of the present disclosure.

FIG. 6 is a schematic diagram of a user management chart according to an aspect of the present disclosure.

1 is a diagram illustrating an example of a system using a technique of PPPoE technology according to an aspect of the present disclosure. FIG.

  For an example of a user connection flow diagram for tunnel authorization, user identification, and access through a Layer 2 Tunneling Protocol Network Server (LNS), see FIGS. 1-1, 1-2 and FIGS. 10A-10C. This will be described below. A configured router 22, such as a wireless router, can be placed at the user's home or office to provide access to the user's device, such as a smartphone, laptop, desktop, or other type of handheld device 21. Although described herein as a wireless router 22, it will be appreciated that a wired connection may be provided. Multiple such user devices 21 can also share the same connection to the Internet via the wireless router 22. Similarly, as an ISP router CPE (customer premises equipment) that can also be provided in the user premises 20, connections via the ISP router 24 shown in FIGS. 1-1 and 1-2 can be shared by a plurality of devices. .

  The user tries to connect to the Internet via the wireless router 22 as shown by a communication arrow 1 in FIG. The configured router 22 sends a RADIUS request to a RADIUS proxy server of the system that can be arranged in an ISP (Internet Service Provider). Although described herein as a RADIUS proxy, it will be appreciated that other types of user authentication may be provided, and other types of servers may perform this function. Transmission of this profile request by the router is shown in FIG. 10A at step S1. In response to this, the system RADIUS proxy 35 of the ISP transmits the configuration profile to the set router 22 as shown in step 2 of FIG. 10A and further as indicated by the communication arrow 2 in FIG.

  According to one aspect of the present disclosure, the user is then free to send an HTTP request to the whitelisted domain, and the configured router 22 transmits such request to the ISP router 24. This will NAT the request with its own public IP address and forward it to the Internet. During profile configuration in step 2, the ISP's server will allow the list of whitelisted domains that can be accepted without further security measures, the URL of the welcome page, details of the layer 2 tunneling protocol network server 31, etc. Information is transmitted to the router 22 which has been set. Thus, according to this aspect of the invention, a request from a configured router 22 to a whitelisted domain is answered as shown by communication arrow 4 in FIG.

  On the other hand, when the configured router 22 sends an HTTP request to a domain that is not whitelisted, as shown by the communication arrow 5, this request from the browser of the user using the captive portal service is sent to the configured router. The captive portal intercepts and sends an HTTP redirect to the welcome page to the user's browser as indicated by communication arrow 6. 1-1, the user's browser requests a welcome page, as shown by communication arrow 7, and the HTTPS welcome page is displayed to the user, as shown by communication arrow 8. FIG.

  At this point, the user enters his credentials, such as a username and password issued by the user's ISP, or other provided to the user, on the welcome page, as indicated by communication arrow 9. It is possible. The welcome page can be sent by a web server 41 located at a different location than the ISP data center 30, for example, the web server 41 supports user identification and tunneling as described herein. It can be arranged in a centralized data center 40 that provides services for this purpose. It may be located anywhere in the world, or in addition, and / or other equipment shown in FIGS. 1-2 as part of the data center 40, may be located on the ISP premises. 1-1 and 1-2, the web server 41, the user database 43, the proxy RADIUS 45, and the VCR 40 are illustrated as being disposed in the centralized data center 40. The user's welcome page is shown as being transmitted from the web server 41 located at the central location 40 in FIGS. 1-1 and 1-2.

  The user can enter his credentials as described above using the user equipment 21 on the user premises 20 and these credentials can be transferred to the web server 41 and thereby , The credential information is processed to authenticate the user by accessing a database, such as the user database 43, as indicated by the communication arrow 10 and further in step 3 of FIG. 10A. In response to this, when the authentication is successful, the web server 41 transmits the password or the one-time password hash as shown in FIG. 10A and further as shown by the communication arrow 11 in FIG. Authenticate. The web server 41 redirects the HTTP request to the user's browser 21. At this point, the user's browser sends an authorization request over HTTP (or using another protocol) to the configured router's captive portal, as indicated by communication arrow 12, and the request is sent from web server 41. Contains the received one-time password. The captive portal of the configured router receives the permission request including the one-time password received from the web server 41 as shown in step S5 of FIG. 10A.

  As shown in step 6 of FIG. 10A, the configured router 22 establishes an L2TP tunnel with the LNS 31 of the ISP data center if it has not been established by a previous connection. This communication is indicated by a communication arrow 13 in FIG. If the connection to the primary LNS fails, the configured router 22 tries to connect to the secondary LNS. The configured router 22 sends a PPP (point-to-point protocol) session permission request through the established L2TP tunnel, as indicated by S7 in FIG. 10A and further by the communication arrow 14 in FIG. Send to LNS. This permission request includes the one-time password received from the user device.

  The LNS 31 then attempts to send an authorization RADIUS request to the system RADIUS proxy 35 that can be located at the ISP data center 30. This is shown as a communication arrow 15 in FIG. 1-2, and further shown in step S8 of FIG. 10A. In response, the system RADIUS proxy 35 sends the request to the central database 40 system via an encrypted VPM (Virtual Private Network) established between the ISP data center 30 and the DC router in the central data center 40. Transfer to RADIUS. This is shown in step 9 of FIG. 10A and further as communication arrow 16 in FIG. 1-2. At this point, as shown in step S10 of FIG. 10A, based on the password received in the request, it is determined whether to permit or not, and if an affirmative determination is made, communication arrows 17 and 18 in FIG. Further, as shown in S 11 of FIG. 10A, the system RADIUS proxy 45 of the centralized data center 40 notifies this access permission (access-accept) to the RADIUS proxy of the ISP, and this is transferred to the LNS 31. In response to the access permission message received from the RADIUS proxy 35, the LNS 31 accepts the PPP tunnel as shown by the communication arrow 19 in FIG. 1-1 and further in step S13 of FIG. Assign a private IP address to the session.

  Here, the captive portal authentication will be described with reference to the communication arrows 20 to 24 shown in FIGS. 1-1 and 1-2. As shown by the communication arrow 20 in FIG. A request for a RADIUS permission request is sent to the RADIUS proxy 35 of the ISP data center 30, and the request includes the previously received one-time password. This is shown as S14 in FIG. 10B. In response, the RADIUS proxy 35 forwards the RADIUS request to the system RADIUS proxy 45 in the central data center. This request is always accepted because the transmitted credentials including the password are the same as the PPP authorization credentials. As shown by arrow communication 22 in FIG. 1-2, an access permission packet is returned from proxy RADIUS 45 to ISP proxy RADIUS 35, and includes the user's network profile as shown by communication arrow 23 in FIG. Access permission is sent to the configured router 22. These steps are shown as steps S16 to S18 in FIG. 10B. At this point, as indicated by communication arrow 24 in FIG. 1-1, the configured router 22 configures Internet access for the user device 21, which is assigned to the PPP session of the user device 21 by the LNS 31. Providing static NAT between the assigned private IP address and the private IP address assigned by the configured router 22 to the user device 21 via DHCP.

  Authenticated users are provided access to the Internet as described below. The user sends a request to access a target on the Internet through the configured router 22 as indicated by communication arrow 25 in FIG. 1-1 and step 19 in FIG. 10B. The request can be encapsulated within an established PPP tunnel, as indicated by communication arrow 26 in FIG. 1-1 and as shown in step 20 of FIG. 10B. In response to this, the LNS 31 performs PAT (port address conversion) on the Internet request from the user, as indicated by the communication arrow 27 in FIG. , Translate the private IP address and port of the request into a public IP address (which may be on a different port than the private IP address). In this connection, the PAT log is stored in the ISP public server 33 as indicated by the communication arrow 28 in FIG. 1-2 and further in step S22 of FIG. 10B. The request is forwarded to the Internet by the LNS 31 as indicated by the communication arrow 29 in FIG. 1-2 and further as shown in step S23 of FIG. 10B.

  LNS 31 receives a response from the Internet that has responded to the Internet request, as indicated by communication arrow 30 and further in steps S24 and S25 of FIG. 10B, and LNS 31 subsequently performs a PAT process. In this way, the IP conversion is reversely converted, whereby the LNS obtains the private IP address of the user device 21 again. As indicated by the communication arrow 32 in FIG. 1-1 and S40 in FIG. 10C, the LNS 31 transmits a response to the Internet request to the configured router 22 via the PPP tunnel. Next, the configured router 22 transfers the response to the user device 21.

Live platform:
Further contemplated is a live communications platform with a modular design to facilitate ensuring system scalability and to provide a redundancy solution. The live platform can include an LNS subplatform that terminates the L2TP / PPP tunnel starting from the configured router 22. A layer 3 live platform map is shown in FIG. FIG. 4 represents the IP connections in the system cabinet at the ISP data center and the central data center.

  5A and 5B show the layer 2 live platform map. FIGS. 5-1 and 5-2 illustrate link connections between system devices in an ISP data center and other ISP data centers and a central data center that supports identification and secure tunneling services. FIGS. 6A and 6B are layer 2 live network maps showing a relationship between devices in the data center 1 and the data center 2 connected via the ISP data network.

  As described above, the LNS sub-platform can provide functions such as terminating an L2TP / PPP tunnel starting from the configured router 22, and in addition, the LNS sub-platform can provide a private address for the user's session. Assigning, converting its private IP address to a public IP address, generating NAT accounting, forwarding such NAT results to an external system log, eg authenticating a user's session using the RADIUS protocol In addition, session accounting can be generated using the RADIUS protocol.

  At the same time, the IT services subplatform can provide a router / firewall to provide an encrypted tunnel (Gre / IPSec) with a central data center for secure RADIUS authentication and other transactions. A firewall function for protecting servers installed in the data center can be realized. The IT service sub-platform can further provide a RADIUS proxy server that centralizes RADIUS authentication and accounting and forwards the results to the central data center system RADIUS proxy. In addition, the IT service sub-platform can function as a monitoring server to check the health status of network devices and server devices, and can transfer that information to the centralized monitoring platform of the centralized data center. . Furthermore, it can function as a public server for storing information required for public actions including RADIUS logs, NAT accounting, and the like. It can also provide a secure web interface for data extraction. Finally, border switches can aggregate traffic from LNS and IT service sub-platforms, provide IP connectivity with ISP data centers and the platform as a whole ISP, and provide additional redundancy Inter-data center connections can be provided.

  Live platform scalability can be provided as follows: The LNS subplatform may comprise several LNS routers, which distribute the tunnel sessions and NAT services among all those LNS routers. In this way, network traffic congestion and single point of failure of the network can be avoided, in which case scaling by adding LNS routers is possible. IT services can be provided by server farms such as HP's DL 380 for multiple purposes, including monitoring, RADIUS proxy, and public services, and can be extended by adding more servers. The IT service router can include a modular router (eg, Cisco 3945) that can be upgraded with additional hardware or add a secondary router. The boundary switch can include, for example, a core switch such as a Cisco 3750E using StackWise Plus technology that can aggregate up to nine switches in a 64 GB backbone. Each LNS is independent of the others, and can be distributed over two or more geographically separated data centers as shown in FIGS. 1-1 and 1-2. Redundancy can be provided. The configured router 22 can dynamically configure not only the primary LNS 31 of the ISP but also the secondary LNS of the second data center. Thus, if one or more LNS servers fail, the user is reconnected to the secondary LNS or tertiary LNS.

  Redundancy is also provided by LNS failover, which allows the LNS platform to ensure that services are secured even in the maximum usage scenario when multiple LNS failures occur. It can be a scale that has spare capacity. By duplicating IT service routers and servers in the data center, all LNS routers can reach both IT service platforms either locally or via an inter-data center link, for example RADIUS proxy. If a failure occurs, the LNS router can connect to the secondary RADIUS proxy. Similarly, the boundary switch is configured in a cluster in each data center, so that if a master switch fails in one data center, one or more slave switches in the same data center without interrupting service Becomes the master. Thus, all LNS routers and IP service routers are redundantly connected to the master switch and the slave switch.

  Typically, as shown in FIGS. 1-1 and 1-2, the two data centers need to be geographically redundant and separated from each other. However, it will be appreciated that a single data center, or more than one data center located nearby, may be sufficient to implement and implement the invention described herein. Typically, a switched PDU has a rack power bar that can perform remote power on / off, eg, a network operations center is supported to handle possible problems, eg, system May need to report a power outage and may require appropriate action. Responsible for emergency physical actions, such as in the event of a power outage or when wires are not properly connected to one or more structures or devices or equipment described herein An engineer who can do it must be prepared. In general, live network communication may require an Internet link of 2 × 10 Gbps (total of 4 × 10 Gbps) for user traffic in each data center. Typically, an interface type such as LR or SR can be provided, and each link can be connected to a separate router for redundancy.

  Network out-of-band monitoring can be provided as 1x high-speed Internet links (2x100 Mbps) for remote management, these links differ from others for live network connections due to redundancy Can be connected to a router. The Internet-data center / private network can include a 1 × high-speed Ethernet (registered trademark, the same applies hereinafter) / private link between both racks arranged in each data center. This can be thought of as a critical link, and thus various protections can be implemented for multiple paths (also for redundancy). If various protections are not feasible, the second link can be realized.

  Out-of-Band Supervision for Network (OBSN) is a secure and reliable remote management that includes an IPSec tunnel established from an OBSN router in a central data center to a system OBSN router in an ISP data center. Functions can be included. The connection from the central data center data center to the ISP data center equipment can be fully encrypted and the OBSN traffic is separated from the user traffic, for example using virtual routing forwarding (VRF). Access to each device can be secured remotely by SSH or by console, so that even if there is a connection problem or remote access is required to perform the boot sequence, It is guaranteed that the device is usable and reachable.

  The OBSN network is located in a DCR router having a 24-port high speed Ethernet card with a VLAN configuration function. Each device (router, server, PDU, etc.) is connected to this network for remote management.

  Regardless of whether the device has VRF (virtual routing forwarding) capability, it must be configured to ensure isolation of the OBSN from other networks. If the device does not have this capability, it is either connected only to the OBSN network or configured with the strictest security level to prevent the OBSN from being compromised.

  The OSR router can reach the DCR's local OBSN VLAN, can reach the OBSN VLAN of other data centers via border switches, and can reach the Madrid platform via the IPSec / Gre tunnel. .

  The DCR router has a directly connected OBSN VLAN and can provide a route to reach the OBSN VLAN of another data center through a border switch. The default route can be a local OSR.

  The border switch may have a route to reach the DCR's local OBSN VLAN, a route to the other data center's OBSN VLAN via a point-to-point link, and a default route to the local OSR.

  The configured router firmware can be modified to connect to this platform to ensure that the L2TP over PPP tunnel does not pass filtering by a different ISP in the country where the ISP is installed.

  An OpenNMS platform can be deployed to monitor network devices using the SNMP protocol.

  Zabbix platform can be deployed to monitor servers and services (such as RADIUS proxies) using local agents.

  The primary monitoring platform is operating normally at the partner partner's data center, the communication between the system platforms is operating normally at the partner partner's data center and Madrid, and an alert is sent to the system administrator's Blackberry device via email / In order to verify that it is escalated with SMS, the secondary monitoring platform can be configured into a centralized data center platform.

  The remote monitoring platform may use the OBSN to reach the partner partner data center system equipment.

  Mobile client applications can be provided on iOS and Android devices, as well as on other types of phones, handheld devices and portable devices. An Apache web server running on Linux can be used. However, it will be appreciated that other systems may be used.

  The methods, functions, systems, computer readable media products, etc. may be implemented using hardware, software, firmware, or combinations thereof, and may require one or more human operations so that no human manipulation may be required. It can be implemented in a computer system or other processing system. In other words, the present method and function can be carried out fully automatically by the operation of the machine, but not all need to be carried out by the machine. Similarly, the system and computer readable media may be fully automated depending on the operation of the machine, but this is not necessarily so. A computer system can include one or more processors in one or more units for implementing a system according to the present disclosure, the computers or processors can be located in the cloud, or Can be provided in the local enterprise settings of third party contractors or off-premises. Similarly, the stored information can be stored in the cloud or stored locally or remotely. A computer system or system for interacting with a user can include a GUI (graphical user interface) or can include graphics, text, and other types of information, via a desktop, laptop computer Or through other types of processors, including handheld devices, telephones, cell phones, smartphones, or other types of electronic communication devices and systems. A computer system for implementing the methods, functions, systems, and computer-readable storage media described above can include a memory, preferably a random access memory, and can include a secondary memory. Thus, even though illustrated as a system database, the database can be part of the same machine or located off-site, and can be a floppy disk drive, magnetic tape drive, optical disk drive. , A removable storage drive, a combination thereof, or any type of recording medium. Examples of memory or computer readable storage media products include erasable programmable ROM (EPROM), removable memory chips such as programmable ROM (PROM), removable storage units, and the like.

  The communication interface can include a wired or wireless interface that communicates via a TCP / IP paradigm or other type of protocol, and can also be a wire, cable, fiber optic, telephone line, cellular link, Wi-Fi or Bluetooth®. ), LAN, WAN, VPN, World Wide Web, or other such communication channels and networks, or combinations thereof.

  According to one aspect of the present disclosure, public IP addresses are saved so as to reduce the number of public IP addresses required for the system. Therefore, when there is no incoming communication from the Internet to the user device 21, and there is no direct communication between users of the ISP, an IP saving solution can be provided. In this way, distributed NAT by each LNS 31 can be implemented. This allows all user traffic to go through NAT (eg, within the 7200 Cisco router) and NAT accounting is generated by the NAT router, which can improve performance. Since NATs are distributed and each LNS is completely independent of the other LNS, there can be practically no scalability limit. Also, since the system relies on existing network equipment, no additional points of failure are introduced, and reliability can be improved.

  An example of an IP addressing technique for a live platform or other communication scenario is described below. A PPP session can be assigned a private IP address in the range 10.128.0.0/9. Each LNS can be assigned a private / 18 pool for the user's PPP tunnel. Each LNS has a public / 26 pool to NAT translate PPP sessions. Public IP addresses are also required for platform configuration. Thus, each data center will probably need a public / 22 network in total for the NAT pool, platform configuration, and future service expansion. IP addressing for the OBSN platform can be implemented, for example, by setting a private IP address in the OBSN platform to achieve enhanced security and IP saving. According to this implementation method, the only public IP address in the OBSN platform can be set in the OSR router connected to the Internet via the ISP data center. In this way, the public IP address can be saved to some extent.

  In a distributed model, if a tunnel and NAT solution is provided by an LNS router, a fairly scalable solution can be provided. In each data center, two border switches can be included to aggregate at least 14 LNS routers. Each LNS router can support, for example, 10,000 user sessions, each having 1.8 Gbps throughput and 2 Gbps memory RAM, so that the throughput of each user by peak simultaneous use is 100 Kbps, On average, 100 NAT conversions can be made. Depending on the service performance, an additional device may be required for NAT log storage.

  According to one embodiment, three actors are used: a supplicant, an authenticator, and a server, and tunneling may or may not be employed. FIG. 14 shows a supplicant, an authenticator, and an authentication server. In one embodiment, for example, an EAP (“Extended Authentication Protocol”) message is forwarded from EAPOL to PPP and then forwarded to RADIUS. In an alternative embodiment, an “on-demand” tunneling architecture is employed, which eliminates the step of converting EAPOL to PPP and may be easier to implement for the manufacturer. In alternative embodiments, proxy RADIUS (which can be modified to trigger PPP authentication) is employed, or an improved EAP daemon can be applied. Each of these two embodiments will be described in more detail below in connection with FIGS.

  In one embodiment, the application employs an extended authentication protocol (“EAP”), which is an authentication framework commonly used in wireless networks and point-to-point connections. EAP is widely used in, for example, IEEE 802.11 (Wi-Fi), and IEEE 802.1x having a plurality of EAP types is adopted as an authentication mechanism in the WPA and WPA2 standards. When used as an authentication protocol, EAP can be used in captive portals and is suitable for use in WPA and / or WPA2. For example, LEAP (Lightweight EAP), EAP-TLS, EAP-TTLS, EAP-FAST, EAP-SIM, EAP-AKA can be applied in connection with one or more credentials and / or processes. In one embodiment, 802.1x involves a supplicant (eg, a mobile computing device such as a smartphone, a PDA), an authenticator (eg, a configured router), and a server. 802.1x is used to transfer EAP messages from the supplicant to the authenticator by EAP over LAN ("EAPOL"), and then from the authenticator to the server by RADIUS / DIAMETER.

  In such an embodiment, a universal access scheme (“UAM”) is used to transfer password authentication protocol (“PAP”) messages. Subsequently, HTTPS can be used to transfer data from the supplicant to the UAM server, HTTP is used from the supplicant to the authenticator, and RADIUS is used from the authenticator to the server.

  11-13 illustrate an embodiment according to one aspect of the present disclosure by way of example. As described above, EAP can be used to transmit qualification information, such as in the case of user authentication. However, in a known system, EAP cannot be used to transmit qualification information from a mobile computer device such as a smartphone to an authentication server such as the RADIUS server 110.

  Although described herein with respect to specific types of equipment, specific bandwidth requirements, specific network solutions and protocols, it will be appreciated that other types of equipment, bandwidth limitations, protocol approaches are also contemplated, Even so, it will work well enough to implement and implement the invention described herein.

  In one embodiment, the data is encapsulated in one form and transmitted from one device, such as a smart phone computing device 104, and then transmitted to another device, thereby releasing the EAP capsule, The authentication information is encapsulated using another protocol, for example PPP, and transmitted to another device, for example RADIUS server 110. When the RADIUS server 110 receives the PPP encapsulated credentials, the RADIUS server 110 authenticates the user with the authentication credentials (or the credentials are incorrect or not authenticated for other reasons). The RADIUS server 110 transmits a reply by PPP. The PPP reply is received, opened and encapsulated again in EAP before being sent back to the computing device 104.

  FIG. 11 shows an exemplary hardware configuration 1100 and data transmission and respective communication protocols used therein. As shown in FIG. 11, authentication occurs in one phase. A user using the handset 104 attempts to associate using 802.1x (EAPOL) and transmits an EAP message encapsulated in this protocol (step S1102). The configured router 302 converts the EAP message from EAPOL to PPP and sends them to the LNS (step S1104). The LNS server 108 converts the EAP message from the PPP capsule to the RADIUS capsule, and transfers them to the RADIUS server 110 (step S1106).

  In this case, as shown in FIG. 11, the configured router 302 receives the qualification information with the EAPOL capsule, releases the EAPOL capsule, encapsulates the qualification information into PPP, and transmits it to the LNS server 108. The LNS server 108 receives the PPP packet and transfers the EAP qualification information to the RADIUS server 110 using the RADIUS protocol. Successful authentication means that a PPP / L2TP tunnel has been established between the router 302 and the LNS server 108. The tunnel is dedicated to the user's handset 104, and all traffic to and from this device is routed through this tunnel until the session is stopped.

  FIG. 12 shows an exemplary hardware configuration 1200 and data transmission and respective communication protocols used therein. In the example shown in FIG. 12, tunnel establishment occurs in two phases. Phase 1 relates to user authentication. The user attempts to associate with a signal using 802.1x (EAPOL), and transmits an EAP message encapsulated in this protocol (step S1202). The configured router 302 converts the EAP messages from the EAPOL capsule, converts them into the RADIUS format, and sends them directly to the RADIUS server 110 (step S1204). In phase 2, if the user is authenticated by, for example, the RADIUS server 110, the RADIUS server 110 optionally returns a one-time password to the configured router 302, which uses the configured router to communicate with the LNS 108. L2TP / PPP tunnel is established, and then the user's traffic is routed using this tunnel (step S1206).

  In this case, with reference to FIG. 12, the user device 104 has user credentials (not shown) and initiates an association with the configured router 302 using the 802.1x (EAPOL) protocol. EAP is used to transmit a message that authenticates the user. The EAP message may vary depending on the type of EAP used (EAP-SIM, EAP-AKA, EAP-TTLS, or other suitable type). The configured router 302 receives EAP messages encapsulated in 802.1x (EAPOL) and encapsulates them into RADIUS packets, which are sent to the RADIUS server for user authentication. The RADIUS server 110 responds with a new EAP message to the LNS server 108 within the RADIUS encapsulation range (as is known in the art, this process is repeated until the credentials are considered valid. Times may occur). Along with the acceptance message, an (optional) one-time password can be sent to the configured router 302. When the RADIUS server 110 transmits a one-time password (which can be identified by parameters), the configured router 302 constructs an L2TP / PPP packet with the received one-time password, and a PPP session to the LNS server 108 (Eg, by an appropriate authentication protocol, such as PAP, CHAP, EAP) (step S1208).

  With continued reference to FIG. 12, after receiving an acceptance indication of the RADIUS server 110, or after PPP is established (depending on the circumstances), the configured router 302 sends an EAP message from the RADIUS server 110 to the client device 104. To allow and associate. The traffic is then forwarded to the Internet using the tunnel if it has been established.

  FIG. 13 shows an exemplary hardware configuration 1300 and data transmission and respective communication protocols used therein. The embodiment shown in FIG. 13 is a simplified diagram of the embodiment shown and described above with reference to FIG.

  FIG. 15 illustrates one embodiment of a supplicant, authenticator, and server, where the server has two elements and uses a universal access scheme to transfer PAP messages without requiring tunneling. Use. HTTPS can be used from the supplicant to the UAM server, HTTP can be used from the supplicant to the authenticator, and RADIUS can be used from the authenticator to the server.

  FIG. 16 shows EAP that uses UAM for PAP message transfer and does not use tunneling. HTTP is used from the supplicant to the authenticator, and RADIUS is used from the authenticator to the server. .

  FIG. 17 is a user management chart.

  FIG. 18 illustrates the use of PPPoE technology that can be used instead of PPP and L2TP. Furthermore, the combination of the second router device, which is, for example, a Foera device, and a CPE can be replaced with a single customer device, for example, a CPE device provided by an ISP. By using such a PPPoE technique, for example, the number of necessary devices is reduced, so that a more efficient and lower-cost solution can be provided.

While preferred embodiments of the invention have been illustrated and described, modifications and adaptations of the structures and steps described and other combinations or configurations are within the spirit and scope of the application and the claims. An example of this embodiment is shown as an item below.
[Item 1]
A system for identifying a user and providing a virtual tunnel on the Internet for user communication, the system comprising:
Comprising a tunneling server module configured to receive a user request for permission to communicate via a virtual tunnel via a virtual tunneling protocol and to send an authorization request to the authorization module based on the user request;
The permission module receives a permission request from the tunneling server module, and transmits a permission acceptance message for the user to the tunneling server module only when the permission determination based on the password included in the user request determines that the user is authenticated. Is composed of
The password is sent to the user by the remote server module, and the transmission indicating the authorization decision is from a server remote from the authorization module,
Received by the authorization module,
The tunneling server module communicates with the user via the virtual tunnel only after the tunneling server module receives the permission acceptance message for the user, receives the internet request from the user via the virtual tunnel, and is included in the internet request. Configured to forward Internet requests to the destination address
The tunneling server module is configured to receive a reply in response to an internet request over the internet and transmit the reply to a user.
system.
[Item 2]
The tunneling server module is further configured to assign a public IP address to the user's user session;
The reply is received by the tunneling server module as addressed to the assigned public IP address,
The tunneling server module was further configured to translate the public IP address to the user's private IP address before transmitting the reply to the user.
The system according to item 1.
[Item 3]
The system of item 1, wherein the virtual tunnel is a layer 2 tunneling protocol tunnel.
[Item 4]
The system of item 1, wherein a point-to-point data link protocol session is established for the virtual tunnel.
[Item 5]
The system according to item 1, wherein the tunneling server module is a layer 2 tunneling protocol network server and the authorization module is a proxy RADIUS server separate from the layer 2 tunneling protocol network server.
[Item 6]
The system of claim 1, wherein the tunneling server module is a layer 2 tunneling protocol network server, the authorization module is proxy RADIUS, and both proxy RADIUSs are located in an internet service provider's data center.
[Item 7]
7. The system of item 6, wherein a server remote from the authorization module is located in a centralized data center remote from the Internet service provider's data center.
[Item 8]
The system according to item 7, wherein the central data center and the data center of the Internet service provider communicate with each other via a dynamic context router.
[Item 9]
8. The system of item 7, further comprising a proxy RADIUS arranged in the central data center and configured to make a permission decision based on a password.
[Item 10]
The system according to item 7, wherein the remote server module is arranged in a central data center.
[Item 11]
The system according to item 2, wherein the tunneling server module assigns a public IP address to the user session by port address conversion and requests a private IP address and a port.
[Item 12]
The system according to item 1, wherein the system provides a live platform for real-time communication between a user and a remote destination via the Internet.
[Item 13]
A method for identifying a user and providing a virtual tunnel for user communication over the Internet, the method comprising:
Receiving a user request for permission to communicate through a virtual tunnel with a virtual tunneling protocol by a tunneling server;
Sending a permission request to the permission module by the tunneling server module based on the user request;
A permission request from the tunneling server module is foreseen by the permission module, and a request for permission determination based on the password received by the user from the remote user information server and included in the user request is sent to the remote permission server To do
Receiving a permission determination in response to the request for permission determination by the permission module and transmitting the response to the tunneling server module;
Only after the tunneling server module receives a permission acceptance message to the user, the tunneling server module performs communication with the user via the virtual tunnel;
Receiving an internet request from a user via a virtual tunnel by a tunneling server module and forwarding the internet request to a destination address included in the internet request;
Receiving a reply to the internet request in response to the internet request by the tunneling server module over the internet and transmitting the reply to the user;
Including methods.
[Item 14]
Further comprising assigning a public IP address to the communication session by the tunneling server module;
The reply is received by the tunneling server module as addressed to the assigned public IP address,
Converting a public IP address to a user's private IP address by a tunneling server module;
Further comprising transmitting a reply to the user.
14. The method according to item 13.
[Item 15]
14. The method of item 13, wherein the established virtual tunnel is a layer 2 tunneling protocol tunnel implemented as a point-to-point data link protocol session.
[Item 16]
15. A method according to item 14, wherein the translation by the tunneling server module comprises a port address translation of the request, wherein the private IP address and port are translated to a public IP address.
[Item 17]
14. The method of claim 13, wherein the user communication is a live communication platform with real time information.
[Item 18]
Item 18. The method according to Item 17, wherein the real-time communication is voice over IP communication.
[Item 19]
The tunneling server module is a server located in the internet service provider's data center, the authorization module is a RADIUS proxy server located in the internet service provider's data center, and the remote server is a tunneling server module and centralized identification. 14. The method according to item 13, which is located remotely from the authorization module in the data center of the support system.
[Item 20]
14. A method according to item 13, wherein point-to-point over Ethernet encapsulation is used.

Claims (17)

A system for identifying a user and providing a virtual tunnel on the Internet for communication of the user, the system comprising:
A tunneling server module configured to receive a user request for permission to communicate via the virtual tunnel via a virtual tunneling protocol and to send a permission request to the permission module based on the user request;
Sending an HTTP redirect to a welcome page for entering the user credentials to the browser of the user device, receiving a user request including a first password from the user device, and sending a PPP session authorization request to the tunneling server A configured router to send to the module;
With
The permission module receives the permission request from the tunneling server module and permits the user only when the permission determination based on the first password included in the user request determines that the user is authenticated. Configured to send an acceptance message to the tunneling server module;
The first password is transmitted to the user device by a remote server module upon successful authentication of the user credentials, and the transmission indicating the authorization decision is a server remote from the authorization module Received by the authorization module from
The tunneling server module communicates with the user via the virtual tunnel only after the tunneling server module receives the permission acceptance message for the user, and sends an Internet request from the user via the virtual tunnel. Is configured to forward the Internet request to a destination address included in the Internet request,
The tunneling server module is configured to receive a reply in response to the internet request over the internet and transmit the reply to the user ;
The configured router sends a RADIUS request to the authorization module and receives a configuration profile from the authorization module;
A server remote from the authorization module issues a second password and sends it to the configured router, and the configured router uses the second password to create an L2TP / PPP tunnel with the tunneling server module. Build and
The tunneling server module is further configured to assign a public IP address to the user session of the user;
The tunneling server module assigns the public IP address to the user session by port address translation (PAT), requests a private IP address and port,
The reply is received by the tunneling server module as addressed to the assigned public IP address;
The tunneling server module is further configured to translate the public IP address to the user's private IP address before transmitting the reply to the user.
system. The system of claim 1 , wherein the virtual tunnel is a layer 2 tunneling protocol tunnel. The system according to claim 1 or 2 , wherein a point-to-point data link protocol session is established in the virtual tunnel. The tunneling server module is a layer 2 tunneling protocol network server, the permission module, said layer 2 tunneling protocol network server according to any one of claims 1-3 which is a separate proxy RADIUS server System. 2. The tunneling server module is a layer 2 tunneling protocol network server, the authorization module is proxy RADIUS, and both the proxy RADIUS and the tunneling server module are located in an Internet service provider data center. 5. The system according to any one of items 1 to 4 . 6. The system of claim 5 , wherein a server remote from the authorization module is located in a centralized data center remote from the internet service provider data center. The system of claim 6 , wherein the centralized data center and the Internet service provider's data center communicate via a dynamic context router. The system according to claim 6 or 7 , further comprising a proxy RADIUS arranged in the central data center and configured to make an authorization decision based on the first password. The system according to any one of claims 6 to 8 , wherein the remote server module is arranged in the central data center.   The first password is a random one-time password;
  The system according to any one of claims 1 to 9.   The tunneling server module stores the port address conversion log in a public server;
  The system according to any one of claims 1 to 10. A method of identifying a user and providing a virtual tunnel for the user's communication over the Internet, the method comprising:
The configured router sends an HTTP redirect to the welcome page for entering the user's credentials to the browser of the user device, receives a user request including the first password from the user device, and accepts the PPP session Sending a request to the tunneling server module;
Receiving the user request for permission to communicate through the virtual tunnel via a virtual tunneling protocol, via the configured router, by the tunneling server module;
Based on the user request, by the tunneling server module, sending a permission request to the permission module;
The authorization request from the tunneling server module is foreseen by the authorization module and is a first password received by the user device from a remote user information server and based on a first password included in the user request Sending a request for a decision to a remote authorization server;
And that the permission is responsive determination to the request for permission decision, received by the authorization module, it transmits a response of the permission determination to the tunneling server module,
Executing the communication with the user via the virtual tunnel by the tunneling server module only after the tunneling server module receives the permission acceptance message to the user as a response to the permission determination ;
Receiving an internet request from the user via the virtual tunnel by the tunneling server module and forwarding the internet request to a destination address included in the internet request;
Receiving a reply to the internet request in response to the internet request by the tunneling server module over the internet and transmitting the reply to the user ;
A public IP address is assigned to the communication session by the tunneling server module, and the reply is received by the tunneling server module as addressed to the assigned public IP address;
Converting the public IP address to the user's private IP address by the tunneling server module;
Transmitting the reply to the user;
Including
The first password, when the authentication of the user credentials is successful is transmitted from said remote user information server to the user device,
Translation by the tunneling server module includes port address translation of the request to translate the private IP address and port to the public IP address;
The configured router sends a RADIUS request to the authorization module and receives a configuration profile from the authorization module;
A server remote from the authorization module issues a second password and sends it to the configured router, and the configured router uses the second password to create an L2TP / PPP tunnel with the tunneling server module. To construct,
Method. Established the virtual tunnel, The method of claim 1 2 is a Layer 2 Tunneling Protocol tunnels implemented as a point-to-point data link protocol session. The tunneling server module is a server located in an internet service provider's data center, the authorization module is a RADIUS proxy server located in the internet service provider's data center, and the remote server is the tunneling 14. A method according to claim 12 or 13 , wherein the method is located remotely from a server module and the authorization module. The method according to any one of claims 1 2 to 1 4 point-to-point over Ethernet encapsulation is used.   The first password is a random one-time password;
  The method according to any one of claims 12 to 15.   The tunneling server module stores the port address conversion log in a public server;
  The method according to any one of claims 12 to 16.

Images