När du står inför en fråga och en paus från en stor mängd dokumentation, försök att organisera och skriva ner det du lärt dig att komma ihåg bättre. Och gör också instruktioner i denna fråga för att inte gå igenom hela vägen igen.
Källdokumentation finns i stora mängder på
Problem uttalande
Klienten vill kombinera flera hyrda servrar till ett nätverk för att bli av med behovet av att betala för flera ytterligare subnät, hänga hela sitt hushåll bakom en router, tilldela lokala adresser till dem och skyddas av en brandvägg. Så att all servicetrafik går inuti VLAN. Plus, flytta virtuella maskiner från en gammal server till en ny och överge den, uppgradera den gamla hårdvaran du använder och flytta samtidigt till nya Proxmox.
Inledningsvis har klienten 5 servrar, var och en med ett extra subnät, den första adressen från det dedikerade subnätet tilldelas den extra bryggan på Proxmox
Samtidigt körs de virtuella datorerna på Windows och har adressen 85.xx177/29 konfigurerad med en gate 85.xx176
Och alla 5 servrarna med sina egna virtuella maskiner är konfigurerade på liknande sätt.
Det är lustigt att den här konfigurationen är felaktig när det gäller att sätta upp nätverket i princip, använd nätverksadressen för den första noden och samma för gatewayen. Om du försöker köra den här konfigurationen på en virtuell maskin i Ubuntu fungerar inte nätverket.
genomförande
- Vi skapar en vSwitch i gränssnittet, tilldelar den ett VlanID och lägger till denna vSwitch till alla servrar vi behöver.
- Vi gör en testserver så att vi kan ställa in och flytta utan problem.
Vi höjer den första virtuella maskinen chr med .
Om du använder skriptet ovan, observera att det först kontrollerar förekomsten av -d /root/temp-katalogen, och om den inte finns där skapas /home/root/temp-katalogen, men ytterligare arbete utförs fortfarande ut med katalogen /root/temp. Skriptet måste korrigeras för att skapa rätt katalog.
- Konfigurera ett nätverk för Proxmox.
Vi lägger till ett undergränssnitt med ett VLAN-nummer, vilket indikerar att adresserna kommer att konfigureras på bryggorna med hjälp av inet-manualen. VIKTIG. Du kan inte konfigurera IP-adresser på gränssnitten som du sedan ska inkludera i bryggan, hur detta kommer att fungera och om det kommer att fungera kommer att vara okänt för någon.
Därefter skapar vi en brygga vmbr0 - och bifogar den första adressen till själva servern, som ges till oss av Hetzner-leverantörerna, anger bryggporten - det första fysiska gränssnittet utan ett VLAN, och anger även med ett extra kommando tillägget av en rutt till vårt ytterligare nätverk, beställd från Hetzner för denna server genom denna brygga. Att lägga till en rutt fungerar när gränssnittet går upp.
Den andra bryggan kommer att vara vårt gränssnitt för lokal trafik, vi lägger till en adress till den för att erhålla anslutning mellan olika Proxmox-servrar över ett lokalt nätverk utan tillgång till Internet och anger porten som undergränssnitt eno1.4000, som är allokerad för vårt VlanID.
Under den första installationen får du råd om att du kan installera ytterligare ett ifupdown2-paket för Proxmox och att du inte behöver starta om hela servern om det sker förändringar i nätverksgränssnitten. Detta är dock typiskt endast för den initiala installationen, och när du använder bryggor och konfigurerar virtuella maskiner, stöter du på problem med nätverksfel i virtuella maskiner. Trots att du redigerade till exempel vmbr2-gränssnittet, och när du tillämpar konfigurationen, faller nätverket av på alla interna gränssnitt och återställs inte förrän servern är helt omstartad. ifdown&&ifup hjälper inte. Om någon har en lösning vore jag tacksam.
Det allra första konfigurerade gränssnittet på servern förblir fungerande och tillgängligt.
-
Tilldelning av en adress för CHR för att inte tappa adresser från poolen
Den pool av adresser som Hetzner producerar ser väldigt märklig ut för en nätverkare, ungefär så här:
Det konstiga är att porten föreslår att man använder sin egen adress till den fysiska servern.
Det klassiska alternativet som föreslås av Hetzner själv anges i problembeskrivningen och implementerades av klienten självständigt. I det här alternativet förlorar klienten den första adressen till nätverksadressen, den andra adressen till proxmox-bryggan och det kommer också att vara gatewayen och den sista adressen för sändningen. IPv4-adresser är aldrig redundanta. Om du direkt försöker registrera IP-adressen 136.x.x.177/29 och gatewayen för 0.0.0.0/0 148.x.x.165 på CHR kan du göra detta, men gatewayen kommer inte att vara direktansluten och kommer därför att vara oåtkomlig .
Vi kan ta oss ur den här situationen genom att använda nätverk 32 för varje adress och specificera adressen vi behöver, vilket kan vara vad som helst, som nätverksnamn. Det visar sig vara en analog till en punkt-till-punkt-förbindelse.
I det här fallet kommer gatewayen givetvis att vara tillgänglig, och allt kommer att fungera som vi behöver.
Tänk på att i en sådan konfiguration rekommenderas det inte att använda SRC-NAT-maskeringsregeln, eftersom utdataadressen kommer att vara oändlig obestämd, och det är mer korrekt att ange åtgärd: src-NAT och den specifika adress från vilken du kommer att släppa klienten.
- Och slutligen.
För att blockera åtkomst till själva Proxmox från Internet, använd de inbyggda verktygen: det finns en utmärkt brandvägg.
Du bör inte använda brandväggen som erbjuds av hetzner, för att inte bli förvirrad över var inställningarna finns. Hetzner kommer också att fungera på alla nätverk, inklusive de som är etablerade på CHR, och för att öppna och vidarebefordra portar kommer det också att vara nödvändigt att öppna dem i leverantörens webbgränssnitt.
Källa: will.com