DMZ na Proxmoxe

DMZ na Proxmoxe
« kdy: 28. 10. 2025, 16:17:29 »
Topologia
Kód: [Vybrat]
Proxmox -- vmbr0 -- enp2s0 -- rb5009ug (eth2) -- internet (eth1)
Kód: [Vybrat]
LAN siet 192.168.100.0/24
IP PVE 192.168.100.2
vmbr0 je sietovy bridge pre VM a CT.

Chcem vytvorit novu siet (192.168.200.0/24), teda novy bridge pre server/y, ktore budu izolovane od 192.168.100.0/24.
Neviem ci je to najlepsia moznost, ale zrejme bude idelane pouzit VLAN (podporu ma MK ROS7 aj PVE 9).

Takze na MK

Kód: [Vybrat]
/interface vlan add name=vlan200_dmz interface=bridge1 vlan-id=200 comment="DMZ VLAN"
/ip address add address=192.168.200.1/24 interface=vlan200_dmz comment="DMZ network"
/ip firewall nat add chain=srcnat out-interface=pppoe-out1 src-address=192.168.200.0/24 action=masquerade comment="DMZ internet access"
/ip firewall filter add chain=forward src-address=192.168.200.0/24 dst-address=192.168.100.0/24 action=drop comment="Block DMZ -> LAN"
Pre zaklad by to malo stacit.

PVE

do /etc/network/interfaces pridavam

Kód: [Vybrat]
auto vmbr200
iface vmbr200 inet manual
    bridge-ports enp2s0.200
    bridge-stp off
    bridge-fd 0

Jediny problem je ze som geograficky od PVE dalej a siet na proxmoxe po reboote padla (divne je, ze LXC a VM bezia bez problemov dalej).

Viete ma nakopnut ci idem dobrym smerom a kde robim chybu ?


Re:DMZ na Proxmoxe
« Odpověď #1 kdy: 29. 10. 2025, 13:50:45 »
bud zdrav s proxmoxem zacinam.. ale tim spis to mam ted cerstve vozkouseny. mam proxmox 9.
Kód: [Vybrat]
pve-manager/9.0.11/3bf5476b8a4699e2 (running kernel: 6.14.11-4-pve)

na trunk interface mam
Kód: [Vybrat]
auto sfpplus
iface sfpplus inet manual
        bridge-ports ens1f0np0 ens1f1np1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2 5 10 20 30 40 50 60 70 80 90 100 110 120

a na jednotlivejch hostech do sitovky si napises jaky vlan ID chces a proxmox zaridi zbytek sam. tzn bridge primo pro vlany nevyrabis, pokud tam nepotrebujes mit management if.
Kód: [Vybrat]
net0: virtio=BC:24:11:EC:D6:99,bridge=sfpplus,firewall=1,tag=10

pokud bys tam chtel mit mgmt if udelas neco takovyho
Kód: [Vybrat]
auto vlan2
iface vlan2 inet static
        address 10.1.2.4/24
        gateway 10.1.2.1
        bridge-ports sfpplus.2
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2

stalo se mi ze se proxmoxu nejak kouslo sitovani pri nastavovani z guicka a musel jsem ho protocit z iDracu z local console. nevylucuju, ze moji chybou.

je zajimavy ze to co maj v dokumentaci mi nefungovalo
zatim to mam takhle v testovacim provozu a zda se to delat co od toho cekam.

Re:DMZ na Proxmoxe
« Odpověď #2 kdy: 29. 10. 2025, 16:12:37 »
na trunk interface mam
Kód: [Vybrat]
auto sfpplus
iface sfpplus inet manual
        bridge-ports ens1f0np0 ens1f1np1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2 5 10 20 30 40 50 60 70 80 90 100 110 120

a na jednotlivejch hostech do sitovky si napises jaky vlan ID chces a proxmox zaridi zbytek sam. tzn bridge primo pro vlany nevyrabis, pokud tam nepotrebujes mit management if.
Kód: [Vybrat]
net0: virtio=BC:24:11:EC:D6:99,bridge=sfpplus,firewall=1,tag=10

Souhlas, jenom dávat bridgi jméno "sfpplus" mi přijde potenciálně poněkud matoucí :-)
Defaultní vmbr0 mi přijde přehlednější.
Jinak ale logika té konfigurace je myslím v pořádku.

pokud bys tam chtel mit mgmt if udelas neco takovyho
Kód: [Vybrat]
auto vlan2
iface vlan2 inet static
        address 10.1.2.4/24
        gateway 10.1.2.1
        bridge-ports sfpplus.2
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2

Opět to pojmenování... interface jménem "vlan2", ale typu bridge... jasně, je to věc subjektivního vkusu.
Navíc vlan-aware (= bridguje včetně tagů) ale nakonec omezený na tag2...
Vytvořil jste druhý bridge, do kterého přiřazujete VLAN subinterface z prvního bridge... err...
dejte mi někdo pohlavek, jestli nevím o nějaké skryté samočinné eleganci :-)

Sečteno podtrženo, co třeba takto?
V tom prvním iface bloku si jenom přejmenuju defaultní bridge na defaultní jméno, čistě pro svoje egoistické uspokojení:

Kód: [Vybrat]
auto vmbr0
iface vmbr0 inet manual
        bridge-ports ens1f0np0 ens1f1np1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes        # toto v defaultu tuším není, správně jste to přidal
        bridge-vids 2 5 10 20 30 40 50 60 70 80 90 100 110 120

auto vmbr0.2
iface vmbr0.2 inet static
        address 10.1.2.4/24
        gateway 10.1.2.1

...vytvoří ten VLANový subinterface s VID=2 pro hostitele automaticky nad defaultním vmbr0.
A pokud byste potřeboval, aby do mngt VLANy viděli taky někteří guesti, tak přiřadit tag v Proxmox GUI jak správně píšete... není potřeba tam pečovat o další bridge, všechno to zvládne bridgovat ten jeden defaultní VLAN-aware.

Mimochodem ty dva tagované fyzické porty... nezasloužily by si spíš LACP bond? (záleží, jaký je jejich smysl v navazující topologii)
« Poslední změna: 29. 10. 2025, 16:15:23 od František Ryšánek »

Jose D

  • *****
  • 914
    • Zobrazit profil
Re:DMZ na Proxmoxe
« Odpověď #3 kdy: 29. 10. 2025, 17:28:32 »
Kód: [Vybrat]
Proxmox -- vmbr0 -- enp2s0 -- rb5009ug (eth2) -- internet (eth1)

mám tu skoro identickej setup. už jsi to rozjel?

Re:DMZ na Proxmoxe
« Odpověď #4 kdy: 29. 10. 2025, 18:49:43 »
dekuju za nazor.
priznavam se, ze jsem prvni sel dle toho co maji v Proxmoxi dokumentaci a nefungovalo mi to.
uz s tim tedka vic laborovat nemam kdy. Vykonove tam problem nevidim snad nebudu zaskocen. kazdopadne pri dalsi prilezitosti (plusminus mesic) zkusim Vas navrh a kdyz nezapomenu dam sem vedet. taky mi to prijde jako nesmysl na prvni pohled a dosel jsem tam v podstate vylucovaci metodou ze zoufalstvi. az bude potreba dojet posledni metr role v plotaku tak mam prichystanej linux packet flow a snad se mi rozsviti az to budu mit na plachte..

Navíc vlan-aware (= bridguje včetně tagů) ale nakonec omezený na tag2...
chapu ze bych se tam mohl dostat do QinQ sitauce ale viz vyse.

ja si to predstavuju jako cisco ekvivalent
Kód: [Vybrat]
switchport mode trunk
switchport trunk native vlan 2
switchport allowed vlan 2
coz by efektivne melo delat to samy co
Kód: [Vybrat]
switchport mode access
switchport access vlan 2
snad, ale proste to nechodilo. mozna jsem nekde v ramci testovani udelal o restart min a vzdycky budu prvni predpokladat chybu u sebe :)
jsem posledni dobou dost unavenej a pristihuju se delat dost debilni chyby, tak to co pisu berte prosim jako s rezervou, prvni prispevek mam z poznamek a doslova mi to takhle funguje a dost jsem se s tim nazlobil, jinac bych snad mlcel a cekal az snad obnovi me dusevni schopnosti..


Re:DMZ na Proxmoxe
« Odpověď #5 kdy: 30. 10. 2025, 00:33:13 »
@panpanika v klidu, nejsme ve škole a já nejsem učitel ani šéf :-)
Já jsem jenom zkombinoval historické znalosti jak se to konfiguruje holýma rukama v živém systému: ifconfig, ip, brctl, bridge, vconfig...   s jakousi znalostí debianího tradičního konfiguráku /etc/network/interfaces. Který má docela obstojnou dokumentaci, a poměrně dost navazujících examplů se válí různě po internetu - např. na serverech ze skupiny StackExchange (vč. Ask Ubuntu).
Dokumentace Proxmoxu ohledně toho vlan-aware bridge mi přišla poměrně kusá, ale když jsem to poskládal s examply z Debianu, tak mi vyšlo něco, co mi dává smysl. A v Proxmoxu mi to funguje. A rozhodně netvrdím, že je to jediná správná možnost.

Re:DMZ na Proxmoxe
« Odpověď #6 kdy: 01. 11. 2025, 12:43:58 »
Kód: [Vybrat]
Proxmox -- vmbr0 -- enp2s0 -- rb5009ug (eth2) -- internet (eth1)

mám tu skoro identickej setup. už jsi to rozjel?
Mne to uz funguje, tak ako to mam povodne v prvom prispevku. Lenze ja nemam ziadny idrac ani ipmi, tak ze som musel cestovat k serveru fyzicky.
Toto je cely config
Kód: [Vybrat]
auto lo
iface lo inet loopback

iface enp2s0 inet manual

iface eno1 inet manual

iface wlp4s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.100.2/24
        gateway 192.168.100.1
        bridge-ports enp2s0
        bridge-stp off
        bridge-fd 0

auto vmbr200
iface vmbr200 inet manual
        bridge-ports enp2s0.200
        bridge-stp off
        bridge-fd 0

source /etc/network/interfaces.d/*
Neviem vsak dovod, preco som sa nevedel napojit po reboote na proxmox (paradoxne na ine CT a VM som sa bez problemov pripojil (na stejnom subnete ako je aj proxmox)).
Nie som specialita, ale ked som robil diagnostiku, ci VLAN funguje a taguje packety, tak sa zda, ze to fungovalo OK.
Info z MK
Kód: [Vybrat]
                         ;;; DMZ VLAN 200
                       name:      vlan200
      rx-packets-per-second:            2
         rx-bits-per-second:      1216bps
   fp-rx-packets-per-second:            2
      fp-rx-bits-per-second:      1216bps
        rx-drops-per-second:            0
       rx-errors-per-second:            0
      tx-packets-per-second:            2
         tx-bits-per-second:      1112bps
   fp-tx-packets-per-second:            0
      fp-tx-bits-per-second:         0bps
        tx-drops-per-second:            0
  tx-queue-drops-per-second:            0
       tx-errors-per-second:            0
Info z PVE

Kód: [Vybrat]
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:48:43.088516 f4:1e:57:f2:1c:c7 (oui Unknown) > bc:24:11:93:d8:b6 (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 200, p 0, ethertype IPv4 (0x0800), 10.10.8.3 > 192.168.200.2: ICMP echo request, id 42605, seq 9, length 64
11:48:43.088545 bc:24:11:93:d8:b6 (oui Unknown) > f4:1e:57:f2:1c:c7 (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 200, p 0, ethertype IPv4 (0x0800), 192.168.200.2 > 10.10.8.3: ICMP echo reply, id 42605, seq 9, length 64
11:48:44.090340 f4:1e:57:f2:1c:c7 (oui Unknown) > bc:24:11:93:d8:b6 (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 200, p 0, ethertype IPv4 (0x0800), 10.10.8.3 > 192.168.200.2: ICMP echo request, id 42605, seq 10, length 64
11:48:44.090380 bc:24:11:93:d8:b6 (oui Unknown) > f4:1e:57:f2:1c:c7 (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 200, p 0, ethertype IPv4 (0x0800), 192.168.200.2 > 10.10.8.3: ICMP echo reply, id 42605, seq 10, length 64
11:48:45.091594 f4:1e:57:f2:1c:c7 (oui Unknown) > bc:24:11:93:d8:b6 (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 200, p 0, ethertype IPv4 (0x0800), 10.10.8.3 > 192.168.200.2: ICMP echo request, id 42605, seq 11, length 64
11:48:45.091635 bc:24:11:93:d8:b6 (oui Unknown) > f4:1e:57:f2:1c:c7 (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 200, p 0, ethertype IPv4 (0x0800), 192.168.200.2 > 10.10.8.3: ICMP echo reply, id 42605, seq 11, length 64
11:48:46.092695 f4:1e:57:f2:1c:c7 (oui Unknown) > bc:24:11:93:d8:b6 (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 200, p 0, ethertype IPv4 (0x0800), 10.10.8.3 > 192.168.200.2: ICMP echo request, id 42605, seq 12, length 64
11:48:46.092734 bc:24:11:93:d8:b6 (oui Unknown) > f4:1e:57:f2:1c:c7 (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 200, p 0, ethertype IPv4 (0x0800), 192.168.200.2 > 10.10.8.3: ICMP echo reply, id 42605, seq 12, length 64
 
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

Re:DMZ na Proxmoxe : Síť-Vytvořit- nový bridge
« Odpověď #7 kdy: 01. 11. 2025, 18:54:03 »
Také to teď čerstvě řeším, (víc výzev, například  zda na routeru nechat iptables -I FORWARD -s 10.0.1.0/24 -d 10.0.1.0/24 -j ACCEPT) nebo nezvyk..... Je to taková školková úloha  zapojování drátů do krabiček.

Mě napadla jedna obvious věc: udělej to tak, aby rozsah pro VM byl odlišný od adresy clusteru.

----a/ nebo ----

Jak to udělat? Proxmox- Datacenter-Uzel počítač : v druhém vertikálním menu: Systém-Síť. Chvilku zastav, zapřemýšlej po rozklikni si upravit všech tří položek (vmbr0 enpes0 a wtf0wifi1the2fuck)  a pozoruj, co tam je za hodnoty
Já bych to udělat tak, že bych dal Vytvořit - Linux bridge a do portů mostu nedal nic, nebo jiné rozhraní, které tam chci., třeba bych ho pojmenoval pro změnu vm,bro. (a odteď nové CT/VM zapřahoval do vmbro)
Je to správně? Ptám se, že to vidím poprvé.
« Poslední změna: 01. 11. 2025, 18:56:38 od Ħαℓ₸℮ℵ ␏⫢ ⦚ »

Re:DMZ na Proxmoxe : Síť-Vytvořit- nový bridge
« Odpověď #8 kdy: 02. 11. 2025, 00:05:41 »
Já bych to udělat tak, že bych dal Vytvořit - Linux bridge a do portů mostu nedal nic,...
Sice jsem moc nedával pozor, k čemu to, ale vyrobit na hostiteli soft-bridge, který zpočátku nebude mít žádné member porty, lze takto:

Kód: [Vybrat]
auto mojebr0
iface mojebr0 inet manual
    bridge-ports none
    ...atd...

Hodí se to obecně k vytváření čistě virtuálních segmentů sítě, izolovaných od fyzických ethernetů hostitelského stroje - do takového virtuálního L2 segmentu se později podle okamžité potřeby a situace mohou probouzet VM guesti, až na ně přijde řada v kaskádě závislých startů, nebo když správce nějakou virtuálku spustí dle svého okamžitého rozmaru.

Re:sjednocení MAC adres na Proxmoxe při trafficu ven
« Odpověď #9 kdy: 04. 11. 2025, 13:18:52 »
Už vím co jsem chtěl. Mám li víc hostů  , vm ,lxc, pak defaultně jsou ve vmbr0 (jehož member je i fyzické rozhraní hypervizora) a traffic z každého VMID/CTID má svoji MAC adresu a chtěl bych to "uklidit" pod jednu mac adresu .  ideílně druhou odlišnou od hosta

Jak na to nejlépe? řešení bude asi víc

Re:sjednocení MAC adres na Proxmoxe při trafficu ven
« Odpověď #10 kdy: 04. 11. 2025, 16:42:59 »
Už vím co jsem chtěl. Mám li víc hostů  , vm ,lxc, pak defaultně jsou ve vmbr0 (jehož member je i fyzické rozhraní hypervizora) a traffic z každého VMID/CTID má svoji MAC adresu a chtěl bych to "uklidit" pod jednu mac adresu .  ideílně druhou odlišnou od hosta

Jak na to nejlépe? řešení bude asi víc

Zajímavé zadání. A jak si představujete, že je "sesypete" pod jednu MAC adresu? Že pak mezi těmi skutečným VM guesty rozlišíte?

Teoreticky za určitých okolností se praktikuje "překlad MAC adres" (jako L2 maškaráda). Dělá to WiFi client v tříadresním režimu, když se po něm chce, aby na klientské straně bridgoval do další sítě. Taky "schovává síť pod sebou" za jedinou MAC adresu. Popravdě nevím, jak bych toto spáchal např. pomocí ebtables na L2 (možná to jde, ale zatím jsem našel jenom prostý SNAT). Pozor: nefunguje navazování spojení ze širší sítě skrz tuhle L2 maškarádu "dovnitř".

Nebo samozřejmě L3 maškarádou to zařídit. Za mě čistší řešení. Ale to byste musel provoz protáhnout skrz L3 routing process. Takže asi udělat izolovaný virtuální bridge, do něj sázet guesty, a v routovacím procesu hostitelského Proxmoxu přidat maškarádu z muj_izolovany_br0 směrem na IP rozhraní Proxmox hostitele... nebo si vyrobit dedicated NAT outside rozhraní a potřebný routovací proces s maškarádou zavřít do izolovaného network namespace (nebo VM guesta). Vyrobit si dedicated NAT outside rozhraní lze například pomocí VETH nebo MACVLAN...

Re:MAC agregace adres na Proxmoxe při trafficu ven
« Odpověď #11 kdy: 06. 11. 2025, 15:14:04 »
Pardon, nestihl jsem to dopsat (upřesnění a moje myšlenky ; zadání jakš takš ano)
No myslím právě jen při trafficu ven přes eth0 fyzické rozhraní, aby traffic kontejnerů a VM vystupoval pod jednou mac adresou (případně dvěmi, aby šlo rozlišovat, první původní s MAC hosta si ponechat pro provoz v konextu hosta a druhou  MAC pro balík LXC konejnerů+KVM guestů dohromady)
Uvnitř počítače samozřejmě to samozřejmě nejde, když je to sesíťované přes L2 vmbr(idge)0.
napadaly mě různé L2 proxy, ARP proxy, atd, ale to se mi zdá jako přidávání komplexity, routing je asi nejlepší řešení? Ale kde ten routing dělat, jakým způsobem? vyčleneňit na to nový LXC nebo nebo v kontextu hosta?

A nebo se na to vykašlat? Reálně to žádný problém není, 20 záznamů v CAM tabulce není nic, ale jde spíš o pocit, že to (z pohledu switche, routeru a ostatních fyzických zařízení v síti) kosmeticky vypadá hezky a odpovídá skutečnému stavu, když kysna číslo 3 má právě jednu MAC adresu

Re:DMZ na Proxmoxe
« Odpověď #12 kdy: 07. 11. 2025, 12:04:38 »
Rád slyším, že těm technologiím podle všeho rozumíte. Takže si uděláte vlastní úsudek, s ohledem na Váš "scénář nasazení". Zbytek je totiž do značné míry věc osobního vkusu a zdravého rozumu. Subjektivní faktory.

Mně třeba nepřijde jako moc dobrý nápad, schovávat guesty za společnou MAC adresu, jenom protože jsou pohromadě v jednom fyzickém šasi. Když je pak stejně máte na společném subnetu či VLAN napříč místností, budovou apod. Otázkou je, zda se na ně chcete jednotlivě obracet příchozími spojeními zvenčí. Jako v nějaké velmi povrchní rovině tu motivaci třeba chápu, "udělat si pořádek" - ale v rovině vrstevnatosti sítě, elegantní transparence, třeba taky migrace VM guestů mezi fyzickými boxy... mi to nepřipadá nutně jako dobrý nápad. Ale jak říkám - je to věc Vašeho vkusu, úsudku, scénáře použití atd.

Ohledně dotazu "a kde to teda routovat skrz NAT" - ano v kontextu hostitele je jedna možnost, pomocí iptables to ani není moc práce, a souhlas, nevypadá to moc hezky. Zmínil jste LXC - ano souhlas, to je možnost realizovatelná z větší části prostředky PVE GUI. "lehčí" variantou by bylo, zavřít ten virtualizovaný routující uzel do dedikovaného "network namespace" v rámci hostitele. Podle mého LXC také používá network namespace pro virtualizaci/opouzdření svého síťování (možná kecám, nezkoumal jsem).
Abyste si vyvedl spoj ze základního vmbr0 do odděleného network namespace, k tomu bych použil již zmíněný VETH - vyrobíte pár rozhraní, jedno přiřadíte do vmbr0 v defaultním namespace, druhé v páru vystrčíte do nově vytvořeného network namespace. Následně je mi otázkou, zda je možné, zapíchnout TAP rozhraní konkrétního VM guesta zvenčí v hostiteli právě do toho oploceného dedicated namespace. Ale ono by zřejmě stačilo, nasázet guesty do zcela virtuálního soft-bridge (nemusíte jim ani nutit VLANu) v defaultním namespace, a z něj si vytáhnout opět "VETH pár" do výše připraveného odděleného network namespace. Možná by ten VETH ani nebyl potřeba, možná by stačilo přiřadit do namespace "muj_izolovany_vmbr1" - tady nevím, zda může "vlastní referenční rozhraní instance soft-bridge" patřit do jiného namespace, než členské porty soft-bridge :-)

Doufám, že jsem to zašmodrchal dostatečně a jdu dělat něco užitečného.

Re:DMZ na Proxmoxe
« Odpověď #13 kdy: Dnes v 16:02:49 »
No jsem z toho trochu zašmodrchaný, tohle není úplně můj denní chleba a a ještě v takovéto koncentraci...
Ale když se dívám na ilustrační obrázek VETH, nějak z toho mám pocit, že to ten příklad je špatně, že tam mají chybky v číslech (ale možná taky je OK, jenom ten příklad nemusí být vhodně zvolen, stačilo by zvolit jiné identifikátory)... VETH by mělo být jednoduché  na pochopení, prostě roura (černý spoj na obrázku), která má dva konce a vždy se musí definovat ty konce současně (černé obdélníky) , ale jen je tam (možná?) zmatek , že některé obdélníčky tam jsou (asi?) implicitně a že se odkazují na veth* v spodním řádku (těsně nad br0) . Jenom prostě na první pohled není nikdy není vidět veth2 uvnitř NS2 ačkoliv "assigns veth2 to NS netns2")

, k tomu bych použil již zmíněný VETH

Citace: stránka z redhat #veth
Here's how to set up a VETH configuration:

Kód: [Vybrat]
# ip netns add net1
# ip netns add net2
# ip link add veth1 netns net1 type veth peer name veth2 netns net2
This creates two namespaces, net1 and net2, and a pair of VETH devices, and it assigns veth1 to namespace net1 and veth2 to namespace net2. These two namespaces are connected with this VETH pair. Assign a pair of IP addresses, and you can ping and communicate between the two namespaces.


Koukal jsem i do man ip link a domyslel jsem si že přidané netns ID_NS je zkratka ip link set netns volaná v jednom. , asi to ještě není v dokumentaci man. (ne že bych nevěděl co je netns, ale zkoumal jsem přesný tvar ip link add .type veth)
 ip link add DEVICE type { veth | vxcan } [ peer name NAME ]
                      peer name NAME - specifies the virtual pair device name of the VETH/VXCAN tunnel.
« Poslední změna: Dnes v 16:11:21 od Ħαℓ₸℮ℵ ␏⫢ ⦚ »

Re:DMZ na Proxmoxe
« Odpověď #14 kdy: Dnes v 17:49:52 »
Jo to mě taky zaujalo - ten obrázek by naznačoval, že "netdevice name" veth<pořadové číslo> nemusí být globálně unikátní v instanci OS, ale stačí pokud je unikátní v rámci "network namespace" (zkratka netns, která je Vám záhadou).
Ona se mimochodem rozhraní dají taky všelijak přejmenovávat - viz notace eth0 vs. enp1s0. Zde je taky využito přejmenování, během startu OS.

Network Namespaces jsou takové ohrádky, uvnitř kterých existuje oddělená instance celého síťového stacku (zřejmě nejen L3 ale taky L2). Network Namespace obsahuje svou vlastní routovací tabulku, svůj vlastní soft-bridge proces, svoji vlastní sadu iptables pravidel apod. Když se v shellu odkážete na "netdevice name", který do daného network namespace nepatří = není v dotyčném netns přítomen, dostanete zpátky chybu "no such device".

Network Namespaces jsou jednoduchá virtualizace síťového stacku, zatímco jiné prostředky a rozhraní OS mohou zůstat sdílené. Takže vidíte procesy spolu na hromadě ve výpisech ps a top, můžou vidět všechny stejný filesystém, ale síťoviny můžou mít každý svoje = oddělené ohrádkami (proces je spuštěn uvnitř konkrétního Network Namespace). Upřesňuji: uvnitř konkrétního network namespace může pohromadě běžet větší počet procesů.
Ovšem jednotlivý proces nemůže vidět do více netns zároveň. Probourat červí díru mezi dvěma network namespaces umí právě VETH.

Network Namespaces se podobají např. VRF instancím - nicméně bych řekl, že Network Namespaces mají poněkud širší schopnosti.

Po startu holého systému (Linux) máte pouze základní globální instanci síťového stacku = de facto default network namespace. Pokud následně vytváříte své pojmenované network namespaces, tyto jsou oddělené od globálního default netns a také od sebe navzájem.