Új hozzászólás Aktív témák

• #4008 AiRLAC veterán almi #4004

  Új Válasz 2017-09-28 08:55:20 #4008

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  AiRLAC

  veterán

  válasz almi #4004 üzenetére

  Hacsak direkt nem célod hogy záros határidőn belül megtörjék a szervert akkor kurvagyorsan tedd egy VPN mögé.

• #4005 Chal addikt almi #4004

  Új Válasz 2017-09-27 20:42:28 #4005

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Chal

  addikt

  válasz almi #4004 üzenetére

  Ajánlott, stabil, és biztonságos módon kb. sehogy. Mármint plusz eszközök használata nélkül.

  Bővebben:

  A best practice itt az lenne, hogy ledumálod a szolgáltatóval, hogy adjon +1 switchportot és arra egy VPN elérést. Portot vélhetően tud, VPN szolgáltatást hozzá már nem biztos, ezért ez utóbbi esetben kelleni fog valamilyen eszköz a host elé. Ez pénztárcától függően lehet egy mini PC, olcsó router, Mikrotik router, kisebb Cisco ASA, stb stb... Ezután a hoston létrehozol egy saját virtual switchet saját vmkernel interface-el (persze ehhez a host oldalán is kell +egy fizikai uplink), és ezen keresztül manageled a hostot. Itt még esetleg lehet spórolni azzal, hogy a fent említett VPN/router eszközt egy vm-el valósítod meg. Ezen vm egyik vmnic-ét különálló vs-re teszed, és a szolgáltató igényelsz neki egy publikus IP-t, a másik nic-et pedig bedobod az esxi management networkbe. Ez persze a külső hw-s eszközhöz képest már gányolás kategória. Külső eszköz esetén egyébként pl. a host out-of-band megoldását (mint pl. a HP ILO) is bele tudod kötni, router vm esetén nyilván ez felejtős. Szóval én mindenképpen a külső megoldást ajánlanám, legyen az a szolgáltató által biztosított VPN, vagy saját eszközzel megoldott.

  A másik megoldás igazi tákolás: csinálsz egy vs-t fizikai uplink nélkül, ebbe teszed a vmkernel interfészt, majd hozzárendelsz egy privát subnetet és management IP-t. A másik vs kapja meg a szolgáltató által adott fizikai uplinket, és ezt a két hálózatot összekötöd egy router vm-el. A router vm-en természetesen csinálsz VPN szolgáltatást melyen keresztül eléred az mgmt vmkernel interfacet. Ebben az esetben (is) nagy kérdés, hogy a szolgáltató tud e több publikus IP-t biztosítan az uplinken, hiszen a router vm el fogja vinni azt az 1-et amit jelenleg is kaptál. Szóval a további vm-eknek kell igényelni még IP-t, vagy beteszed őket a privát subnetbe (vagy akár egy másikba, ez már rajtad múlik, hogy mennyire akarod szeparálni az esxi mgmt-től) a router vm-en pedig NAT-olod őket a külvilág felé. Természetesen nat esetén át kell gondolni azt is, hogy az alkalmazások támogatják e ezt a felállást, illetve hogy mennyire akarod keresztülküldeni a forgalmukat egy vm-en. Szóval ebből egy bitang nagy SPOF-ot lehet így kihozni, ráadásul a szoftveres-gányolós fajtából.

  Én egy helyen a második megoldást használom, évek óta működik, de tudni kell róla, hogy ez egy privát/hobbi/játszós szerver, gombokért bérlem egy német hosting szolgáltatótól, és ha lerohadna rajta a router vm, vagy bármi baja lenne ami miatt nem érem el az egész kócerájt, akkor sem történne semmi, még abban az esetben sem, ha teszem azt 2-3 hétig nem hárítom el a hibát, mert mondjuk nincs kedvem. Ha ez a rendszer pénzt termelne, és ügyfelek lennének rajta, akkor biztosan nem így oldanám meg.

Új hozzászólás Aktív témák