Når du står over for spørgsmål og gennemgår en stor mængde dokumentation, så prøv at systematisere og nedskrive det, du har lært, så du bedre kan huske det. Lav også en instruktion om dette emne, så du ikke skal gennemgå hele processen igen.
Den oprindelige dokumentation findes i stort omfang på
Problemformulering
Klienten ønsker at samle flere lejede servere i et netværk for at undgå at betale for flere ekstra undernet, tilslutte alt sit udstyr til en router, tildele dem lokale adresser internt, og beskytte dem med en firewall. Så hele serverkommunikationen kører inden for VLAN. Plus at flytte virtuelle maskiner fra en gammel server til en ny og opgive den gamle, opgradere det brugte gamle hardware og samtidig skifte til en ny Proxmox.
Klienten har oprindeligt 5 servere, hvor hver enkelt har et ekstra undernet, den første adresse fra det tildelte undernet er tildelt en ekstra bro på Proxmox.
VM'erne kører på Windows og har tildelt adressen 85.x.x.177/29 med gateway 85.x.x.176.
Alle 5 servere med deres virtuelle maskiner er opsat på lignende måde.
Det er sjovt, at denne konfiguration er fejlagtig i netværksindstillingerne i princippet; at bruge netværksadressen til den første node, som også er gateway. Hvis man forsøger at implementere en sådan konfiguration på en virtuel maskine i Ubuntu, fungerer netværket ikke.
Implementering
- Opretter en vSwitch i grænsefladen, tildeler VlanID til den, og tilføjer denne vSwitch til alle de servere, vi har brug for.
- Vi laver en testserver, så vi kan konfigurere og flytte uden problemer.
Vi starter med den første virtuelle maskine chr i .
Hvis du bruger det angivne script, bemærk venligst, at der i begyndelsen kontrolleres for eksistensen af mappen -d /root/temp, og hvis den ikke findes, oprettes mappen /home/root/temp, men arbejdet fortsætter alligevel med mappen /root/temp. Scriptet skal rettes, så den korrekte mappe oprettes.
- Vi konfigurerer netværket til Proxmox.
Vi tilføjer en subinterface med VLAN-nummeret og angiver, at konfigurationen af adresser vil finde sted på broer ved hjælp af inet manual. VIGTIGT. Du må ikke sætte IP-adresser på de interfaces, som du senere vil inkludere i en bro, da det jo ikke er klart, hvordan det vil fungere, eller om det overhovedet vil fungere.
Derefter opretter vi broen vmbr0 og knytter den første adresse, som er tildelt os af udbyderen Hetzner, til broen. Vi angiver porten til broen – den første fysiske interface uden VLAN, samt tilføjer en rute til vores ekstra netværk, som er bestilt fra Hetzner for denne server via denne bro. Tilføjelsen af ruten træder i kraft, når interfacet aktiveres.
Den anden bro vil være vores interface til lokal trafik, vi tilføjer en adresse for at sikre forbindelse mellem forskellige Proxmox-servere i det lokale netværk uden at gå på internettet, og angiver subinterfacet eno1.4000 som port, der er tildelt vores VlanID.
Når man indstiller systemet første gang, er der råd om, at man kan installere pakken ifupdown2 til Proxmox, så man ikke behøver at genstarte serveren ved ændringer i netværksinterfacene. Men dette gælder kun for den indledende opsætning, og ved brug af broer og opsætning af virtuelle maskiner, støder man på problemer med netværksforbindelse i de virtuelle maskiner. Givet at du for eksempel har rettet interfacet vmbr2, taber netværket forbindelsen for alle interne interfacet, og det kommer ikke op igen før serveren genstartes fuldstændigt. ifdown&&ifup hjælper ikke. Hvis nogen har en løsning – vil jeg være taknemmelig.
Det første konfigurerede interface på serveren forbliver aktivt og tilgængeligt.
Tildeling af en adresse til CHR for ikke at miste adresser fra puljen.
Puljen af adresser, som Hetzner tildeler, ser for netværksteknikeren meget underlig ud, omtrent sådan her:
Underligheden er, at der foreslås at bruge den fysiske servers egen adresse som gateway.
Den klassiske løsning, der foreslås af Hetzner selv, er beskrevet i problemstillingen og blev gennemført af kunden selv. I denne løsning mister kunden den første adresse til netværket, den anden adresse til broen proxmox, som også vil fungere som gateway, og den sidste adresse til broadcast. IPv4-adresser er aldrig overflødige. Hvis du prøver at angive IP-adressen 136.x.x.177/29 direkte på CHR og gateway for 0.0.0.0/0 148.x.x.165, kan du gøre det, men gateway vil ikke være Direct Connected og derfor vil være utilgængelig.
Man kan løse det ved at bruge 32-netværk på hver adresse og angive den ønskede adresse som netværksnavn, hvilket kan være vilkårligt. Det svarer til en point-to-point forbindelse.
I dette tilfælde vil gatewayen naturligvis være tilgængelig, og alt vil fungere, som vi har brug for.
Vær opmærksom på, at det i en sådan konfiguration ikke anbefales at bruge SRC-NAT masquerade-reglen, fordi den udgående adresse vil være ubestemt forskellig, og det er mere korrekt at angive action: src-NAT og den specifikke adresse, som du vil frigive klienten fra.
- Og til sidst.
For at blokere adgangen til selve Proxmox fra internettet, skal du bruge de indbyggede værktøjer: der er en fremragende firewall.
Det er ikke en god idé at bruge den firewall, som Hetzner tilbyder, for ikke at blive forvirret over placeringen af indstillingerne. Hetzner vil også påvirke alle netværk, herunder dem, der er tilknyttet CHR, og for at åbne og viderekoble porte skal du også åbne dem i webgrænsefladen hos udbyderen.
Kilde: habr.com
