Phare EIONET Centralised Training Session EIONET node Architecture & Connectivity
Overview of the Presentation EIONET node components Physical architecture Logical architecture Variations IP Addressing issues Additional servers Management of the node Questions & Comments
Eionet node components (standard architecture layout) Internet link Access server (router) EIONET server(s) Firewall node’s LAN
Physical architecture The only requirements from the point of view of physical connections are: EIONET server should be connected to Internet EIONET server should be connected to LAN LAN should be connected to Internet.
Logical architecture “The Internet” is able to access EIONET services LAN should be able to access EIONET services + other services (ex. Mail retrieval) Access to EIONET server(s) should comply to EIONET security policy Access to LAN should comply to local security policy
Logical architecture (cont. …) And that meens… LAN topology and existing wiring style may may impose different solutions than the “standard” EIONET node schematics Local security policy may require ALL computers to be “behind firewall” Internet provider change may also change the interface to an unsupported one ... Etc. ... …we could need variations
Variations Variations in EIONET node’s architecture are possible as long as they implement: Physical connectivity constraints Logical connectivity constraints Compliance to EIONET security policy (applicable to EIONET server(s) Invariance of the way OTHERS see and access your node’s services
Variations (cont. …) In punch-lines: You should ensure the possibility of implementing two (usually) different security policies; eventually on the same machine … You should be able to reliably distinguish between LAN users accessing EIONET server and Internet users AGAIN and AGAIN: your structure should be functionally equal to all other EIONET nodes
Phare EIONET Centralised Training Session Practical issues
large number of workstation in LAN IP addressing scheme When deciding the actual addressing scheme, each EIONET node faces one or more of the following constraints: reduced number of registered IP addresses provided by ISP (a quarter of a C class or less) large number of workstation in LAN foreseeable growth in number of servers/workstations both in LAN and Internet exposed
Terms IP address; dotted decimal notation Network mask Classfull and classless subneting Subnet and Host ID Subnetzero
IP network classes
Divide the available range of addresses
HW &. SW subnetting
Custom Subnetting: the steps
Chart for class C Networks
Determine subnet ID
Last step: Numbering Hosts
Additional servers Physical and logical location of additional servers inside EIONET node structure should be decided studying: Server audience (in terms of: LAN and/or Internet clients) Server capabilities (in terms of protecting itself) Impact to other servers and the node’s structure
Additional servers (cont. …) Open Access Reverse proxy, multi class segment, etc ... EIONET security policy
Management of the node There are several aspects of the node management: System management: servers, routers, firewall(s); includes system backup/restore activity Network management: connectivity, performance, network services Application management: software installation, patches & upgrades; includes applications’ backup, data migration etc. ... System, Network and Applications monitoring: logs, events etc.… Security management: monitoring, updates, alarms, crisis scenarios preparation etc. ...
System management Basic responsibilities for the EIONET node systems manager: SO patches and upgrades: to be performed with balance between fixing bugs, enhancing functionality and keeping full compatibility with installed applications Backup of vital system configuration data before any SO changes and/or reconfigurations are planned Monitors event logs, disk and other resources usage and reacts accordingly to situations that may affect availability and/or quality of services offered by the respective systems Keep users informed of changes, interrupts in operation and client side targeted security threats (I love you message …)
Network management General guidelines: plan carefully structural changes; better still: avoid them monitor network performance at all times, determine the bottleneck before users can feel it if network complexity requires install automated SNMP tools to trap and alert you on unwanted events
Questions & Comments