Kur përballeni me një pyetje dhe një pushim nga një sasi e madhe dokumentacioni, përpiquni të organizoni dhe shkruani atë që keni mësuar të mbani mend më mirë. Dhe gjithashtu bëni udhëzime për këtë çështje në mënyrë që të mos kaloni përsëri nëpër të gjithë rrugën.
Dokumentacioni burimor është i disponueshëm në sasi të mëdha në
Formulimi i problemit
Klienti dëshiron të kombinojë disa serverë të marrë me qira në një rrjet në mënyrë që të heqë qafe nevojën për të paguar për disa nënrrjeta shtesë, të varë të gjithë familjen e tij pas një ruteri, t'u caktojë atyre adresa lokale dhe të mbrohet nga një mur zjarri. Kështu që i gjithë trafiku i shërbimit të kalojë brenda VLAN. Plus, zhvendosni makinat virtuale nga një server i vjetër në një të ri dhe braktisni atë, përmirësoni harduerin e vjetër që po përdorni dhe në të njëjtën kohë kaloni në Proxmox të ri.
Fillimisht, klienti ka 5 serverë, secili me një nënrrjet shtesë, adresa e parë nga nënrrjeti i dedikuar i caktohet urës shtesë në Proxmox
Në të njëjtën kohë, VM-të funksionojnë në Windows dhe kanë adresën 85.xx177/29 të konfiguruar me një portë 85.xx176
Dhe të 5 serverët me makinat e tyre virtuale janë konfiguruar në një mënyrë të ngjashme.
Është qesharake që ky konfigurim është i gabuar në konfigurimin e rrjetit në parim; përdorni adresën e rrjetit për nyjen e parë dhe të njëjtën gjë për gateway. Nëse përpiqeni ta ekzekutoni këtë konfigurim në një makinë virtuale në Ubuntu, rrjeti nuk funksionon.
Zbatimi
- Ne krijojmë një vSwitch në ndërfaqe, caktojmë një VlanID për të dhe shtojmë këtë vSwitch në të gjithë serverët që na duhen.
- Ne po bëjmë një server testimi në mënyrë që të mund të konfigurojmë dhe të lëvizim pa probleme.
Ne ngremë makinën e parë virtuale chr nga .
Nëse përdorni skriptin e mësipërm, ju lutemi vini re se ai së pari kontrollon praninë e drejtorisë -d /root/temp dhe nëse nuk është aty, krijohet drejtoria /home/root/temp, por puna e mëtejshme vazhdon ende. me direktorinë /root/temp. Skripti duhet të korrigjohet për të krijuar drejtorinë e duhur.
- Vendosja e një rrjeti për Proxmox.
Ne shtojmë një nënndërfaqe me një numër VLAN, duke treguar se adresat do të konfigurohen në urat duke përdorur manualin inet. E RËNDËSISHME. Ju nuk mund të konfiguroni adresat IP në ndërfaqet që do të përfshini më pas në urë; si do të funksionojë kjo dhe nëse do të funksionojë do të jetë e panjohur për këdo.
Tjetra, ne krijojmë një urë vmbr0 - dhe bashkojmë me të adresën e parë të vetë serverit, të dhënë nga ofruesit Hetzner, tregojmë portën e urës - ndërfaqen e parë fizike pa VLAN, dhe gjithashtu specifikojmë me një komandë shtesë shtimin të një rruge drejt rrjetit tonë shtesë, të porositur nga Hetzner për këtë server përmes kësaj ure. Shtimi i një itinerari do të funksionojë kur ndërfaqja të rritet.
Ura e dytë do të jetë ndërfaqja jonë për trafikun lokal, ne shtojmë një adresë në të për të marrë lidhjen midis serverëve të ndryshëm Proxmox përmes një rrjeti lokal pa qasje në internet dhe specifikojmë portin si nënndërfaqe eno1.4000, e cila është ndarë për VlanID-në tonë.
Gjatë konfigurimit fillestar, hasni këshilla se mund të instaloni një paketë shtesë ifupdown2 për Proxmox dhe nuk keni nevojë të rindizni të gjithë serverin nëse ka ndryshime në ndërfaqet e rrjetit. Megjithatë, kjo është tipike vetëm për konfigurimin fillestar, dhe kur përdorni ura dhe konfiguroni makina virtuale, hasni probleme me dështimin e rrjetit në makinat virtuale. Përkundër faktit që keni redaktuar, për shembull, ndërfaqen vmbr2 dhe kur aplikoni konfigurimin, rrjeti bie në të gjitha ndërfaqet e brendshme dhe nuk rikuperohet derisa serveri të riniset plotësisht. ifdown&&ifup nuk ndihmon. Nëse dikush ka një zgjidhje, do të isha mirënjohës.
Ndërfaqja e parë e konfiguruar në server mbetet funksionale dhe e aksesueshme.
-
Ndarja e një adrese për CHR në mënyrë që të mos humbasin adresat nga grupi
Grupi i adresave që prodhon Hetzner duket shumë i çuditshëm për një rrjetor, diçka si kjo:
Gjëja e çuditshme është se porta sugjeron përdorimin e adresës së saj të serverit fizik.
Opsioni klasik i propozuar nga vetë Hetzner tregohet në deklaratën e problemit dhe u zbatua nga klienti në mënyrë të pavarur. Në këtë opsion, klienti humb adresën e parë në adresën e rrjetit, adresën e dytë në urën proxmox dhe gjithashtu do të jetë porta dhe adresa e fundit për transmetimin. Adresat IPv4 nuk janë kurrë të tepërta. Nëse provoni drejtpërdrejt të regjistroni adresën IP 136.x.x.177/29 dhe portën për 0.0.0.0/0 148.x.x.165 në CHR, mund ta bëni këtë, por porta nuk do të jetë e lidhur direkt dhe për këtë arsye do të jetë e paarritshme .
Mund të dalim nga kjo situatë duke përdorur rrjetin 32 për secilën adresë dhe duke specifikuar adresën që na nevojitet, e cila mund të jetë çdo gjë, si emri i rrjetit. Rezulton të jetë një analog i një lidhjeje pikë-për-pikë.
Në këtë rast, porta sigurisht që do të jetë e disponueshme dhe gjithçka do të funksionojë ashtu siç na nevojitet.
Mbani në mend se në një konfigurim të tillë nuk rekomandohet të përdorni rregullin e maskaradës SRC-NAT, sepse adresa e daljes do të jetë pafundësisht e ndryshme, dhe është më e saktë të specifikoni veprimin: src-NAT dhe adresën specifike nga e cila do të lironi klientin.
- Dhe së fundi.
Për të bllokuar hyrjen në vetë Proxmox nga Interneti, përdorni mjetet e integruara: ekziston një mur i shkëlqyer zjarri.
Ju nuk duhet të përdorni murin e zjarrit të ofruar nga hetzner, në mënyrë që të mos ngatërroheni për vendndodhjen e cilësimeve. Hetzner do të punojë gjithashtu në të gjitha rrjetet, përfshirë ato të krijuara në CHR, dhe për të hapur dhe përcjellë portet, do të jetë gjithashtu e nevojshme hapja e tyre në ndërfaqen e internetit të ofruesit.
Burimi: www.habr.com