Når du står over for et spørgsmål og bryd en stor mængde dokumentation, så prøv at systematisere og skrive ned, hvad du har lært for at huske bedre. Og lav også instruktioner om dette spørgsmål, for ikke at gå hele vejen igen.
Kildedokumentation er rigeligt kl
Formulering af problemet
Klienten ønsker at kombinere flere lejede servere i ét netværk for at slippe af med behovet for at betale for flere ekstra undernet, hænge hele sin husstand bag en router, tildele lokale adresser til dem indeni og beskytte sig selv med en firewall. Så al servicetrafik kører inde i VLAN. Plus, overfør virtuelle maskiner fra en gammel server til en ny og afvis det, opgrader den brugte gamle hardware og flyt samtidig til frisk Proxmox.
Til at begynde med har klienten 5 servere, hver med et ekstra undernet, den første adresse fra det tildelte undernet er tildelt en ekstra bro på Proxmox
Samtidig kører VM'er på Windows og har adressen 85.xx177/29 konfigureret med en gate 85.xx176
Og på samme måde er alle 5 servere konfigureret med deres virtuelle maskiner.
Det er sjovt at denne konfiguration er forkert i opsætningen af netværket i princippet, brug netværksadressen til den første node og den er også til gatewayen. Hvis du forsøger at starte en sådan konfiguration på en virtuel maskine i Ubuntu, virker netværket ikke.
implementering
- Vi opretter en vSwitch i grænsefladen, tildeler den et VlanID, tilføjer denne vSwitch til alle de servere, vi har brug for.
- Vi laver en testserver, så du kan opsætte og flytte uden problemer.
Vi hæver den første virtuelle maskine chr ved .
Hvis du bruger ovenstående script, skal du være opmærksom på, at -d /root/temp-mappen er markeret i begyndelsen, og hvis den ikke er der, oprettes mappen /home/root/temp, men der arbejdes stadig med mappen /root/temp. Scriptet skal rettes for at oprette den passende mappe.
- Opsætning af netværk til Proxmox.
Vi tilføjer en undergrænseflade med VLAN-nummeret, angiver, at adresseindstillingerne vil forekomme på broerne ved hjælp af inet-manualen. VIGTIG. Du kan ikke konfigurere IP-adresser på grænseflader, som du så vil inkludere i broen, hvordan det vil fungere, og om ingen overhovedet ved det.
Dernæst opretter vi en vmbr0-bro - og vi hænger den første adresse på selve serveren, givet til os af Hetzner-udbydere, specificerer broporten - den første fysiske grænseflade uden VLAN, og specificerer også med en ekstra kommando for at tilføje en rute til vores ekstra netværk bestilt fra Hetzner til denne server gennem denne bro. Tilføjelse af en rute fungerer, når grænsefladen kommer op.
Den anden bro vil være vores grænseflade til lokal trafik, tilføje en adresse til den for at få forbindelse mellem forskellige Proxmox-servere over et lokalt netværk uden adgang til internettet og angive eno1.4000-undergrænsefladen, som er allokeret til vores VlanID, som porten .
Under den indledende opsætning er der tips om, at du kan installere en ekstra ifupdown2-pakke til Proxmox, og du kan ikke genstarte hele serveren ved ændringer i netværksgrænseflader. Dette er dog kun typisk for den indledende opsætning, og når du bruger broer og opsætter virtuelle maskiner, støder du på problemer med netværksfejl i virtuelle maskiner. På trods af det faktum, at du for eksempel regerede vmbr2-grænsefladen, og når du anvender konfigurationen, falder netværket allerede af på alle interne grænseflader og stiger ikke, før serveren er fuldstændig genstartet. ifdown&&ifup hjælper ikke. Hvis nogen har en løsning, vil jeg være taknemmelig.
Den første konfigurerede grænseflade på selve serveren forbliver operationel og tilgængelig.
-
Adressetildeling til CHR for ikke at miste adresser fra puljen
Adressepuljen, som Hetzner giver ud, ser meget mærkelig ud for en netværker, noget som dette:
Det mærkelige er, at porten foreslås at bruge sin egen adresse på den fysiske server.
Den klassiske version foreslået af Hetzner selv er angivet i problemformuleringen og blev implementeret af klienten uafhængigt. I denne mulighed mister klienten den første adresse til netværksadressen, den anden adresse til proxmox-broen, og det vil også være gatewayen og den sidste adresse til udsendelse. IPv4-adresser er aldrig overflødige. Hvis du direkte forsøger at registrere CHR IP-adressen 136.х.х.177/29 og gatewayen for 0.0.0.0/0 148.х.х.165, så kan du gøre det, men gatewayen vil ikke være direkte forbundet og vil derfor være uopnåelig.
Du kan komme ud af situationen, hvis du bruger 32 netværk til hver adresse og angiver den adresse, vi skal bruge som netværksnavn, hvilket kan være hvad som helst. Det viser sig at være en analog af en punkt-til-punkt-forbindelse.
I dette tilfælde vil gatewayen naturligvis være tilgængelig, og alt vil fungere som vi har brug for.
Husk, at i en sådan konfiguration anbefales det ikke at bruge SRC-NAT-maskereglen, fordi outputadressen vil være uendeligt anderledes, men det er mere korrekt at angive handling: src-NAT og den specifikke adresse, hvorfra du vil frigive klienten.
- Og endelig.
For at blokere adgangen til selve Proxmox fra internettet skal du bruge de indbyggede værktøjer: der er en fremragende firewall.
Du bør ikke bruge den firewall, der tilbydes af hetzner, for ikke at blive forvirret over placeringen af indstillingerne. Hetzner vil også agere på alle netværk, også dem der er etableret på CHR, og for at åbne og videresende porte vil det også være nødvendigt at åbne det i udbyderens webgrænseflade.
Kilde: www.habr.com