KVM - nastavení sítě IPV4/IPV6

Jenže potom nebude vps přístupná přes v4 a i kdybych nasměroval portu na interní ip z kvm do vps, tak mi to stejně nepůjde, kdyby byl nějaký průser s kvm. Chci se vyvarovat situaci, kdybych neměl přístup přes v6 a nemusel jsem to opravovat přes konzoli ve vpsadmin.
Takhle, snažím se myslet na všechny scénáře :smiley:, dokonce i ty velice nepravděpodobné.

Jinak nebylo by možné někdy udělat jinou konzoli(něco ve stylu jako má třeba google cloud)? Jakože na pc to jakž takž jde(myslím, že tabování pro autocomplete moc dobře nefunguje a i jiné věci myslím). a dělat v konzoli přes telefon to je úplný horror(myslím jen v situacích, kdy mám při ruce jen mobil :smiley:).

Problém je že když dám vše do bridge tak mi nefunguje NAT, tudíž KVM není přístup přes v4 ale jen přes v6. a brigde mezi KVM a výstupní sítí musí být kvůli fungování v6(bez bridge jsem to nezprovoznil vůbec).

Jinak při restartu vps je pokaždé jiná v6 gateway, což mi oproti statické 255.255.255.254 v4 gateway příjde nelogické. Teda nevím jestli se něco nezměnilo od doby kdy jsem s tím experimentoval.

Misto bridgovani mrkni na toto, jestli to pro Tebe nebude lepsi:

https://utcc.utoronto.ca/~cks/space/blog/linux/ModernProxyIPv6AndARP

Tu konzoli jsme nevyvijeli, je to docela dost komplexni zalezitost, udelat to od nuly… je to prevzate z projektu shellinabox. Kdybys vedel o nejake lepsi/modernejsi/kamaradstejsi s mobilem, sem s tim, muzem zkusit integrovat neco lepsiho :slight_smile:

Je to proto, ze v6 ma koncept link-local adres, co v4 tak uplne nema, proto se na v4 musi takhle strasne nestandardne prasit, u v6 jsme si rikali, ze takovou prasarnu delat nebudem, kdyz to neni potreba :smiley: Menici se adresu bychom umeli doresit, kdyby Ti to pomohlo; ted to neni staticke jenom proto, ze LXC to neumi a jeden z tech veth koncu meni mac adresu pri kazdem startu VPS. Ale dalo by se to dodelat, kdyby Ti to nejak vyrazne pomohlo.

Předem upozorňuji že nejsem expert a mé nazvosloví může být trochu jiné :smiley:.
Po té konzoli se mrknu.
Dřív jsem NDP zkoušel, ale neuspěšně
jinak ten blog je trošku špatně, ale navedl mě na myšlenku
v blogu je

echo 1 >/proc/sys/net/ipv6/conf/em0/proxy_arp

jenže ARP je u ipv4 ale ne u ipv6, tam je NDP
takže jsem našel klíč

/proc/sys/net/ipv6/conf/eth0/proxy_ndp
o kterém jsem nevěděl tak možná si s tím pohraju.
jinak nevíš o nějakém funkčním skriptu který má být údajně v /etc/qemu-ifup?
je to kvůli tomu když jsem do qemu nastavil síť tap tak to padá na /etc/qemu-ifup a ikdyž jsem tam zkoušel snad cokoliv tak bez úspěchu a vždy to spadlo na tento skript.

ten blog je potreba procist, protoze se to prave mezi v4 a v6 lisi a je potreba to trochu nasat :slight_smile:

jinac Aither prave rikal, ze by se dalo zkusit toto - https://xtermjs.org/ - ale narozdil od toho shellinabox to vubec nema on-screen keyboard, hmmm…

Problém s NDP je ten že přes něj nejspíš neroutnu celý rozsah co mám. takže NDP asi padá.

Jinak ten xtermjs vypadá dobře a na mobilu to i funguje :smiley:.
Za zkoušku by to určitě stálo.

u v6 si zas muzes rict treba o dalsi /48 a neni problem, kdyz to zduvodnis nejak rozumne, tak muze bejt aj vic, klidne udelame celou zadost prefixu od RIPE :smiley: … a s nasim ASN budeme taky mit moznost propagovat dalsi ASka, takze i to by se dalo…

EDIT: cim chci rict, ze v6 jde routovat uplne nativne snadno, pokud netrvas na deleni na drobky…

u VPS by mi stačila jedna /128 a do KVM bych chtěl /48 (mám jednu) akorát nevim jak na to, a na internetu jsem nic nenašel, nebo jsem špatně hledal.

takze +1x /64 a v6 bude solved :slight_smile:

Vlastně i jednu /64 mám, ale to furt neřeší, že nevim jak na to :smiley:.
A taky to nemám k dispozici na playground pro vyzkoušení.
Na produkčním stroji to zkoušet nehodlám, když jsem rád, že mi to jede :smiley:.

No jenze tady potrebujes site dve, jednu priradis VPS primo na interface ve vpsAdminu, druhou nechas jako routovanou a tu pak vesele priradis na interface nejbliz k tomu QEMU a proste >routujes< :smiley: neni co resit :slight_smile:

  • teda toto neni podpora@vpsfree.cz, tady to Kerryk necte, protoze na podpore toho ma dost :slight_smile: o ty IPv6 prefixy navic teda prosim pripadne napis mailem mimo tady tu diskuzi :slight_smile: jestli ti chybi resourcy na zkouseni na pgnd, tak to spravi jedna veta smerem podpora@ :slight_smile:

Aha, ja vím že toto není podpora@vpsfree.cz, jen jsem chtěl nějak nasměrovat, protože jsem vůbec neměl tušení jak na to. Díky za nasměrování. Možná se mi i povede zbavit se 2 interface na KVM a budu jen s jednou.

ja jsem to taky nemyslel nijak zle, jen ze tady si toho vsimne nekdy za dlouho, jestli :slight_smile: a pridelovani resourcu pokud jede vsechno normalne resi prave Kerryk. Playground a staging jsou proste k dispozici, kdyz je to nekomu na neco potreba, staci si rict. Stejne se to flaka, ohledne prostredku, kterych je dost a nehrozi, ze dojdou nejak snadno, neni co resit :slight_smile:

13 posts were split to a new topic: Konzole ve vpsAdminu přes xterm.js

Tak zpět k původnímu tématu :smiley: pokročil jsem s testováním a mám úspěch a podařilo se mi vše dát do jednoho bridge se stejnou konfigurací že VPS a KVM mají v4 a v6. Zkoušel jsem snad všechno (ip neigh add proxy, SOLICITATION, různé routy apod.) abych zprovoznil v6 komunikaci mezi tap0 a eth0 a následně ven ale bez výsledku.
jsem rád alespoň, že se mi tohle povedlo. Trochu jsem bojoval s NATem ale nakonec jsem to ukecal :smiley:.
Dotaz nemůže to být tim, že je nějaká chyba v jádře? Třeba že to na fyzickém stroji funguje, ale už ne ve VPS kontejnerech?

Opět zpět k tématu jestli to ještě někdo čte :smiley:.
Povedlo se mi zprovoznit i verzi bez bridge. čistě KVM s tap0 bez bridge br0.
Možná tam nechám tu verzi s bridge. Ono to vyjde tak nějak na stejno (pro mě hlavní bylo se zbavit 2 interface pro KVM a mít jen jednu), ale alespoň jsem se přiučil novým věcem a to jak správně routovat a taky že link-local adresy nejsou routovatelný. Zajímavý, že na internetu toho moc není co se týká routovaní a nebo se to týká jiné situace.

1 Like

Ja jsem ale blbec, ze jsem se nad tim nezamyslel poradne, NDP/neigh proxy tady je k nicemu, to by simulovalo bridge-like chovani v situaci, kdy potrebujes pouzit bridge, ale nemuzes, protoze se ocekava, ze mas ty konkretni adresy primo na rozhrani, kde je pripojeni do netu (~priblizne receno);

To by asi vpsAdmin musel umet napridavat vic adres z jednoho subnetu na rozhrani a ty bys pak asi musel ty adresy odebirat po startu (nebo delat dalsi kejkle s konfiguraci rozhrani, ktere jinak manazuje vpsAdmin stack, obvykle pro jednoduchost, ne tak ale v tomhle pripade, no) - a prave pres neigh/arp proxy to preposilat na dalsi iface (bridge s QEMUs)…

Routed setup tady je nativni zpusob, jak delame veci, protoze nam staci resit celou sit jen na L3 urovni, mame uplne minimalni L2 domeny, co to jen jde (2 mac adresy v kazde).

Routovat site pres adresu z nejake dalsi site je nativni zpusob, jak propojujeme vsechno, akorat pro v4 to vypada trochu aliensky, kdyz se predava /32 adresa dal tak, aby ji mohl pouzit novy network namespace pro link do sveta - uplne analogicky by se poslala o dalsi uroven dal do QEMU, taky s nejakou vymyslenou /32 protiadresou pouzitou na default gw v tom QEMU, s odpovidajici /32 routou via interface primo. Ta vymyslena default gw adresa nemusi byt propagovana na zadne vyssi ani nizsi urovne (akorat se musi menit tak, aby se nepotkavala jedna ze dvou smeru v jednom net namespace). My ji btw v tom nadrazenem net ns prirazujeme na dummy iface osrtr0.

Ze link-local adresy jsou neroutovatelny, jj, ale to nevylucuje routovani neceho dalsiho pres link-local adresy mezi tema koncema, co na sebe skrz ty ll adresy vidi :slight_smile:

IMHO nejlepsi setup je rict si o /24(/25, /26) internich v4 a ty pak preroutovat na bridge s KVMkama (a nechat tam radit dnsmasq pres libvirt). Analogicky routed setup s v6 a autoconfig na strane bridge s KVMkama.

Na ty interni v4 jde pak presmerovat traffic z konkretnich portu z te verejky, jinak pujdou do netu pres nas spolecny NAT.

Co takhle?

Vůbec nejsem expert a né uplně vše jsem pochopil co píšeš (nic ve zlém jen já jsem tatar a stále se učím :smiley:)
Já úplně nepotřebuju /24 interních v4. stačí mi dummy 172.18.1.1/24(možná i menší) jen čistě komunikace VPS(172.18.1.1)-KVM(172.18.1.2)
Kde veškerý provoz z KVM jde ven zkrze NAT a příchozí provoz je kromě 2 portů přesměrován na dummy IP KVM(172.18.1.2)
na playground jsem vyzkoušel toto:
U v6 na interface eth0(výstupní síť) je ip 2a03:3b40:fe:7ac::1/64 na tap0(interface do KVM) jsem přiřadil 2a03:3b40:fe:7ac::2/64
na KVM jsem přidal adresy 2a03:3b40:29::1/48 a 2a03:3b40:fe:7ac::3/64
a routy na KVM
“ip r add 2a03:3b40:fe:7ac::1 via 2a03:3b40:fe:7ac::2 dev eth0”
“ip r add default via 2a03:3b40:fe:7ac::1 nexthop via 2a03:3b40:fe:7ac::2 dev eth0”
a routy na VPS
“ip r add 2a03:3b40:fe:7ac::3 dev tap0”
a default byla neměněná
a takhle to fungovalo podmínka byla to že routa musela být “2a03:3b40:29::/48 via 2a03:3b40:fe:7ac::1”
právě když jsem si hrál s link-local adresama bez bridge tak jsem zjistil, že na VPS interface eth0(fe80::2c1f:ceff:feb0:3741/64) a tap0(fe80::2c1f:ceff:feb0:3742/64) na sebe nikdy neuvídí a to jsem zkoušel variantu, že by routa byla veth_routed čili by měla použít gw toho eth0(měnící se link-local adresa)
ale protože přes link-local adresy vidí na sebe jen tap0 a KVM tak jsem to víceméně vzdal, že tudy to asi bez bridge nepůjde.
Ono reálně to je asi jedno jestli je routa “2a03:3b40:29::/48 via 2a03:3b40:fe:7ac::1” nebo veth_routed(výstup na eth0) jen si mi to takhle nelíbí - myslím “2a03:3b40:29::/48 via 2a03:3b40:fe:7ac::1” (ano asi jsem divnej :smiley:)
když mám variantu kde eth0 a tap0 jsou v bridgi br0 tak pro v6 jako gw použiji nastavenou link-local adresu(statická) toho eth0 a v případě NAT pro v4 mi stačilo přidat jedno pravidlo do iptables a chodí to.
Stačí mi staticky nastavená síť.
Prostě mi to chodí a jsem spokojenej :smiley:.
jinak VPS slouží jen jako host pro KVM nic jiného na VPS nikdy běžet nebude(teda kromě ssh a vnc do KVM).
P.S. doufám, že nepíšu ptákoviny a je to alespoň trochu srozumitelné.
P.S. nic jako libvirt a virt-manager nepoužívám