Când te confrunți cu o problemă și te oprești din cantitatea mare de documentație, încearcă să sistematizezi și să notezi ceea ce ai învățat pentru a reține mai bine. De asemenea, fă o instrucțiune pentru această problemă, astfel încât să nu fie necesar să parcurgi tot drumul din nou.
Documentația inițială este disponibilă într-o cantitate mare pe
Formularea problemei
Clientul dorește să integreze mai multe servere închiriate într-o singură rețea, pentru a scăpa de necesitatea de a plăti pentru mai multe subrețele suplimentare, să conecteze tot echipamentul printr-un router, să le aloce adrese IP locale și să se protejeze cu un firewall. Astfel, tot traficul de serviciu va circula în interiorul VLAN-ului. De asemenea, să mute mașinile virtuale de pe un server vechi pe unul nou și să renunțe la acel server, să facă upgrade la hardware-ul vechi utilizat și, de asemenea, să treacă la un Proxmox mai recent.
Inițial, clientul are 5 servere, fiecare având o subrețea suplimentară, iar prima adresă din subrețeaua alocată este alocată unei punți suplimentare pe Proxmox.
În acest context, VM-urile funcționează pe Windows și au configurat adresa 85.x.x.177/29 cu gateway 85.x.x.176.
Într-o notă similară, toate cele 5 servere sunt configurate cu propriile mașini virtuale.
Interesant este că această configurație este eronată în principiu în ceea ce privește configurarea rețelei, deoarece se folosește adresa rețelei pentru primul nod și totodată ca gateway. Dacă ai încerca să configurezi o astfel de configurație pe o mașină virtuală în Ubuntu, rețeaua nu ar funcționa.
Implementarea
- Creăm vSwitch în interfață, alocăm un VlanID, adăugăm acest vSwitch la toate serverele necesare.
- Facem un server de test, pentru a putea configura și a migra fără probleme.
Ridicăm prima mașină virtuală chr prin .
Dacă folosești scriptul oferit, fii atent că se verifică inițial existența directorului -d /root/temp, iar dacă acesta nu există, se creează directorul /home/root/temp, însă lucrul continuă totuși cu directorul /root/temp. Scriptul trebuie corectat pentru a crea directorul corespunzător.
- Configurăm rețeaua pentru Proxmox.
Adăugăm un subinterfață cu numărul VLAN, indicăm că configurarea adreselor se va realiza pe punți folosind inet manual. IMPORTANT. Nu se pot configura adrese IP pe interfețele pe care le vei include apoi în punte, deoarece modul în care va funcționa acest lucru și dacă va funcționa în general este necunoscut.
Apoi creăm bridge-ul vmbr0 – și îi asociem prima adresă a serverului, furnizată de către providerul Hetzner, specificăm portul bridge-ului – primul interfață fizică fără VLAN, și de asemenea indicăm o comandă suplimentară pentru adăugarea unei rute către rețeaua noastră suplimentară, comandată la Hetzner pentru acest server prin acest bridge. Adăugarea rutei va funcționa atunci când interfața este activată.
Al doilea bridge va fi interfața pentru traficul local, adăugăm pe acesta o adresă pentru a obține conectivitate între diferitele servere Proxmox prin rețeaua locală fără a ieși pe internet și specificăm sub-interfața eno1.4000, care este rezervată pentru VlanID-ul nostru.
În timpul configurării inițiale, există sugestii că se poate instala pachetul ifupdown2 pentru Proxmox, iar la modificările interfețelor de rețea, serverul nu trebuie să fie repornit complet. Totuși, aceasta este caracteristică doar pentru setările inițiale, iar atunci când folosești bridges și configurezi deja mașini virtuale, te confrunți cu probleme de cădere a rețelei în virtuale. De exemplu, ai modificat interfața vmbr2, dar după aplicarea configurației, rețeaua cedează deja pe toate interfețele interne și nu se activează până la o repornire completă a serverului. ifdown&&ifup nu ajută. Dacă cineva are o soluție – aș fi recunoscător.
Prima interfață configurată pe server rămâne funcțională și accesibilă.
Alocarea unei adrese pentru CHR pentru a nu pierde adresele din pool.
Pool-ul de adrese pe care îl furnizează Hetzner arată destul de ciudat pentru rețelistică, aproximativ așa:
Ciudățenia este că se propune utilizarea propriei adrese fizice a serverului ca gateway.
Varianta clasică, propusă de către Hetzner este specificată în formularea sarcinii și a fost realizată de client pe cont propriu. În această variantă, clientul pierde prima adresă pentru adresa de rețea, a doua adresă pe bridge-ul proxmox, care va fi și gateway-ul, și ultima adresă pentru broadcast. Adresele IPv4 nu sunt niciodată de prisos. Dacă încerci direct să-ți scrii pe CHR adresa IP 136.x.x.177/29 și gateway pentru 0.0.0.0/0 148.x.x.165, poți face acest lucru, dar gateway-ul nu va fi Direct Connected și, prin urmare, va fi unreachable.
Se poate ieși din această situație dacă folosești o rețea de 32 pe fiecare adresă și ca nume al rețelei indicând adresa de care avem nevoie, care poate fi orice. Rezultatul este un analog al conexiunii point-to-point.
În acest caz, gateway-ul va fi desigur disponibil și totul va funcționa așa cum trebuie.
Este important să țineți cont că în această configurație nu este recomandat să utilizați regula SRC-NAT masquerade, deoarece adresa de ieșire va fi diferit definită, iar mai corect ar fi să specificați action: src-NAT și adresa concretă din care veți lansa clientul.
- Și, în cele din urmă.
Pentru a bloca accesul la Proxmox din internet, utilizați mijloacele încorporate: există un firewall excelent.
Nu este recomandat să folosiți firewall-ul propus de Hetzner, pentru a nu vă confunda cu locația setărilor. De asemenea, Hetzner va afecta toate rețelele, inclusiv cele configurate pe CHR, iar pentru a deschide și redirecționa porturile, va trebui să le deschideți și în interfața web a furnizorului.
Sursa: habr.com
