Network configuration
Once the dedicated server service has been activated, the Customer receives the network parameters required to connect the server to the public network and — if ordered — to a private network or additional network services. The network configuration may include a public IP address, the server’s network interfaces, DNS records, the internal network and Anti-DDoS protection.
The range of available options depends on the service configuration, server type, assigned IP addresses and any additional services purchased by the Customer. Some information and operations may be accessible directly via the Customer Portal, whilst certain changes may require the Customer to contact Atman via a support ticket.
Publiczna adresacja IP
A public IP address enables the server to communicate with the Internet. Once the service is started, the client receives the address details assigned to the server or network service.
A standard set of information may include:
Server IP address — the primary public IPv4 address assigned to the service.
Subnet mask — a parameter specifying the size and scope of the allocated network.
Default gateway — the router’s address through which the server communicates with the external network.
Additional IP addresses — if ordered, these may be assigned to the same service or used by virtual machines, application services, containers, firewalls, high-availability systems or other components of the Customer’s environment.
IPv6 addressing — if available and specified in the service configuration.
Once you have received the network details, you must configure them in the server’s operating system in accordance with the distribution or system you are using. For Linux systems, configuration can be carried out using, amongst other methods, Netplan, NetworkManager, interface configuration files or tools specific to the distribution in question. On Windows systems, configuration is carried out via the network adapter settings or the system’s administrative tools.
Once the addressing has been configured, carry out a basic connectivity check:
check whether the network interface is active,
check that the IP address, subnet mask and gateway are correct,
carry out a connection test to the default gateway,
carry out an internet connection test,
verify the operation of services listening on a public IP address,
Check the system firewall rules if the services are not accessible from outside.
If you experience communication issues, you should first check the operating system configuration, the status of the network interface and the firewall rules. If the server-side configuration is correct and the problem persists, please raise a support ticket in the Customer Zone.
Zarządzanie interfejsem sieciowym
The server’s network interface is responsible for the server’s physical or logical communication with the Atman network and the client’s networks. Depending on the server’s configuration, one or more network interfaces may be available.
Interfaces can be used, amongst other things, for:
Public communications — access to the internet and publicly available services.
Private communication — internal traffic between the Client’s servers, application environments, databases or back-end systems.
Traffic separation — the separation of production, administrative, backup or replication traffic.
High-availability configuration — the use of multiple interfaces, IP addresses or redundancy mechanisms at the operating system and application levels.
Virtualisation — assigning IP addresses to virtual machines, bridges, VLANs or virtual interfaces.
After starting the server for the first time, you should check whether the operating system correctly detects the network adapters and whether the correct interface is active. In particular, you should check the following:
the name of the network interface,
connection status,
link speed,
assigned IP address,
default routing,
konfigurację DNS,
firewall rules,
any VLAN, bridge, bonding or teaming configuration.
In the case of servers with multiple network interface cards, care must be taken to ensure that the correct physical port is designated for public communication and the correct one for private or administrative communication. Incorrectly assigning a configuration to the wrong interface may result in the server becoming inaccessible.
If the Customer is planning to implement an advanced network configuration, such as link aggregation, VLANs, a bridge for virtualisation, application traffic separation or a high-availability environment, it is recommended that they plan the addressing, routing and allocation of roles between interfaces in advance.
DNS Management
DNS enables domain names to be linked to the IP addresses of services. This allows users and applications to use names such as example.pl instead of direct IP addresses.\ \
Depending on the domain management model, DNS records can be managed:
On the customer’s side — with their current domain registrar, DNS provider or via an external DNS control panel.
On Atman’s side — if the Customer is using the DNS services provided by Atman or the domain has been delegated correctly.
In external DNS systems — for example, with cloud service providers, CDN operators, application security providers or specialist DNS providers.
The most commonly used DNS records are:
A — maps a domain name to an IPv5 address.
AAAA — resolves a domain name to an IPv6 address.
CNAME — creates an alias for another domain name.
MX — specifies the mail servers that handle the domain.
TXT — used, amongst other things, for SPF, DKIM, DMARC, domain verification and other security mechanisms.
PTR — a reverse record that maps an IP address to a domain name. It is particularly important when configuring email services.
Once the server has been launched, the Customer may point a domain or subdomain to the public IP address assigned to the service. To do this, they must create or amend the relevant DNS record, most commonly an A record.
Please note that changes to the DNS may not be visible straight away. The propagation time depends on the TTL settings, the DNS provider and the caches on the resolver side. In practice, some changes may be visible after a few minutes, but full propagation may take longer.
In the case of postal services, particular attention should also be paid to the correct configuration of MX, SPF, DKIM, DMARC and PTR records. Failure to configure the DNS correctly may affect the deliverability of emails.
Internal network
An internal network enables communication between the Client’s services without the need to use the public Internet. It can be used to build multi-server environments, application systems, databases, clusters, backup and replication systems, and high-availability environments.
The internal network can be used, amongst other things, for:
Application–database communication\ The application server can communicate with the database server via a private network, without exposing the database to the Internet.
Communication between the Client’s servers\ Several dedicated servers can exchange data within a single dedicated private network.
Backup and replication\ Traffic relating to backups or replication can be separated from public traffic.
HA Environments\ A private network can be used for communication between cluster nodes, service state synchronisation, heartbeats and data replication.
Separation of system layers\ It is possible to separate the front-end, back-end, database and administration layers.
When using an internal network, the Customer should plan for private IP addressing and the method of communication between servers. Private addressing from the RFC1918 ranges is most commonly used, for example:
10.0.0.0/8,
172.16.0.0/12,
192.168.0.0/16.
On the operating system side, an additional interface or additional addressing assigned to the private interface must be configured. When configuring the system, ensure that the default route to the Internet remains assigned to the public interface, whilst internal traffic is routed via the private interface.
In the case of more complex environments, it is worth drawing up a simple addressing plan, covering:
server names,
public addresses,
home addresses,
the roles of individual servers,
required communication ports,
firewall rules,
routing requirements,
relationships between services.
The availability of the internal network and how it is set up depend on the configuration ordered. If a Customer wishes to combine several services within a single private network or set up additional traffic separation, they should check the available options in the Customer Portal or submit a support request to Atman.
Anti-DDoS Protection
Anti-DDoS protection is designed to mitigate the effects of Distributed Denial of Service attacks, which aim to disrupt service availability by generating a high volume of traffic or application- or protocol-based traffic.
For dedicated servers, Anti-DDoS protection may be available as part of the service or as an additional service assigned to the customer’s environment. The scope of protection depends on the service option selected and the network configuration.
Anti-DDoS protection may include, amongst other things:
Network traffic monitoring\ Traffic directed to the Customer’s services is analysed for anomalies and patterns characteristic of DDoS attacks.
Mitigation of volumetric attacks\ Security systems limit the impact of large volumes of unwanted traffic on service availability.
Filtering out unwanted traffic\ Depending on the nature of the attack, traffic may be filtered or restricted before it reaches the client’s infrastructure.
Service Availability Protection\ The aim of the service is to maintain the highest possible availability of the Client’s resources during an incident.
Operational support provided by Atman\ In the event of any problems or if an attack is suspected, the Customer may contact Atman by submitting a report via the Customer Zone.
Once the service has been launched, the Customer should check that Anti-DDoS protection is active for the correct service or IP address. If the protection is listed in the Customer Portal as a separate service, it should be treated as part of the environment’s security measures.
If you suspect a DDoS attack, you should:
check whether the problem affects a single service, several services or the entire addressing scheme,
check the server load,
check the system and application logs,
check the traffic statistics, if available,
reduce unnecessary public services and ports,
Create a ticket in the Customer Area, describing the symptoms.
It is worth including the following in your application:
the IP address affected by the issue,
the time the incident began,
the type of service that is unavailable,
symptoms observed,
examples of logs or messages,
whether the problem occurs constantly or intermittently,
information as to whether the customer is observing any unusual activity on the server side.
Anti-DDoS protection is no substitute for the correct security configuration of the operating system and applications. The customer should continue to use a firewall, keep the system up to date, restrict access to administrative services, secure applications and monitor their own environment. Anti-DDoS should be regarded as a layer of network protection designed to increase the service’s resilience to overload attacks.