5. Internet Gateway and Related Systems¶
5.1. System Scenario¶
This document describes exemplary solution implementations for an “Internet Gateway and Related System” scenario. Internet Gateway and related systems are systems that internal corporate users prepared to implement for utilizing to complete their tasks in the Internet connectivity platform environment. These systems mainly possess the following features:
- Installation of proxy servers and implementation of various security measures for web traffic access to the Internet.
- For small scale offices without VPN connectivity, the system establishes connectivity between cloud environments / sites within the VPN using Internet VPN (IPsec).
- Performs remote access from the Internet to the cloud environment and / or within the VPN using SSL-VPN.
5.2. System Configuration¶
This system, assuming implementation of DR (i.e., Disaster Recovery) measures, is configured from 2 geographically separate sites: the main site and the DR site. The system configurations for the main site and the DR site are described below.
5.2.1. Main Site¶
The main site accommodates the system during normal operation times, and configurations similar to the following can be assumed.
- Installation of various servers with consideration to physical locations in order to minimize downtime for systems on the DMZ segment.
- Main site applies UTM as security measures for such time as transmitting externally.
- Connectivity with several DCs using free of charge/low cost VPN connectivity service.
- Connectivity between sites using IPsec for small scale locations without VPN.
Below is a diagram outlining the system configuration.
The main points of the configuration are described in the following sections.
5.2.1.1. VPN / Internet Connectivity Depending Upon the Uses¶
The cloud environment provided with this service enables direct connectivity through Arcstar Universal One which is one of the VPN services via VPN Connectivity. The cloud environment provided by this service enables direct connectivity with the VPN server Universal One through the Cloud-GW. In cases where there are servers at the Customer location that must perform direct Internet transmissions, or where Internet access from several thousand locations is required, a configuration can be implemented to consolidate Internet access to the cloud environment as transmissions can be performed from the Internet connectivity setup on the cloud. This configuration is extremely useful not only from a cost perspective, but also for the ability to centralize control of a company’s internal Internet access.
5.2.1.2. VPN Termination Between Sites Using IPSec¶
Termination can be performed by IPsec VPN functions provided through the Firewall. This can be applied to Internet VPN in between sites using IPsec for connectivity with temporary locations and small scale locations not included in a closed network. As the Firewall is installed in a location assigned by the Customer, this configuration allows separate internal installation of a Firewall for IPsec termination, which differs from an external Firewall, and performs IPsec termination on the internal segment end. Furthermore, Customers can multiply install Internet Connectivity; therefore, it depends on the Customers themselves to determine how they distribute IPsec connections; e.g., servicing Internet for public release and separately relocated IPsec connected Internet Connectivity.
Furthermore, bandwidth control can be performed on each internal Firewall to prevent specific locations from occupying bandwidth due to download of Internet files.
Note
NAT Traversal settings to allow IPsec transmissions must be performed on Firewall.
5.2.1.3. Strengthening Security Measures¶
The UTM service provides IPS/IDS anti-viral functions, and web filtering functions. As logical networks can be setup according to the Customer, UTM can be setup to filter transmissions between segments with traffic that should be scanned. In cases where there are inter-segment transmissions that don’t require scans, consumption of UTM processing performance by these transmissions can be avoided. This can lead to cost effectiveness in UTM setup.
In this example, UTM is setup only for transmissions connected to external networks, but it is possible to further setup UTM in multiple places as necessary.
5.2.1.4. Physical Level of Server Redundancy¶
As the Internet currently occupies an important position for execution of company tasks, high reliability is required for various servers installed in the DMZ such as proxy servers and mail relay servers.
Generally, Virtual Servers provided by cloud services cannot be optionally assigned to a physical host on which they will be stored. As such, even if redundancy is created through multiple Virtual Servers there is a possibility that all will be stored on the same physical host. In cases where a failure occurs on the physical host, these redundant Virtual Servers will be suspended simultaneously, leading to a suspension of service. Virtual Servers provided by public IaaS can be optionally assigned during creation to a physical host equipment group (Group) on which the it will be stored. As a result, physical level redundancy to ensure distribution of physical hosts for storage can be achieved through creating Virtual Servers on differing Groups for redundancy.
5.2.1.5. Larger Volume / Lower Cost / Higher Reliability Data Archiving¶
Storage of data such as proxy server access logs are critical for Internet Gateway and related systems. Daily generated log data will continually enlarge, but it is necessary to securely save data for purposes such as IT audit support. Cloudn Object Storage and Biz Simple Disk utilization is recommended as the storage destination for this archive data.
Object Storage can be utilized via the Internet, and Biz Simple Disk can be utilized via VPN. Either services perform distributed data write multiple data centers, and as such, high reliability of 99.9999999999% (12 nines) by Biz Simple Disk and 99.999999999% (11 nines) by Object Storage is achieved.
Note
Cloudn Object Storage、Biz Simple Disk will be dedicated within the domestic Japan.
5.2.2. DR Site¶
In cases where the main site is offline due to disaster, tasks utilizing the Internet will be suspended. Due to this, it is necessary to consider scenarios involving disaster measures for building a DR site to quickly resume tasks. Here, an example system configuration will be introduced with the following features for low cost DR implementation.
- Until a disaster occurs, the DR site will run the minimally required servers and others will be maintained by template etc.
- Global IP addresses used by Internet connectivity and VPN connectivity settings will be setup beforehand for quick switch-over to the DR site.
- After a disaster occurs, server templates that were maintained and Firewall settings information etc. will be used to build a DR site system.
Below is a diagram outlining the system configuration.
The main points of the configuration are described in the following sections.
5.2.2.1. Preliminary VM Volume Image Copying¶
The Virtual Server volume being used at the main site will be obtained beforehand. The volume created will be stored on the main site image storage, but can be exported via API or portal. Additionally, the exported volume can be imported to the DR site image storage space. These export/import tasks will be performed in advance. Once the Virtual Server (Instance + Volume) is created and deployed from the previously transferred volume at the DR site, the various DR site settings will be performed.
Note
Volume cannot be exported in cases where the license service is associated with the volume.
After settings to the virtual server are complete, in cases where it is necessary to perform a sync with data from normal operating times because of the server’s attribute, the instance will be deployed and left on standby (hot standby). When data sync is not necessary, the instance will be set to a suspended status during normal operation times, and a virtual server will be deployed during a disaster. In this case, running cost can be cut back, in comparison to deployment status costs, due to instance billing applied based on suspension status (cold standby). Additionally, in cases where switch-over time is flexible to some extent, the instance will be deleted leaving only the volume (disk storage). In this case, cost can be suppressed, but tasks for deployment of the server may be time consuming. When a disaster occurs, the instance will be created based on the volume that was saved previously. Through this, instance billing will not be generated and only volume charges will not be billed. Running costs can be further reduced.
5.2.2.2. Preliminary Internet Connectivity Settings¶
A 10Mbps Internet Connectivity menu will be connected in advance at the DR site, as it can be either utilized free of charge or very inexpensive.
Additionally, only the required number of global IP addresses will be contracted secured beforehand. Through this, address design can be performed in advance for the DR site. For example, the settings parameters for the external Firewalls and external DNS can be determined in advance using the previously allocated global IP addresses which will enable quick switching of operations changes during DR initiation.
As a note, if 10Mbps bandwidth is insufficient after DR is initiated then bandwidth will be extended to the necessary size.
5.2.2.3. User Access Paths Switch-Over¶
When migration and restore processes are completed for data at the DR site, it will be necessary for to switch access paths for users. Especially for Enterprise system where accessing through VPN in user scenario, VPN access path should be required to be changed accordingly without any difficulties. For such switch-overs, there are two (2) patterns for Customers to utilize as below:
- By regularly designating private IP Addresses anew to respective nodes on the DR Site, VPN should be connected from the beginning. At the time of DR, internally utilized DNS record will be modified and user connection will be switched over safely from main site to recovery site. With switching over private IP Addresses to ensure such actions, DR Zone files and change scripts should be prepared beforehand regularly as daily routines, which will let Customers proceed much more smoothly.
- In the other patterns, the replica configuration is deployed by Customer, preparing for such event as DR even prior to such will occur; therefore, Customers can smoothly switch over to the other side by designating private IP Addresses on DR site (just as service will) with the main site service. At this point, difficulty on system transmissions as route is not clarified on DR site, so such actions will not arise any risks even though concurrent IP Addresses are assigned on both of DR and Main Sites. At the time of disaster or abnormal failures on Main Site, the well-prepared API will be utilized and that will open the route, which will guide DR Site’s new-coming transmissions.
Furthermore, Internet transmissions and 10Mbps Menu (at Best Effort) should be either free of charge or if ever charged that will be less than market price, so such can be utilized without much of financial burdens on the end of Customers, so the Internet connectivity beforehand is required. Moreover, Customers can ensure their global IP Addresses (these are commercially priced, so it is not really free) with parameters including global IP Addresses. By doing so, Customers can create such switch-over procedures much easier and simpler orders when the disaster recovery does occur in real time.