Passer au contenu 
Je vais te montrer comment utiliser ton réseau hetzner et que tu augmentes ainsi de manière ciblée la performance, la sécurité et l'évolutivité. Pour ce faire, je m'appuie sur la pratique : du panneau cloud aux variantes de routage, en passant par les IP de basculement, les MAC virtuels, IPv6, la sécurité, le diagnostic des erreurs et la surveillance.
Points centraux
- Espace d'adressage choisir : Utiliser proprement la RFC 1918, planifier des sous-réseaux propres.
- Mode déterminer le type de connexion : Routed, Bridge ou vSwitch en fonction de l'objectif d'utilisation.
- Linux-Maintenir la cohérence de la configuration : ifupdown, netplan, systemd-networkd.
- Basculement & MAC : attribuer correctement des MAC virtuels, définir des routes d'hôtes.
- Sécurité & Surveillance : établir une segmentation, des pare-feux, des logs et des contrôles.
Principes de base de la configuration du réseau Hetzner
Une planification soignée évite des dépenses ultérieures et fournit des résultats tangibles. Performance. Je sépare les systèmes internes dans un réseau cloud dédié, j'isole les composants sensibles et je maintiens le vecteur d'attaque public à un niveau faible, ce qui Sécurité a considérablement augmenté. Les réseaux privés dans le cloud Hetzner me permettent un contrôle granulaire, des voies claires pour les flux de données et moins de bruit de diffusion. Je définis très tôt quels serveurs ont besoin d'adresses publiques et lesquels ne parlent qu'en interne, afin que le routage, les pare-feux et l'attribution des IP restent logiques. Cette clarté s'avère payante dès que le failover, le load balancer ou l'orchestration de conteneurs entrent en jeu et que je dois gérer plusieurs serveurs. Sous-réseaux de manière claire.
Hetzner Cloud Panel : Créer un réseau et choisir l'espace d'adressage
Dans le panneau Cloud, je crée un nouveau réseau, j'attribue un nom unique à chaque projet et je choisis un espace d'adresses RFC-1918 tel que 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16 comme Bloc IP. Je planifie les sous-réseaux à l'avance, par exemple /24 pour les couches d'applications, /28 pour les accès administratifs ou /26 pour les bases de données, afin que la croissance reste bien représentée. Ensuite, j'intègre des serveurs, des équilibreurs de charge et des services supplémentaires pour que la communication soit immédiatement établie. Pour les débutants dans la plate-forme, je livre volontiers le Présentation du serveur cloudqui résume les principales options. Dès que le réseau est prêt, je teste l'accessibilité de base et je vérifie les groupes de sécurité pour m'assurer qu'aucun port inutile n'est ouvert et que mes utilisateurs ne se sentent pas en danger. Pare-feu-Les règles de l'UE s'appliquent.
Conception de sous-réseaux et planification IP en détail
Je travaille avec des conventions de nom et de numérotation claires, afin de pouvoir reconnaître intuitivement les sous-réseaux par la suite. Chaque zone (p. ex. app, db, mgmt, edge) reçoit une plage de numéros fixe et une taille standard documentée. Je réserve délibérément des zones tampons entre les sous-réseaux afin de permettre des extensions sans renumérotation. Lorsque les services évoluent horizontalement, je préfère prévoir plusieurs /25 ou /26 plutôt qu'un grand /22 ; les ACL et les routes restent ainsi légères. Pour les accès admin, je prévois un 28 de gestion séparé que je durcis de bout en bout et que je rends accessible via VPN ou des hôtes bastion. Lorsque je connecte des sites externes, je définis dès le départ des zones claires qui ne se chevauchent pas et j'établis des routes statiques de manière ciblée afin d'éviter tout conflit.
Routed, Bridge ou vSwitch : le mode approprié
Je mise sur trois variantes principales : Routed pour les sous-réseaux supplémentaires et les adresses de basculement, le pont lorsque les invités doivent agir comme leurs propres serveurs, ainsi que vSwitch pour les configurations flexibles et la NAT. Avec le modèle Routed, les adresses supplémentaires dépendent du MAC principal de l'hôte ; j'active le renvoi d'IP pour IPv4 et IPv6 et je définis des routes d'hôte vers la passerelle. Avec Bridge, les invités ont besoin d'un MAC visible sur le réseau ; je demande un MAC virtuel par IP attribuée et je l'associe à l'invité. Je combine vSwitch avec le masquerading pour que les VM avec des adresses privées puissent accéder à Internet, tandis que les services internes restent protégés. Cette sélection contrôle plus tard l'effort, Transparence et la tolérance aux pannes de ma plateforme.
| Mode | Utilisation | Conditions préalables | Avantages | Les pièges à éviter |
|---|---|---|---|---|
| Routed | Sous-réseaux supplémentaires, IP de basculement | Transfert IP, route hôte | Routage clair, bonne Mise à l'échelle | Gérer proprement la passerelle/l'itinéraire d'accueil |
| Pont | Les invités comme "propres serveurs | MAC virtuel par IP | Visibilité réelle par invité | Gestion des MAC dans le Robot nécessaire |
| vSwitch + NAT | VMs privées avec Internet | Masquerading, pare-feu | Isolation interne élevée | Gérer proprement les règles NAT |
Configurations hybrides : cloud, dédié et transitions
Dans les environnements hybrides, je connecte des réseaux cloud à des serveurs dédiés via des instances de routeurs explicites. Un sous-réseau de transit clairement défini et des routes statiques garantissent que les deux parties ne voient que les préfixes nécessaires. Selon les besoins en matière de sécurité, je fais passer le trafic par une instance Edge via NAT ou je route les sous-réseaux de manière transparente. Il est important que la passerelle soit conçue de manière à être hautement disponible - par exemple avec deux VM de routeur qui vérifient mutuellement l'état et prennent le relais de manière transparente en cas de panne. Je tiens également une liste de contrôle à disposition : routes correctes dans le panneau cloud, forwarding actif, états de pare-feu cohérents, et health checks qui vérifient non seulement ICMP, mais aussi les ports pertinents.
Configuration Linux : utiliser correctement ifupdown, netplan et systemd-networkd
Sous Debian/Ubuntu avec ifupdown, je place la configuration dans /etc/network/interfaces ou sous /etc/network/interfaces.d et je maintiens la touche Route hôte est correct. Pour l'adressage IP de l'hôte, j'utilise /32 (255.255.255.255) et je définis la passerelle comme pointopoint pour que le noyau connaisse le voisin. Sous netplan (Ubuntu 18.04, 20.04, 22.04), je définis des adresses, des routes et on-link pour que la route par défaut corresponde immédiatement. Si je change de matériel, je vérifie la désignation de l'interface et la modifie de eth0 à enp7s0, par exemple, afin que la carte réseau puisse remonter. Pour systemd-networkd, je gère les fichiers .network et .netdev, je recharge les services et je teste ensuite toujours le DNS, le routage et le Connectivité.
Réglage du réseau : MTU, délestage, routage des politiques
Je vérifie le MTU de bout en bout, surtout lorsque des VPN, des overlays ou des tunnels entrent en jeu. Si les valeurs ne sont pas correctes, il y aura une fragmentation ou des drops. Sur les passerelles, j'active le TCP-MTU-Probing et je place des clamps MSS aux endroits appropriés afin de maintenir des connexions robustes. J'utilise consciemment les fonctions de déchargement (GRO/LRO/TSO) : je les désactive partiellement sur les hyperviseurs ou lors de l'interception de paquets, je les laisse activées sur les chemins de données purs - en fonction des valeurs mesurées. Si j'ai plusieurs flux ascendants ou des politiques de sortie différenciées, j'utilise le routage basé sur des politiques avec mes propres tables de routage et règles ip. Je documente chaque règle spéciale afin d'éviter que des modifications ultérieures ne déclenchent des effets de bord sans que je m'en aperçoive.
IP de basculement, MAC virtuels et équilibreurs de charge dans la pratique
Pour les IP supplémentaires, je demande dans le Robot Hetzner par adresse, une adresse virtuelle MAC et je les affecte à l'invité pour que l'ARP fonctionne correctement. Dans la configuration routée, le MAC principal reste sur l'hôte et je route les sous-réseaux explicitement vers l'invité. Dans les scénarios de pont, l'invité reçoit son propre MAC visible, ce qui le fait apparaître comme un serveur autonome. Pour le basculement, je définis quelle machine occupe actuellement l'IP ; en cas de changement, j'adapte le routage et, le cas échéant, l'ARP de gratuité pour que le trafic arrive immédiatement. Avec les load balancers, je découple le trafic frontal des systèmes backend, je veille à une répartition régulière et j'augmente ainsi la performance. Disponibilité.
Concevoir proprement les commutations IP
Pour les commutations actives, je mise sur des mécanismes clairs : soit l'instance active annonce une IP via ARP/NDP et la passive reste muette, soit je tire de manière ciblée la route par défaut vers la nouvelle machine active. Des outils comme les implémentations VRRP aident, mais je teste toujours l'ensemble de l'interaction, y compris les pare-feux, les caches voisins et les éventuels timeframes ARP. Important : après le changement, je vérifie l'accessibilité aussi bien depuis le réseau interne que depuis des points de contrôle externes. Pour les services avec de nombreuses connexions TCP, je prévois de courtes périodes de grâce afin que les sessions ouvertes expirent proprement ou soient rapidement réétablies.
Mettre en place IPv6 : Mettre en œuvre proprement la double pile
J'active IPv6 parallèlement à IPv4 pour que les clients puissent utiliser des Connectivité et les pare-feux font double emploi. Pour chaque interface, je définis les préfixes attribués, la route de la passerelle et je vérifie la découverte des voisins ainsi que l'attribution SLAAC ou statique. Je contrôle si les services doivent écouter sur : : et 0.0.0.0 ou si des bindings séparés sont judicieux. Des tests avec ping6, tracepath6 et curl sur des enregistrements AAAA me montrent si le DNS et le routage sont corrects. Dans les pare-feux, je reflète les règles pour IPv4 vers IPv6, afin qu'aucune faille ne reste ouverte et que je puisse utiliser le même Degré de sécurité de l'atteindre.
Sécurité : segmentation, règles, durcissement
Je segmente les réseaux par fonction, comme l'application, les données, la gestion, et je sécurise les transitions avec des règles claires. ACLs. Chaque service ne reçoit que l'accès dont il a besoin, tandis que les accès administratifs passent par des VPN ou des hôtes Bastion. Les pare-feu bloquent par défaut tout ce qui entre, puis j'autorise des ports ciblés pour les services. Je sécurise SSH avec des clés, des contrôles de port, des limites de débit et, en option, un blocage de port pour invalider les analyses. Je teste les modifications de manière contrôlée, je les documente immédiatement et, en cas de problèmes, je fais rapidement marche arrière afin que les Sécurité de fonctionnement reste élevé.
Orchestrer des pare-feux cloud et hôtes
Je combine des pare-feux en nuage avec des règles basées sur l'hôte. Les premières me donnent une couche centrale qui limite de manière fiable les accès de base, les secondes protègent les charges de travail de manière granulaire et peuvent être modulées. La cohérence est importante : les ports standard et les accès de gestion reçoivent des règles identiques dans toutes les zones. Je maintiens les politiques d'accès restrictives afin que seuls les objectifs définis soient accessibles. Pour les environnements sensibles, je mise en outre sur des hôtes Jump avec des accès de courte durée et une protection multifactorielle. Je corrige les journaux de manière centralisée afin de comprendre rapidement les blocages et de réduire les fausses alertes.
Troubleshooting : identifier rapidement les erreurs typiques
Si un serveur n'a pas de réseau après l'échange, je vérifie d'abord le nom de l'interface et j'adapte les Configuration sur le réseau. En cas de panne de routage, je réactive le renvoi IP et je contrôle les routes hôtes et la passerelle par défaut. Les fautes de frappe dans les adresses, les masques de réseau ou les liens entraînent souvent une inaccessibilité ; je compare la config et les routes réelles du noyau. En cas de problèmes de pont, je contrôle les MAC virtuels et les tables ARP pour m'assurer que les correspondances sont correctes. Les journaux sous /var/log/syslog, journalctl et dmesg me fournissent des indications sur les pilotes, les erreurs DHCP ou les blocages. Paquets.
Dépistage systématique des erreurs et diagnostic des paquets
- Contrôle de la couche : Link up, vitesse/duplex, statut VLAN/pont, puis IP/route, puis services.
- Comparaison réel/théorique : ip addr/route/rule vs. fichiers de config, consigner les écarts par écrit.
- Interception de paquets : ciblée sur l'interface et l'hôte, tenir compte du déchargement, vérifier TLS-SNI/ALPN.
- Contre-essai : tests à partir de plusieurs sources (internes/externes) afin de détecter les problèmes asymétriques.
- Capacité de retour en arrière : planifier un retour en arrière défini avant chaque modification.
Mettre en place un monitoring, une documentation et une mise à l'échelle ciblés
Je surveille la latence, la perte de paquets et la gigue à l'aide de contrôles ICMP, de contrôles de ports et d'analyses de flux, afin de pouvoir détecter rapidement les anomalies et les corriger. Tendances reconnaître les erreurs. Je sauvegarde les versions de configuration, je décris les modifications avec précision et je tiens des playbooks à disposition. Pour les enregistrements DNS et les conventions de nommage propres, je m'appuie sur l'outil compact Guide du DNSJ'ai donc besoin d'une solution cohérente pour les services. Au fur et à mesure de la croissance de la plate-forme, j'élargis les sous-réseaux, j'ajoute des équilibreurs de charge et je standardise les groupes de sécurité. Ainsi, j'évolue en toute sécurité, je limite les pannes et je conserve une vision claire de la situation. Structures.
Automatisation : Terraform, Ansible et déploiements cohérents
Je construis des réseaux reproductibles : Le nommage, les sous-réseaux, les routes, les pare-feux et les affectations de serveurs sont représentés sous forme de code. Je génère ainsi des topologies de staging et de production identiques, je teste les modifications au préalable et je réduis les erreurs de frappe. Au niveau de l'hôte, je génère des fichiers de configuration à partir de modèles et j'injecte des paramètres tels que l'IP, la passerelle, les routes et le MTU par rôle. J'utilise Cloud-init pour définir directement le réseau et les bases SSH lors du provisionnement du serveur. En cas de modifications, la règle est la suivante : d'abord valider en staging, puis mettre en production par petits lots et observer attentivement la télémétrie.
Gestion du changement et des capacités
Je planifie des fenêtres de maintenance et je définis des niveaux de repli. Chaque changement de réseau reçoit un petit plan de test avec des points de mesure avant/après le changement. Pour la capacité, je regarde le débit par zone, les charges de connexion aux passerelles et l'évolution des connexions/minute. J'ajoute rapidement des passerelles supplémentaires ou je sépare les voies de communication (est/ouest vs nord/sud) avant que des goulets d'étranglement ne se forment. Je garde la documentation vivante : Les plans IP, les esquisses de routage, les politiques de pare-feu et les responsabilités sont à jour et faciles à trouver pour l'équipe.
Comparaison des fournisseurs pour les projets nécessitant une mise en réseau intensive
J'évalue les fournisseurs en fonction de la connectivité, de l'étendue des fonctions, de la facilité d'utilisation et de la qualité des services. Flexibilité. Pour les projets avec des exigences élevées en matière de réseau, je place webhoster.de en tête en raison de ses réseaux dédiés et de ses adaptations multiples. Hetzner fournit de puissants serveurs cloud et dédiés qui conviennent très bien à de nombreux scénarios et marquent clairement des points. Strato couvre les cas d'utilisation standard, tandis que IONOS offre de bonnes options dans certains cas, mais fournit moins de marge de manœuvre pour les configurations spéciales. Cette classification m'aide à choisir la base la plus appropriée et, plus tard, à choisir le système le plus adapté. Goulots d'étranglement d'éviter.
| Place | Fournisseur | Caractéristiques du réseau | Performance |
|---|---|---|---|
| 1 | webhoster.de | Réseaux dédiés, connexion rapide, grande adaptabilité | Exceptionnel |
| 2 | Hetzner | Un cloud puissant et des serveurs dédiés | Très bon |
| 3 | Strato | Fonctions réseau standard | Bon |
| 4 | IONOS | Options haut de gamme, marge de manœuvre limitée pour les configurations personnalisées | Bon |
Kubernetes et les réseaux de conteneurs dans la pratique
Pour l'orchestration de conteneurs, je pose les bases sur le réseau. Les travailleurs ont des interfaces dans le réseau privé, le plan de contrôle est clairement segmenté et les pods à forte charge d'adresses ont un chemin NAT défini. Je choisis une CNI adaptée à la configuration : Les variantes basées sur le routage me facilitent la recherche d'erreurs et permettent d'économiser les frais généraux de superposition, les superpositions apportent souvent plus de flexibilité en matière d'isolation. Les Load Balancers découplent Ingress des backends ; les Health-Checks sont identiques à ceux de l'App, pas seulement de simples TCP-Checks. J'exploite également la double pile dans le cluster afin que les services soient proprement accessibles via les enregistrements AAAA. Pour les services stateful, je définis des politiques réseau claires (est/ouest) afin que seuls les ports nécessaires soient ouverts entre les pods. Je teste toujours les mises à jour des composants CNI et Kube dans un cluster de staging, y compris le débit, la latence et les scénarios d'échec.
Performance sous charge : optimiser de manière mesurable
Je mesure régulièrement : la latence de base à l'intérieur des zones, la latence vers les points d'accès publics, le débit de port à port, et les exigences RTO/RPO pour les services critiques. Les goulets d'étranglement apparaissent souvent en quelques points : Passerelles NAT, pare-feux stateful surchargés, tables de suivi des connexions trop petites, ou tout simplement trop peu de CPU sur les routeurs. J'augmente systématiquement la capacité, je répartis les flux, j'active les files d'attente multiples sur les NIC et je veille à l'équilibrage Pinning/IRQ lorsque cela est judicieux. Il est important d'éviter les inspections stateful inutiles sur les backbones purement est/ouest et d'y définir des ACL claires. Pour le déchargement TLS, je sépare le trafic de données du trafic de contrôle afin que les charges de travail L7 ne soient pas en concurrence avec les connexions de gestion. Je documente tout cela avec des valeurs de départ et des valeurs cibles - les optimisations ne sont "terminées" que lorsqu'elles apportent des avantages mesurables.
Bilan rapide : comment mettre en place efficacement les réseaux Hetzner
Je commence par un plan clair, je définis des espaces d'adresses, je choisis le Mode et je documente chaque étape. Ensuite, je configure les réseaux Linux de manière cohérente, j'active le renvoi IP si nécessaire et je teste minutieusement le routage et le DNS. J'intègre les IP de basculement et les MAC virtuels de manière structurée afin que les commutations se déroulent correctement. La sécurité est maintenue à un niveau élevé grâce à la segmentation, à des pare-feux puissants et à des correctifs conséquents, tandis que la surveillance permet de détecter rapidement les irrégularités. C'est ainsi que je tire profit du hetzner La configuration du réseau permet d'obtenir des performances fiables tout en conservant la flexibilité de la plateforme pour la croissance.
