Ha kérdésekkel találkozol, és sok dokumentációt átnézel, próbáld meg rendszerezni és feljegyezni, amit tanultál, hogy jobban megjegyezhesd. Készíts egy útmutatót a kérdéshez, hogy ne kelljen újra végigjárnod az összes lépést.
A forrásdokumentáció nagy mennyiségben található itt:
Lépjünk át a kitűzött feladatra: írjunk egy XDP mechanizmust SYN cookie-kkal.
Az ügyfél szeretné egyesíteni a több bérelt szerverét egy hálózatba, hogy megszabaduljon a több külön alhálózat díjaitól, és az összes eszközét egy router mögé kösse, helyi IP-címeket rendelve hozzájuk, valamint tűzfallal biztosítva azokat. Így az összes operatív forgalom VLAN-on belül maradhat. Ezen kívül virtuális gépeket szeretne átköltöztetni egy régi szerverről egy újra, lemondva az előzőről, és frissítené a használt régi hardvert, miközben áttérne egy új Proxmox rendszerre.
Az ügyfélnek eredetileg 5 szervere van, mindegyiken külön alhálózattal, az első cím a kijelölt alhálózatból egy külön bridgen van hozzárendelve a Proxmox alatt.
Ezek a virtuális gépek Windows alatt futnak, és a címük 85.x.x.177/29, a gateway 85.x.x.176.
Hasonló módon vannak beállítva az összes 5 szerver saját virtuális gépeivel.
Vicces, hogy ez a konfiguráció alapvetően hibás a hálózati beállításokban, mivel a hálózati címet használják az első csomópontként, amely ugyanaz a gateway. Ha megpróbálják ezt a konfigurációt elindítani egy virtuális gép alatt Ubuntu rendszerben, a hálózat nem működik.
Megvalósítás
- Virtuális kapcsolót (vSwitch) hozunk létre az interfészen, VLANID-t rendelünk hozzá, és ezt a vSwitch-t az összes szükséges szerverhez hozzáadjuk.
- Készítünk egy teszt szervert, hogy egyszerűen be tudjuk állítani és átköltözni.
Az első virtuális gépet chr néven indítjuk el a .
Ha a megadott scriptet használod, vedd észre, hogy az elején ellenőrzi a -d /root/temp könyvtár meglétét, és ha az nem létezik, létrehozza a /home/root/temp könyvtárat, azonban a további munka továbbra is a /root/temp könyvtárral folytatódik. A scriptet szükséges javítani a megfelelő könyvtár létrehozásához.
- Beállítjuk a hálózatot a Proxmox számára.
Hozzáadunk egy alinterfacet VLAN számmal, megadva, hogy a címek beállítása bridgen történik inet manual módon. FONTOS. IP-címeket nem szabad a bridgen használt interfészeken konfigurálni, mivel hogy ez hogyan fog működni, az senki számára sem ismert.
Ezután létrehozzuk a vmbr0 hidat, és hozzárendelünk hozzá az első IP címet, amelyet a Hetzner szolgáltató adott nekünk. Megadjuk a híd portját – az első fizikai interfészt VLAN nélkül, és emellett egy további paranccsal hozzáadjuk az útvonalat az extra hálózatunkhoz, amelyet a Hetzner szolgáltatott ehhez a szerverhez ezen a hídon keresztül. Az útvonal hozzáadása akkor aktiválódik, amikor az interfész fel van állítva.
A második hidunk a helyi forgalom interfésze lesz, amelyre az IP címet hozzáadjuk, hogy a Proxmox különböző szerverei közötti kapcsolat létrejöhessen a helyi hálózaton, anélkül, hogy az interneten kereszteznék, és megadjuk a portnak az eno1.4000 al-interfészt, amely ki van jelölve a VlanID számára.
A kezdeti beállítás során sok olyan javaslat merül fel, hogy érdemes lenne a Proxmox számára az ifupdown2 csomagot is telepíteni, és a hálózati interfészek változtatásai során a szervert nem kellene teljesen újraindítani. Ez azonban csak az elsődleges beállításra jellemző, és a hidak használatakor, valamint a virtuális gépek beállításakor olyan problémákkal találkozhatsz, hogy a virtuális gépek hálózata megszakad. Amikor például az vmbr2 interfészt módosítottad, a konfiguráció alkalmazásakor a hálózat az összes belső interfészen megszakad, és csak a szerver teljes újraindításával állítható vissza. Az ifdown && ifup nem segít. Ha valakinek van megoldása – hálás lennék.
A legelső beállított interfész a szerveren működőképes és elérhető marad.
Cím kijelölése a CHR számára, hogy ne veszítsük el a címeket a poolból.
A Hetzner által kiadott címpool a hálózati szakemberek számára meglehetősen különösnek tűnik, körülbelül így:
A furcsaság abban rejlik, hogy a kapu használatához a fizikai szerver saját címét javasolják.
A klasszikus lehetőség, amelyet maga a Hetzner ajánlott, fel van tüntetve a feladatban, és a kliens önállóan megvalósította. Ebben az esetben a kliens elveszíti az első címet a hálózati címre, a második címet a proxmox hídon, amely ugyanakkor a gateway is lesz, és az utolsó címet a broadcast számára. Az IPv4 címek sosem feleslegesek. Ha viszont közvetlenül próbálod beállítani a CHR IP címét 136.x.x.177/29-re és a gateway-t 0.0.0.0/0-ra 148.x.x.165-re, akkor ezt megteheted, azonban a gateway nem lesz közvetlenül csatlakoztatható, így elérhetetlen lesz.
Megoldást jelenthet, ha minden címre 32 bites hálózatot használsz, és a hálózat nevének megadásakor a szükséges címet adod meg, ami bármilyen lehet. Ez egy point-to-point kapcsolat analógiája.
Ebben az esetben a gateway nyilvánvalóan elérhető lesz, és minden úgy fog működni, ahogy szükséges.
Figyelembe kell venni, hogy ilyen konfigurációban nem ajánlott SRC-NAT masquerade szabály használata, mert a kimeneti cím meghatározhatatlanul különböző lesz; helyesebb a src-NAT action-t és a konkrét címet megadni, ahonnan a kliens ki fog lépni.
- Nos, és végül.
A Proxmox internetes hozzáférésének blokkolásához használja a beépített eszközöket: van egy nagyszerű tűzfal.
Nem érdemes használni a hetzner által kínált tűzfalat, hogy ne keveredjünk össze a beállítások helyével. A hetzner emellett minden hálózatra hatással lesz, beleértve azokat is, amelyeket a CHR-re állítottak be; a portok megnyitása és átirányítása érdekében a szolgáltató webes felületén is nyitni kell.
Forrás: habr.com
