Når du står overfor et spørsmål og en pause fra en stor mengde dokumentasjon, prøv å organisere og skrive ned det du lærte å huske bedre. Og lag også instruksjoner om dette problemet for ikke å gå gjennom hele banen igjen.
Kildedokumentasjon er tilgjengelig i store mengder på
Formulering av problemet
Klienten ønsker å kombinere flere leide servere til ett nettverk for å bli kvitt behovet for å betale for flere ekstra subnett, henge hele husstanden bak en ruter, tildele lokale adresser til dem og være beskyttet av en brannmur. Slik at all tjenestetrafikk kjører inne i VLAN. Pluss, flytt virtuelle maskiner fra en gammel server til en ny og forlat den, oppgrader den gamle maskinvaren du bruker og flytt samtidig til fersk Proxmox.
I utgangspunktet har klienten 5 servere, hver med et ekstra subnett, den første adressen fra det dedikerte subnettet er tilordnet den ekstra broen på Proxmox
Samtidig kjører VM-ene på Windows og har adressen 85.xx177/29 konfigurert med en gate 85.xx176
Og alle 5 serverne med sine egne virtuelle maskiner er konfigurert på lignende måte.
Det er morsomt at denne konfigurasjonen er feil i å sette opp nettverket i prinsippet; bruk nettverksadressen for den første noden og den samme for gatewayen. Hvis du prøver å kjøre denne konfigurasjonen på en virtuell maskin i Ubuntu, fungerer ikke nettverket.
implementering
- Vi lager en vSwitch i grensesnittet, tildeler en VlanID til den og legger denne vSwitch til alle serverne vi trenger.
- Vi lager en testserver slik at vi kan sette opp og flytte uten problemer.
Vi hever den første virtuelle maskinen chr med .
Hvis du bruker skriptet ovenfor, vær oppmerksom på at det først sjekker for tilstedeværelsen av -d /root/temp-katalogen, og hvis den ikke er der, opprettes /home/root/temp-katalogen, men videre arbeid utføres fortsatt ut med /root/temp-katalogen. Skriptet må korrigeres for å lage riktig katalog.
- Sette opp et nettverk for Proxmox.
Vi legger til et undergrensesnitt med et VLAN-nummer, som indikerer at adressene vil bli konfigurert på broene ved hjelp av inet-manualen. VIKTIG. Du kan ikke konfigurere IP-adresser på grensesnittene som du da vil inkludere i broen; hvordan dette vil fungere og om det vil fungere vil være ukjent for noen.
Deretter lager vi en bro vmbr0 - og legger til den første adressen til selve serveren, gitt til oss av Hetzner-leverandørene, angir broporten - det første fysiske grensesnittet uten et VLAN, og spesifiserer også tillegget med en ekstra kommando av en rute til vårt ekstra nettverk, bestilt fra Hetzner for denne serveren gjennom denne broen. Å legge til en rute vil fungere når grensesnittet går opp.
Den andre broen vil være grensesnittet vårt for lokal trafikk, vi legger til en adresse for å få tilkobling mellom forskjellige Proxmox-servere over et lokalt nettverk uten tilgang til Internett og spesifiserer porten som undergrensesnitt eno1.4000, som er allokert for vår VlanID.
Under det første oppsettet kommer du over råd om at du kan installere en ekstra ifupdown2-pakke for Proxmox, og du trenger ikke å starte hele serveren på nytt hvis det er endringer i nettverksgrensesnittene. Dette er imidlertid typisk kun for det første oppsettet, og når du bruker broer og setter opp virtuelle maskiner, støter du på problemer med nettverksfeil i virtuelle maskiner. Til tross for at du redigerte for eksempel vmbr2-grensesnittet, og når du bruker konfigurasjonen, faller nettverket av på alle interne grensesnitt og gjenopprettes ikke før serveren er fullstendig omstartet. ifdown&&ifup hjelper ikke. Hvis noen har en løsning, ville jeg vært takknemlig.
Det aller første konfigurerte grensesnittet på serveren forblir fungerende og tilgjengelig.
-
Tildeling av adresse til CHR for ikke å miste adresser fra bassenget
Poolen av adresser som Hetzner produserer ser veldig merkelig ut for en nettverksspiller, noe som dette:
Det merkelige er at porten foreslår å bruke sin egen adresse til den fysiske serveren.
Det klassiske alternativet foreslått av Hetzner selv er angitt i problemformuleringen og ble implementert av klienten uavhengig. I dette alternativet mister klienten den første adressen til nettverksadressen, den andre adressen til proxmox-broen, og det vil også være gatewayen, og den siste adressen for kringkastingen. IPv4-adresser er aldri overflødige. Hvis du prøver å registrere IP-adressen 136.x.x.177/29 og gatewayen for 0.0.0.0/0 148.x.x.165 direkte på CHR, kan du gjøre dette, men gatewayen vil ikke være Direct Connected og vil derfor være utilgjengelig. .
Vi kan komme ut av denne situasjonen ved å bruke nettverk 32 for hver adresse og spesifisere adressen vi trenger, som kan være hva som helst, som nettverksnavn. Det viser seg å være en analog av en punkt-til-punkt-forbindelse.
I dette tilfellet vil gatewayen selvfølgelig være tilgjengelig, og alt vil fungere som vi trenger.
Husk at i en slik konfigurasjon anbefales det ikke å bruke SRC-NAT-maskeraderegelen, fordi utdataadressen vil være uendelig forskjellig, og det er mer riktig å spesifisere handling: src-NAT og den spesifikke adressen du vil fra frigi klienten.
- Og endelig.
For å blokkere tilgang til selve Proxmox fra Internett, bruk de innebygde verktøyene: det er en utmerket brannmur.
Du bør ikke bruke brannmuren som tilbys av hetzner, for ikke å bli forvirret om plasseringen av innstillingene. Hetzner vil også fungere på alle nettverk, inkludert de som er etablert på CHR, og for å åpne og videresende porter vil det også være nødvendig å åpne dem i leverandørens webgrensesnitt.
Kilde: www.habr.com