Als je geconfronteerd wordt met vragen en een groot aantal documentatie doorneemt, probeer dan te systematiseren en op te schrijven wat je hebt geleerd om het beter te onthouden. Maak ook een handleiding over deze kwestie, zodat je niet telkens hetzelfde proces opnieuw hoeft te doorlopen.
De oorspronkelijke documentatie is in grote hoeveelheden beschikbaar op
Taakstelling
De klant wil verschillende gehuurde servers in Ć©Ć©n netwerk combineren om te voorkomen dat hij voor meerdere extra subnetten moet betalen, alle apparatuur achter een router te hangen, interne lokale adressen toe te wijzen en zich te beschermen met een firewall. Om ervoor te zorgen dat al het interne verkeer binnen VLAN loopt. Plus het verplaatsen van virtuele machines van een oude server naar een nieuwe, de oude server af te stoten, de gebruikte oude hardware te upgraden en tegelijkertijd te migreren naar een nieuwe Proxmox.
Aanvankelijk heeft de klant 5 servers, elk met een extra subnet, het eerste adres uit het toegewezen subnet is toegewezen aan een extra brug op Proxmox.
De VM's draaien op Windows en hebben het adres 85.x.x.177/29 ingesteld met een gateway 85.x.x.176.
En op dezelfde manier zijn alle 5 servers ingesteld met hun virtuele machines.
Grappig genoeg is deze configuratie in principe fout in de netwerkconfiguratie, omdat het netwerkadres voor de eerste node en ook als gateway wordt gebruikt. Als je zo'n configuratie probeert in te voeren op een virtuele machine in Ubuntu - werkt het netwerk niet.
ā
Implementatie
- We creƫren een vSwitch in de interface, wijzen een VlanID toe en voegen deze vSwitch toe aan alle benodigde servers.
- We maken een testserver om zonder problemen te kunnen configureren en verhuizen.
We starten de eerste virtuele machine chr op .
Als je het gegeven script gebruikt, let dan op dat aan het begin wordt gecontroleerd of de map -d /root/temp aanwezig is, en als deze niet bestaat, wordt de map /home/root/temp aangemaakt, maar de verdere werking vindt nog steeds plaats met de map /root/temp. Het script moet worden aangepast voor het creƫren van de juiste map.
- We configureren het netwerk voor Proxmox.
We voegen een subinterface met een VLAN-nummer toe en geven aan dat de adresinstellingen op de bruggen zullen plaatsvinden met inet manual. BELANGRIJK. IP-adressen mogen niet worden ingesteld op interfaces die je later in de brug gaat opnemen, hoe dit zal werken en of het Ć¼berhaupt zal werken is voor niemand bekend.
Vervolgens maken we de bridge vmbr0 aan en koppelen we het eerste adres van de server, dat ons door de provider Hetzner is toegewezen. We geven de poort van de bridge op - het eerste fysieke interface zonder VLAN, en ook met een extra commando voegen we een route toe naar ons extra netwerk dat bij Hetzner is besteld voor deze server via deze bridge. De route zal actief worden zodra het interface opgestart wordt.
De tweede bridge die we hebben, is het interface voor lokaal verkeer. We voegen hier een adres aan toe om connectiviteit tussen verschillende Proxmox-servers via het lokale netwerk zonder internettoegang te verkrijgen, en we geven de poort aan als subinterface eno1.4000, die is toegewezen voor onze VlanID.
Tijdens de initiƫle configuratie zijn er adviezen te vinden om het pakket ifupdown2 voor Proxmox te installeren, zodat je bij wijzigingen in de netwerkinterfaces de server niet volledig hoeft opnieuw te starten. Dit is echter enkel van toepassing voor de initiƫle configuratie. Bij het gebruik van bridges en het configureren van virtuele machines kun je problemen ondervinden met netwerkuitval in de virtuele machines. Zelfs als je bijvoorbeeld interface vmbr2 hebt aangepast, valt het netwerk bij het toepassen van de configuratie al op alle interne interfaces weg en komt pas weer online na een volledige reboot van de server. ifdown&&ifup helpen niet. Als iemand een oplossing heeft, zou ik dankbaar zijn.
De eerste geconfigureerde interface op de server blijft operationeel en toegankelijk.
Het toewijzen van een adres voor CHR om geen adressen uit de pool te verliezen.
De pool met adressen die Hetzner toewijst, lijkt voor een netwerker behoorlijk vreemd, ongeveer zo:
De vreemdheid is dat als gateway wordt voorgesteld om het eigen adres van de fysieke server te gebruiken.
De klassieke optie die door Hetzner zelf wordt voorgesteld, staat in de probleemstelling en is door de klant zelf uitgevoerd. In deze optie verliest de klant het eerste adres voor het netwerkadres, het tweede adres op de bridge proxmox dat ook de gateway zal zijn, en het laatste adres voor de broadcast. IPv4-adressen zijn nooit overbodig. Als je echter probeert om op CHR het IP-adres 136.x.x.177/29 en de gateway voor 0.0.0.0/0 148.x.x.165 in te voeren, zal dat mogelijk zijn, maar de gateway zal niet Direct Connected zijn en dus onbereikbaar.
Een oplossing kan zijn om een subnet van 32 te gebruiken voor elk adres en als netwerknaam het gewenste adres op te geven, dat elk adres kan zijn. Dit resulteert in een soort point-to-point verbinding.
In dit geval is de gateway uiteraard bereikbaar en zal alles werken zoals we het nodig hebben.
Houd er rekening mee dat in een dergelijke configuratie het niet wordt aanbevolen om de SRC-NAT masquerade regel te gebruiken, omdat het uitgangsadres onbepaald verschillend zal zijn. Het is beter om action: src-NAT en een specifiek adres op te geven waarvanuit je de client zult uitgeven.
- En tot slot.
Om toegang tot Proxmox vanaf het internet te blokkeren, gebruik de ingebouwde middelen: er is een uitstekende firewalls.
Gebruik geen firewall die door Hetzner wordt aangeboden, om verwarring over de configuratie-instellingen te voorkomen. Daarnaast heeft Hetzner invloed op alle netwerken, inclusief die welke zijn ingesteld op CHR, en om poorten te openen en door te sturen, moet je ook in de webinterface van de provider openen.
Bron: habr.com
