Hoppa till innehåll 
Jag ska visa dig hur du kan hetzner-nätverket och konfigurera den på rätt sätt för att öka prestanda, säkerhet och skalbarhet på ett målinriktat sätt. Jag tar ett praktiskt grepp: från molnpanelen och routingvarianter till failover-IP:er, virtuella MAC:er, IPv6, säkerhet, feldiagnostik och övervakning.
Centrala punkter
- Adressutrymme välj: Använd RFC 1918 rent, planera rena subnät.
- Läge bestämma: Routed, Bridge eller vSwitch beroende på tillämpning.
- Linux-Setup: ifupdown, netplan, systemd-networkd hålla konsekvent.
- Failover & MAC: Tilldela virtuella MAC korrekt, ställ in värdvägar.
- Säkerhet & Övervakning: Etablera segmentering, brandväggar, loggar och kontroller.
Grunderna i Hetzners nätverkskonfiguration
Korrekt planering förebygger senare utgifter och ger konkreta fördelar. Prestanda. Jag separerar interna system i ett separat molnnätverk, isolerar känsliga komponenter och håller den publika attackvektorn liten, vilket minimerar Säkerhet ökat betydligt. Privata nätverk i Hetzner Cloud ger mig detaljerad kontroll, tydliga vägar för dataflöden och mindre broadcast-brus. Jag definierar tidigt vilka servrar som behöver publika adresser och vilka som bara talar internt, så att routning, brandväggar och IP-allokering förblir logiska. Denna tydlighet lönar sig så snart failover, lastbalanserare eller containerorkestrering kommer in i bilden och jag måste hantera flera servrar. Undernät tydligt organiserad.
Hetzner Cloud-Panel: Skapa nätverk och välj adressutrymme
I molnpanelen skapar jag ett nytt nätverk, tilldelar ett unikt namn per projekt och väljer ett RFC 1918-adressintervall som 10.0.0.0/8, 172.16.0.0/12 eller 192.168.0.0/16 som IP-block. Jag planerar subnät i ett tidigt skede, till exempel /24 för applager, /28 för administrationsåtkomst eller /26 för databaser, så att tillväxten förblir rent kartlagd. Sedan integrerar jag servrar, lastbalanserare och ytterligare tjänster så att kommunikationen kan upprättas omedelbart. För nykomlingar på plattformen tillhandahåller jag gärna den kompakta Översikt över molnserversom sammanfattar de viktigaste alternativen. Så snart nätverket är klart testar jag den grundläggande tillgängligheten och kontrollerar säkerhetsgrupperna så att inga onödiga portar lämnas öppna och att min Brandvägg-reglerna gäller.
Subnätdesign och IP-planering i detalj
Jag arbetar med tydliga namngivnings- och numreringskonventioner så att jag senare intuitivt kan känna igen subnät. Varje zon (t.ex. app, db, mgmt, edge) får ett fast nummerintervall och en dokumenterad standardstorlek. Jag reserverar medvetet buffertområden mellan subnät för att möjliggöra utvidgningar utan omnumrering. När tjänsterna skalas horisontellt föredrar jag att planera flera /25 eller /26 i stället för en stor /22; detta håller ACL:er och rutter smala. Jag har en separat hantering /28 för adminåtkomst, som jag konsekvent härdar och gör tillgänglig via VPN eller bastionsvärdar. När jag ansluter externa platser definierar jag tydliga, icke-överlappande områden redan från början och ställer in statiska rutter specifikt så att det inte finns några konflikter.
Routed, Bridge eller vSwitch: rätt läge
Jag fokuserar på tre huvudvarianter: Ruttad för ytterligare subnät och failover-adresser, bridge om gästerna ska fungera som sina egna servrar och vSwitch för flexibla konfigurationer och NAT. Med den routade modellen kopplas ytterligare adresser till värdens huvud-MAC; jag aktiverar IP-forwarding för IPv4 och IPv6 och ställer in värdvägar till gatewayen. Med Bridge behöver gästerna en synlig MAC i nätverket; jag ansöker om en virtuell MAC för varje tilldelad IP och länkar den till gästen. Jag kombinerar vSwitch med masquerading så att virtuella datorer med privata adresser kan komma åt Internet medan interna tjänster förblir skyddade. Detta val styr senare insatser, Öppenhet och feltolerans i min plattform.
| Läge | Användning | Förkunskapskrav | Fördelar | Risker för att snubbla |
|---|---|---|---|---|
| Ruttad | Ytterligare subnät, failover-IP:er | IP-videresändning, värdväg | Tydlig routing, bra Skalning | Underhålla gateway/host-rutten på ett snyggt sätt |
| Bro | Gäster som "egna servrar" | Virtuell MAC per IP | Verklig synlighet per gäst | MAC-hantering i Robot nödvändigt |
| vSwitch + NAT | Privata virtuella datorer med internet | Maskerad, Brandvägg | Hög invändig isolering | Underhåll NAT-reglerna på rätt sätt |
Hybridkonfigurationer: moln, dedikerade och övergångar
I hybridmiljöer ansluter jag molnnätverk till dedikerade servrar via explicita routerinstanser. Ett tydligt definierat transit-subnät och statiska rutter säkerställer att båda sidor bara ser de prefix som krävs. Beroende på säkerhetskraven låter jag trafiken passera genom en edge-instans via NAT eller routar subnät transparent. Det är viktigt att gatewayen är utformad för hög tillgänglighet - till exempel med två router-VM:er som kontrollerar varandras status och tar över sömlöst i händelse av ett fel. Jag har också en checklista redo: korrekta routers i molnpanelen, aktiv forwarding, konsekventa brandväggsstatusar och hälsokontroller som inte bara kontrollerar ICMP utan även relevanta portar.
Linux-installation: korrekt användning av ifupdown, netplan och systemd-networkd
Under Debian/Ubuntu med ifupdown lagrar jag konfigurationen i /etc/network/interfaces eller under /etc/network/interfaces.d och behåller Host-väg korrekt. För värd-IP-adressering använder jag /32 (255.255.255.255) och ställer in gatewayen som pointopoint så att kärnan känner till grannen. Under netplan (Ubuntu 18.04, 20.04, 22.04) definierar jag adresser, rutter och on-link så att standardrutten matchar omedelbart. Om jag byter hårdvara kontrollerar jag gränssnittsbeteckningen och ändrar den från eth0 till enp7s0, till exempel, så att nätverkskortet kommer upp igen. För systemd-networkd hanterar jag .network- och .netdev-filer, laddar om tjänsterna och testar sedan alltid DNS, routing och Anslutningsmöjligheter.
Nätverksanpassning: MTU, avlastning, policy-routning
Jag kontrollerar MTU:n från början till slut, särskilt när VPN, overlays eller tunnlar är inblandade. Om värdena inte är korrekta uppstår fragmentering eller avbrott. Jag aktiverar TCP MTU-probing på gateways och sätter MSS clamps på lämpliga ställen för att hålla anslutningarna robusta. Jag använder avlastningsfunktioner (GRO/LRO/TSO) medvetet: jag avaktiverar dem delvis på hypervisorer eller för paketinspelning, men låter dem vara på för rena datavägar - beroende på de uppmätta värdena. Om jag har flera upstreams eller differentierade egress-policyer använder jag policybaserad routing med mina egna routing-tabeller och ip-regler. Jag dokumenterar varje specialregel så att senare ändringar inte utlöser obemärkta bieffekter.
Failover-IP:er, virtuella MAC:er och lastbalanserare i praktiken
För ytterligare IP-adresser ansöker jag i Hetzner Robot per adress en virtuell MAC och tilldelar dem till gästen så att ARP fungerar korrekt. I den routade installationen ligger huvud-MAC:en kvar på värden och jag routar subnät explicit till gästen. I bryggscenarier får gästen sin egen synliga MAC, så att den fungerar som en oberoende server. För failover definierar jag vilken maskin som för närvarande meddelar IP: n; vid byte justerar jag routingen och, om det behövs, gratuity ARP så att trafiken kommer fram omedelbart. Jag använder lastbalanserare för att frikoppla frontend-trafiken från backend-systemen, säkerställa en jämn fördelning och därmed öka Tillgänglighet.
Ren design av IP-omkopplingar
Jag förlitar mig på tydliga mekanismer för aktiva omkopplingar: antingen meddelar den aktiva instansen en IP via ARP/NDP och den passiva förblir tyst, eller så drar jag specifikt standardrutten till den nya aktiva maskinen. Verktyg som VRRP-implementeringar hjälper till, men jag testar alltid hela interaktionen, inklusive brandväggar, granncacher och eventuella ARP-tidsramar. Viktigt: Efter bytet kontrollerar jag tillgängligheten både från det interna nätverket och från externa kontrollpunkter. För tjänster med många TCP-anslutningar schemalägger jag korta grace-perioder så att öppna sessioner löper ut på ett snyggt sätt eller snabbt återupprättas.
Ställ in IPv6: Implementera dual stack på ett snyggt sätt
Jag aktiverar IPv6 parallellt med IPv4 så att kunderna kan använda moderna Anslutningsmöjligheter och brandväggar är duplicerade. För varje gränssnitt ställer jag in de tilldelade prefixen, gateway-rutten och kontrollerar grannupptäckt och SLAAC eller statisk tilldelning. Jag kontrollerar om tjänster ska lyssna på :: och 0.0.0.0 eller om det är vettigt med separata bindningar. Tester med ping6, tracepath6 och curl via AAAA-poster visar mig om DNS och routing är korrekta. I brandväggar speglar jag regler för IPv4 till IPv6 så att inga luckor förblir öppna och jag kan använda samma Säkerhetsnivå räckvidd.
Säkerhet: segmentering, regler, härdning
Jag segmenterar nätverk efter funktion, t.ex. app, data, hantering och säkra övergångar med tydliga ACL:er. Varje avdelning får bara den åtkomst den behöver, medan adminåtkomst körs via VPN eller bastionsvärdar. Brandväggar blockerar all inkommande trafik som standard, sedan tillåter jag specifika portar för tjänster. Jag säkrar SSH med nycklar, portkontroller, hastighetsbegränsningar och valfri portknackning för att ogiltigförklara skanningar. Jag testar förändringar på ett kontrollerat sätt, dokumenterar dem omedelbart och rullar snabbt tillbaka om problem uppstår så att Operativ säkerhet är fortsatt hög.
Orchestrera brandväggar för moln och värdar
Jag kombinerar brandväggar i molnet med värdbaserade regler. De förstnämnda ger mig ett centralt lager som på ett tillförlitligt sätt begränsar grundläggande åtkomst, medan de sistnämnda skyddar arbetsbelastningar på detaljnivå och kan tematiseras. Konsistens är viktigt: standardportar och hanteringsåtkomst får identiska regler i alla zoner. Jag har restriktiva regler för utpassering så att endast definierade mål kan nås. För känsliga miljöer använder jag även jump hosts med kortvarig åtkomst och multifaktorskydd. Jag korrelerar loggar centralt för att snabbt kunna förstå blockeringar och minska antalet falsklarm.
Felsökning: identifiera typiska fel snabbt
Om en server inte har något nätverk efter ett byte, kontrollerar jag först gränssnittsnamnet och justerar Konfiguration på. Om routningen misslyckas återaktiverar jag IP-vidarebefordran och kontrollerar värdvägar och standardgateway. Skrivfel i adresser, nätmasker eller on-link leder ofta till att det inte går att nå; jag jämför konfigurationen och de faktiska kernel-routarna. Vid bryggproblem kontrollerar jag virtuella MAC- och ARP-tabeller för att säkerställa att mappningarna är korrekta. Loggar under /var/log/syslog, journalctl och dmesg ger mig information om drivrutiner, DHCP-fel eller blockerade Paket.
Systematisk felsökning och paketdiagnostik
- Layer check: Länk upp, hastighet/duplex, VLAN/bridge-status, sedan IP/route, sedan tjänster.
- Jämförelse faktiskt/mål: ip-adress/väg/regel vs. konfigurationsfiler, notera avvikelser skriftligen.
- Paketinspelning: riktad mot gränssnitt och värd, observera avlastning, kontrollera TLS-SNI/ALPN.
- Cross-check: Tester från flera källor (interna/externa) för att upptäcka asymmetriska problem.
- Rollback-kapacitet: Planera en definierad returväg före varje förändring.
Riktad övervakning, dokumentation och skalning
Jag övervakar latens, paketförlust och jitter med ICMP-kontroller, portkontroller och flödesanalyser så att jag kan upptäcka avvikelser tidigt och Trender känner igen sig. Jag säkerhetskopierar versioner av konfigurationsstatusar, beskriver ändringar med exakt precision och håller spelböcker redo. För DNS-poster och rena namngivningskonventioner använder jag den kompakta DNS-guideså att tjänsterna förblir konsekvent lösningsbara. I takt med att plattformen växer utökar jag subnäten, lägger till fler lastbalanserare och standardiserar säkerhetsgrupperna. På så sätt kan jag skala på ett säkert sätt, minimera avbrott och upprätthålla tydliga säkerhetsstandarder. Strukturer.
Automation: Terraform, Ansible och konsekventa utrullningar
Jag bygger reproducerbara nätverk: Namngivning, subnät, rutter, brandväggar och servertilldelningar mappas som kod. Detta gör att jag kan skapa identiska topologier för staging och produktion, testa ändringar i förväg och minska antalet skrivfel. På värdnivå genererar jag konfigurationsfiler från mallar och injicerar parametrar som IP, gateway, rutter och MTU per roll. Jag använder Cloud-init för att ställa in nätverk och SSH-grunderna direkt under serverprovisioneringen. När jag gör ändringar validerar jag dem först i staging, sedan går jag live i små satser och håller ett öga på telemetrin.
Förändrings- och kapacitetshantering
Jag planerar underhållsfönster och definierar reservnivåer. Varje nätverksförändring får en liten testplan med mätpunkter före/efter förändringen. För kapacitet tittar jag på genomströmning per zon, anslutningsbelastning vid gateways och utvecklingen av anslutningar/minut. Jag lägger till ytterligare gateways i ett tidigt skede eller separerar trafikleder (öst/väst jämfört med nord/syd) innan flaskhalsar uppstår. Jag håller dokumentationen uppdaterad: IP-planer, routingskisser, brandväggspolicyer och ansvarsområden är uppdaterade och lätta för teamet att hitta.
Jämförelse av leverantörer för nätverksintensiva projekt
Jag utvärderar leverantörer utifrån anslutning, funktionsutbud, användarvänlighet och Flexibilitet. För projekt med höga nätverkskrav sätter jag webhoster.de i topp på grund av dess dedikerade nätverk och mångsidiga anpassning. Hetzner tillhandahåller kraftfulla molnservrar och dedikerade servrar som är mycket väl lämpade för många scenarier och får höga poäng. Strato täcker standardanvändningsfall, medan IONOS erbjuder bra alternativ i vissa fall, men ger mindre spelrum för speciella inställningar. Den här kategoriseringen hjälper mig att välja rätt grund och att fatta senare beslut. Flaskhalsar som ska undvikas.
| Plats | Leverantör | Funktioner i nätverket | Effekt |
|---|---|---|---|
| 1 | webhoster.de | Dedikerade nätverk, snabb uppkoppling, hög anpassningsbarhet | Utestående |
| 2 | Hetzner | Kraftfulla molnservrar och dedikerade servrar | Mycket bra |
| 3 | Strato | Standardfunktioner för nätverk | Bra |
| 4 | IONOS | Högklassiga alternativ, begränsat utrymme för specialinredningar | Bra |
Kubernetes och containernätverk i praktiken
För containerorkestrering lägger jag grunden i nätverket. Medarbetarna får gränssnitt i det privata nätverket, kontrollplanet är tydligt segmenterat och kapslar med många utgångar får en definierad NAT-väg. Jag väljer en CNI som passar installationen: Routing-baserade varianter gör felsökningen enklare för mig och sparar overlay-overhead, medan overlays ofta ger mer flexibilitet när det gäller isolering. Lastbalanserare frikopplar Ingress från backends; hälsokontrollerna är identiska med appens, inte bara enkla TCP-kontroller. Jag kör också dubbla stackar i klustret så att tjänster kan nås på ett rent sätt via AAAA-poster. För stateful-tjänster definierar jag tydliga nätverkspolicyer (öst/väst) så att endast de nödvändiga portarna mellan pods är öppna. Jag testar alltid uppdateringar av CNI- och Kube-komponenter i ett staging-kluster, inklusive genomströmning, latens och felscenarier.
Prestanda under belastning: mätbar optimering
Jag mäter regelbundet: baslinjelatens inom zoner, latens till offentliga slutpunkter, genomströmning port-till-port och RTO/RPO-krav för kritiska tjänster. Flaskhalsar uppstår ofta vid ett fåtal punkter: NAT-gateways, överbelastade stateful-brandväggar, för små tabeller för anslutningsspårning eller helt enkelt för lite CPU på routrarna. Jag ökar systematiskt kapaciteten, distribuerar flöden, aktiverar multiköer på nätverkskort och ser till att pinning/IRQ-balanseras där det är lämpligt. Det är viktigt att undvika onödig stateful inspection på rena öst/väst-backbones och istället sätta tydliga ACL:er där. För TLS-avlastning separerar jag datatrafik från kontrolltrafik så att L7-arbetsbelastningar inte konkurrerar med hanteringsanslutningar. Jag dokumenterar allt detta med start- och målvärden - optimeringar är "färdiga" först när de ger mätbara fördelar.
Kort sammanfattning: Så här sätter du upp Hetzner-nätverk på ett effektivt sätt
Jag börjar med en tydlig plan, definierar adressytor, väljer lämpliga Läge och dokumenterar varje steg. Sedan konfigurerar jag Linux-nätverk på ett konsekvent sätt, aktiverar IP-vidarebefordran om det behövs och testar routing och DNS noggrant. Jag integrerar failover-IP:er och virtuella MAC:ar på ett strukturerat sätt så att omkopplingar fungerar smidigt. Säkerheten förblir hög tack vare segmentering, starka brandväggar och konsekvent patchning, samtidigt som övervakningen avslöjar oegentligheter i ett tidigt skede. Det är så här jag får Hetzner nätverkskonfigurationen levererar tillförlitlig prestanda samtidigt som plattformen är flexibel för tillväxt.
