Gdy napotkasz pytanie i przestudiujesz dużą ilość dokumentacji, postaraj się systematyzować oraz zapisać to, co się nauczyłeś, aby lepiej zapamiętać. Zrób również instrukcję dotyczącą tego zagadnienia, aby nie przechodzić przez całą tę drogę ponownie.
Dokumentacja źródłowa jest dostępna w dużej ilości na
Sformułowanie zadania
Klient chce połączyć kilka wynajmowanych serwerów w jedną sieć, aby uniknąć opłat za kilka dodatkowych podsieci, podłączyć całe swoje urządzenie do routera, przypisać im wewnętrzne adresy lokalne i zabezpieczyć się zaporą. Wszystkie usługi będą biegały wewnątrz VLAN. Dodatkowo, klient chce przenieść maszyny wirtualne z jednego starego serwera na nowy, zrezygnować z tamtego, zaktualizować stare sprzęty i jednocześnie przenieść się na nowy Proxmox.
Na początku klient ma 5 serwerów, z każdą dodatkową podsiecią, pierwszy adres z przydzielonej podsieci jest przypisany do dodatkowego mostka na Proxmox.
VM-y działają na Windowsie i mają skonfigurowany adres 85.x.x.177/29 z bramą 85.x.x.176.
W podobny sposób skonfigurowano wszystkie 5 serwerów z własnymi maszynami wirtualnymi.
Zabawne jest to, że ta konfiguracja jest zasadniczo błędna w ustawieniach sieci, używając adresu sieci do pierwszego węzła, który również służy jako brama. Jeśli spróbujesz wprowadzić taką konfigurację na maszynie wirtualnej w Ubuntu, sieć nie będzie działać.
Realizacja
- Tworzymy vSwitch w interfejsie, przypisujemy do niego VlanID, dodajemy ten vSwitch do wszystkich potrzebnych serwerów.
- Tworzymy serwer testowy, aby można było go skonfigurować i przenieść bez problemów.
Uruchamiamy pierwszą maszynę wirtualną chr według .
Jeśli korzystasz z przedstawionego skryptu, zwróć uwagę, że na początku sprawdzana jest obecność katalogu -d /root/temp, a jeśli go nie ma, to tworzony jest katalog /home/root/temp, jednak dalsza praca odbywa się z katalogiem /root/temp. Skrypt należy poprawić, aby utworzył odpowiedni katalog.
- Konfigurujemy sieć dla Proxmox.
Dodajemy subinterfejs z numerem VLAN, wskazujemy, że adresy będą konfigurowane na mostkach z użyciem inet manual. WAŻNE. Nie wolno konfigurować adresów IP na interfejsach, które później zostaną włączone do mostka, nie wiadomo, jak to będzie działać i czy w ogóle.
Następnie tworzymy mostek vmbr0 i przypisujemy mu pierwszy adres serwera, przydzielony nam przez dostawcę Hetzner, wskazujemy port mostka – pierwszy fizyczny interfejs bez VLAN, a także dodajemy dodatkowym poleceniem trasę do naszej dodatkowej sieci, zarezerwowanej w Hetzner dla tego serwera poprzez ten mostek. Dodanie trasy zadziała, gdy interfejs zostanie uruchomiony.
Drugim mostkiem będzie interfejs dla lokalnego ruchu, dodajemy do niego adres, aby uzyskać łączność między różnymi serwerami Proxmox w lokalnej sieci bez dostępu do internetu i wskazujemy port jako subinterfejs eno1.4000, który jest przydzielony dla naszego VlanID.
Podczas wstępnej konfiguracji pojawiają się wskazówki, że można zainstalować dodatkowy pakiet ifupdown2 dla Proxmox, co pozwoli na dokonanie zmian w interfejsach sieciowych bez całkowitego restartu serwera. Jednakże dotyczy to tylko początkowej konfiguracji, a przy użyciu mostków i konfiguracji maszyn wirtualnych napotykasz problemy z utratą sieci w wirtualkach. Przy tym, jeśli edytujesz na przykład interfejs vmbr2, to po zastosowaniu konfiguracji sieć przestaje działać na wszystkich wewnętrznych interfejsach i nie uruchamia się do pełnego restartu serwera. ifdown&&ifup nie pomagają. Jeśli ktoś ma rozwiązanie – będę wdzięczny.
Pierwszy skonfigurowany interfejs na serwerze pozostaje działający i dostępny.
Przydzielenie adresu dla CHR, aby nie stracić adresów z puli
Pula adresów, którą przydziela Hetzner, wygląda dla administratora sieci dość dziwnie, mniej więcej tak:
Dziwnością jest to, że jako bramę sugeruje użycie własnego adresu fizycznego serwera.
Klasyczna opcja, proponowana przez Hetzner, została opisana w zadaniu i została zrealizowana przez klienta samodzielnie. W tej opcji klient traci pierwszy adres na adres sieci, drugi adres na mostku proxmox, który również będzie bramą, a ostatni adres na broadcast. Adresy IPv4 nigdy nie są zbędne. Jeśli spróbujesz bezpośrednio przypisać adres IP 136.x.x.177/29 do CHR oraz bramę dla 0.0.0.0/0 148.x.x.165, to będzie to możliwe, jednak brama nie będzie podłączona bezpośrednio i dlatego będzie niedostępna.
Można to obejść, używając sieci 32 dla każdego adresu i wskazując jako nazwę sieci potrzebny nam adres, który może być dowolny. Uzyskuje się analogiczne połączenie point-to-point.
W takim przypadku brama oczywiście będzie dostępna, a wszystko będzie działać tak, jak potrzebujemy.
Pamiętaj, że w takiej konfiguracji nie zaleca się używania zasady SRC-NAT masquerade, ponieważ adres wyjściowy będzie różny i lepiej jest określić action: src-NAT oraz konkretny adres, z którego będziesz uruchamiać klienta.
- I na koniec.
Aby zablokować dostęp do samego Proxmox z internetu, skorzystaj z wbudowanych środków: jest świetna zapora ogniowa.
Nie należy używać zapory ogniowej oferowanej przez hetzner, aby nie pogubić się w lokalizacji ustawień. Hetzner wpłynie także na wszystkie sieci, w tym te, które są połączone z CHR, a do otwierania i przekazywania portów konieczne będzie również otwieranie ich w interfejsie webowym dostawcy.
Źródło: habr.com
