Schematic topology

The most common topology of United Networks can be shown schematically as follows:

As can be seen from drawing above used topolosy is “hub-and-spoke”. There are some sites in Network including sites from Russian (mainly Siberian on now days) regions which are connected via OpenVPN tunnels (1024-bit encryption key length) to the Central one. Nevertheless the most of sites from the Moscow region. The comprehensive list (on present day) of the sites is the following:

  • 2nd-district.abakan - 2-nd District, Abakan (region Khakassia);
  • 2nd-zachatyevskiy - 2-nd Zachatyevskiy side-street, Moscow;
  • altufevo.msk - Altufevo district, Moscow;
  • gogolya.pushkino - Gogolya street, Pushkino, Moscow Region - central site;
  • sokol.msk - Sokol, Moscow;
  • eltsovskaya.nsk - Eltsovskaya street, Novosibirsk;
  • zelenka.pushkino - Zelenogradskiy settlement, Pushkino district, Moscow region;

Geographic distribution of Sites

Russia map. Moscow region map. And Moscow city map.

Physical topology

Physical connections accross different hardware is shown below:

Here the list of ISPs (and technologies used) that provide Internet connections for the sites:

Site Name ISP Technology Auth (VPN) type Speed
2nd-district.abakan Sibir-Telecom ADSL PPPoE 2M
2nd-zachatyevskiy Beeline (former Corbina) Ethernet LAN then L2TP 512K
altufevo.msk Beeline (former Corbina) Ethernet L2TP 4.5M
gogolya.pushkino Beirel-Telecom Ethernet DHCP, no-auth 5M
sokol.msk VPK-Telecom Ethernet ISP's VLAN, no-auth 10M
eltsovskaya.nsk Novotelecom Ethernet DHCP 5M
zelenka.pushkino MTS GPRS/3G SIM 128K

Typical site schemes

Administrators stick to some common ideology when deploying their subordinate networks at a some site. The most frequent site schemes are the following.

Typical Site with one network on remote support

This is the top frequent scheme. When the local ISP offers xDSL-connection only, DSL-modem is taken out local site network, and it plays role of a “bridge” or channel-level protocol converter (ATM to Ethernet and back again), not a role of router and authenticator. Authentication/authorisation functions are placed on Gateway of this site which is typically named as “Srvgate” (see "Naming convention" section).

For the goals of ADSL-modem control separate network is allocated. This one is considered as “partially-in-perimeter” - the special firewall rules must be applied as on gateway as on DSL-modem to restrict access from ISP side. Nevertheless access from gateway at IP layer to DSL-modem is full and unlimited. The second network is allocated for all existing hardware including switches, Wireless controllers, user computers and notebooks. The last is fully defended by gateway's firewall from Internet and access from this network to gateway must be restricted by responsible administrator. For example “2nd-district.abakan” is such site.

When ISP gives direct Ethernet connection to the site there is no need to allocate additional network cause there is no additional United Networks hardware between ISP and Srvgate. The example of this scheme can be “gogolya.pushkino”. It is simplier case of above with all previous conditions on perimeter protection.

The following authentication methods are can occur in United networks for considered site design:

  • ADSL with PPPoE authentication;
  • Ethernet with L2TP/PPTP VPN and authentication;
  • Ethernet with DHCP leased address and without authentication;
  • Ethernet with separate ISP's VLAN/Network for connection with no authentication.

The Gateway (Srvgate) may be as dedicated computer as Virtual Machine under VMWare on most powerful user computer in this network. Under some reasons (for example user is inexperienced, he does not see essential difference between Linux and Windows and the computer is the only one at the site) Srvgate can be given to site users for work. In that case some Linux Desktop is deployed. The example of such practice is “2nd-district.abakan” site.

Two networks from pool 172.16.0.0/12 are allocated when this scheme is deployed (see ”Addressing plan” section) independent to ISP connection technology.

Typical Site with single (mobile) computer and no subordinate networks

This is the second on popularity scheme. Mobile users or users without hardware with only computer or often simply notebook use this design of connection to Central Site. This VPN is a “twig” (stub) - no “leaf” (subordinate) networks. Thus end-point of VPN connection hasn't routing features.

Because in this type of sites stub computer is usually Windows machine and VPN there is organized with of TUN/TAP-interface firewall must be off on it and in the same time network filtration must be enabled with defaults on physical interface which suplies Internet connection. By these means perimeter protection is ensured. The example of such site scheme is “2nd-zachatyevskiy.msk”.

Inspite of absence of subordinate networks two subnets from pool of 172.16.0.0/12 is allocated because of OSPF aggregation issues and potential grouth of this design into next considered scheme.

Site with single notebook and subordinate network

This design is extension of previous case with addition of some hardware. Actually such scheme is signle at current moment. Site “zelenka.pushkino” is mutated from above when printer has appeared. Local notebook was not mobile and when printer appeared need to control it has arised.

And as in previuos case OpenVPN's TUN/TAP interface and internal interface are in the perimeter with firewall off and physical interface (MTS's USB 3G-modem) which provides Internet connection is undergone network default Windows filtration.

This site is already legally allocated two of 172.16.0.0/12 networks.

Enhanced Site with multiple subordinate networks

In this case site is quite like the first described “Typical site with one subordinate network” with exception that it has more than one subordinate network. These sites are belong to United Networks System Administrators. Here division networks and organization of separate VLANs may occur. For instance isolation of IP-Phones into separate Voice VLAN (separate subnet) may take place. Or separation servers into “Server-Farm-VLAN” can be. It even could have VPN-connected computers (modile users) with allocation or with no allocation one of subordinate networks. For example “sokol.msk” Site has two remotely connected sites via OpenVPN which is customized in very special way to support two types of VPN: “client” to connect to Central Site and “server” to aggregate secondary connections. Remote sites each are allocated /24 network per site from /20 pool of “sokol.msk” site. These are routed from “sokol.msk” in common manner along with other “sokol.msk” subnets as a single aggregated block.

Such sites have no common rules for building. From point of view of VPN networks this is usual site. But on other hand… The main idea that it must obey to repeatedly mentioned above requirement of “perimeter defence”. Restrict or not access to Site's resources is at discretion of Administrator of that Site. It is strongly recommnded to allow access of others to critical Site's network equipment (including srvgate) but it is only recommendation.

This type of site is allocated 16 networks from pool 172.16.0.0/16. They are fully in disposal of Administrator.

Typical Srvgate's common configuration

Typical gateway which lets out own local subnets has the following approximate configuration.

Hardware

  • CPU: Intel Celeron 2 GHz much like “Celeron Wolfdale” - Dual-cored with VT;
  • RAM: 1GB DDR2/DDR3;
  • HDD: some Seagate near 500 GB, RAID Edition;
  • Cooler: something like Asus Triton - silent and very much effective;
  • Video: Embedded Graphic Adapter Intel IGFX, or simpliest cooler-free NVidia with the lowest power consumption;
  • LAN: embedded LAN 100 or 1000 Mbit/s or some standalone one with RTL8139 chipset;
  • Power Supply like Powerman IP-S400 or FSP BlueStorm near 400 Watt;
  • Some case like InWin ;

Other Site's Hardware includes:

  • some D-Link Switch of D-Link wireless router with Wireless bridge and embedded Ethernet switch (much like DIR-300);
  • [optional] some D-Link ADSL-Router with embedded Ethernet switch (like DSL-524T);
  • some MFU with opportunity of work in conjunction with CIS-system (like HP PhotoSmart C7283);
  • some IP Phone like Zyxel P2300RDL or Cisco CP7906.

…and it's meant user PCs and Notes which have no special requirements.

Software

  • Ubuntu Desktop Long-Term Support (LTS);
  • IPTables - for protecting perimeter;
  • Quagga - to support of routing protocols (OSPF in particular);
  • OpenVPN - fro connection to Central Site;
  • Bind DNS - to cache internal zones;
  • Samba - to connection to Windows shares;
  • Other software specific to this certain site.

Security issues

  • Every Site must provide permiter protection. It MUST provide easy access from VPN Network side (172.31.0.0/16, see Addressing Plan for details). It MUST provide access to own Users from Subordinate Networks to United Networks (172.16.0.0/12). It CAN give access from United-Networks to own Subordinate Networks. It is a “Local Autonomy Principle”, but under “Global General Rules”. All access to local Site's resources should be allowed locally. It can be in a form of some long-term (written) agreement or just of asking every time when it's needed to access from some site to local one.
  • All Subordinate Networks can be in perimeter, Internet must not. All non-UN networks MUST be restricted to minimally possible access that is really needed to this Site (e. g. local WWW, or Mail). There MUST NOT be connections allowed from outside to User computers or any other network devices. If one Site will be defeated all other Sites will be ubder еру threat.
  • Network for ADSL-modem control must be “semi-perimeter”, that is Srvgate MUST have unfiltered access to ADSL-modem, ADSL-modem MUST restrict access to itself for Srvgate only and authentication with Username (if allowed) and Password MUST be provided.
  • Wether or not Srvgate is a dedicated machine access from Local Users (from Subordinate Networks) MUST be restricted to it.

It is strongly recommended:

  • Do not accept SSH connections from outside. SSH CAN be allowed from public IP-addresses of other Srvgates in UN or some trusted computer in Internet.
  • FTP, Telnet, SMB, NetBIOS, Kerberos and other Windows ports MUST be prohibited on Srvgate's firewall for access from outside.
  • If Site has Mailer Agent even possibility of “Open Relay” MUST be disabled and either SPAM-filter MUST be deployed. It is recommended to prohibit direct SMTP connections from Subordinate Networks to External World to avoid mass SPAM sending in result of virus infection of User Computers.
  • It is good practice to allow internal-to-external connections (from User computers to External destinations) on demand only - only required protocols/ports CAN be opened. And only for requsested Users.

In the other words all traffic flows must be under vigilant control of System Administrator.

general_topology.txt · Last modified: 2016/01/31 11:14 (external edit)
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki