Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: waclaw 13. 12. 2023, 09:17:19
-
Ahoj,
rad bych pozadal o pomoc s na prvni pohled s velmi jednoduchou veci, bohuzel nejsem schopen prijit na to proc to nefunguje...
situace:
server - brana (fedora) ipv4 lan/wan (nat)
klient (win10) ipv4
Pres ipv4 vse funguje/routuje.
Zridil jsem si ipv6 wireguard /48 tunel a na serveru pro nej nastavil inet6 rozhrani s adresami:
2a03:3b40:xxx:1::/64 a 2a03:3b40:200::xxx/128,
pro lan rozhrani jsem nastavil 2a03:3b40:xxx::/64 a pro radvd stejny prefix a dns.
Klient dostane ipv6 adresu, internet ipv6 krasne funguje jak na serveru i na klientu.
Nefunguje jen jedna vec: klient se nedostane na wan rozhrani serveru (ping, web...) na 2a03:3b40:xxx:1::
Nechapu proc, ip forwarding zapnut, routovani by melo byt spravne, na fw zadne omezeni neni.
Pakety od klienta jsou videt na lan rozhrani, ale na wan se nedostanou.
$ip -6 r
unreachable ::/96 dev lo metric 1024 pref medium
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 pref medium
unreachable 2002:a00::/24 dev lo metric 1024 pref medium
unreachable 2002:7f00::/24 dev lo metric 1024 pref medium
unreachable 2002:a9fe::/32 dev lo metric 1024 pref medium
unreachable 2002:ac10::/28 dev lo metric 1024 pref medium
unreachable 2002:c0a8::/32 dev lo metric 1024 pref medium
unreachable 2002:e000::/19 dev lo metric 1024 pref medium
2a03:3b40:200::xxx dev inet6 proto kernel metric 256 pref medium
2a03:3b40:xxx::/64 dev lan proto kernel metric 256 pref medium
2a03:3b40:xxx:1::/64 dev inet6 proto kernel metric 256 pref medium
unreachable 3ffe:ffff::/32 dev lo metric 1024 pref medium
fe80::/64 dev inet proto kernel metric 256 pref medium
fe80::/64 dev lan proto kernel metric 256 pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev tun1 proto kernel metric 256 pref medium
Predem dekuji za pomoc.
-
Chápu správně, že na serveru je ukončený ten wireguardový tunel?
A ten prefix 2a03:3b40:xxx:1::/64 je nastavený na tom wireguardovém rozhraní? Jaký to má význam?
Adresa se samými nulami v posledních 64 bitech má speciální význam (https://datatracker.ietf.org/doc/html/rfc2526), takže je lepší vybrat nějakou jinou. Ale to by nemělo představovat velký problém.
Pakety od klienta jsou videt na lan rozhrani, ale na wan se nedostanou.
Pokud jsou ty pakety cílené na IP adresu, která patří serveru, je jasné, že se na wan rozhraní neobjeví, když už tím, že přišly do serveru dorazily do svého cíle.
Nicméně, proč daná adresa neodpovídá, není úplně jasné. Může to být spousta důvodů.
-
Chápu správně, že na serveru je ukončený ten wireguardový tunel?
Ano.
A ten prefix 2a03:3b40:xxx:1::/64 je nastavený na tom wireguardovém rozhraní? Jaký to má význam?
Dobrá otázka. Myšlenka byla mít jeden rozsah ipv6 na wan (inet6) a druhý na lan (lan).
Adresa se samými nulami v posledních 64 bitech má speciální význam (https://datatracker.ietf.org/doc/html/rfc2526), takže je lepší vybrat nějakou jinou. Ale to by nemělo představovat velký problém.
Díky, neznal jsem, opraveno na 2a03:3b40:xxx::1/64.
Pokud jsou ty pakety cílené na IP adresu, která patří serveru, je jasné, že se na wan rozhraní neobjeví, když už tím, že přišly do serveru dorazily do svého cíle.
Nicméně, proč daná adresa neodpovídá, není úplně jasné. Může to být spousta důvodů.
Prozatím jsem to vyřešil tím, že jsem na wg rozhraní nechal jen 2a03:3b40:200::xxx/128 a vnější adresu serveru 2a03:3b40:xxx::1/64 přesunul na lan, kam klient vidí.
-
Jak máš udělanout ipv6 konektivitu - ta je nativní po WAN, nebo ji dostáváš přes nějaký tunel taky?
Když uděláš obrázek, tak nejen, že asi dostaneš lepší radu, ale během kreslení na to asi rovnou přijdeš.
-
IPv6 je pres Wireguard tunel od vpsFree.
Bohuzel, badal jsem nad tim hodne dlouho a na nic racionalniho jsem neprisel :D
-
IPv6 je pres Wireguard tunel od vpsFree.
oki.
jestli je to recentní fedora, tak tam máš asi firewalld, že... ten používá zóny..
Chceš si zkontrolovat:
* jestli máš (ipv4) uplink v public zóně
* jestli máš interface wg tunelu do vpsFree taky v public zóně
pak
* jestli máš lan interface v nějaké trusted/internal zóně
v tomhle momentě ten základ je celkem ok.
Pak si v /etc/firewalld/firewalld.conf
nastav
LogDenied=unicast a otoč firewalld.
A teď si zkus poslat nějaký traffic (curl, wget) na ten public interface. Projde to? A když ne, máš v dmesg nějaký návodný deny?
-
Chceš si zkontrolovat:
* jestli máš (ipv4) uplink v public zóně
* jestli máš interface wg tunelu do vpsFree taky v public zóně
pak
* jestli máš lan interface v nějaké trusted/internal zóně
v tomhle momentě ten základ je celkem ok.
Pak si v /etc/firewalld/firewalld.conf
nastav
LogDenied=unicast a otoč firewalld.
A teď si zkus poslat nějaký traffic (curl, wget) na ten public interface. Projde to? A když ne, máš v dmesg nějaký návodný deny?
Nemám firewalld, používám Shorewall. Ale přesně tohle jsem ověřoval, zóny, atd., všechno vypadá ok.
Nicméně jsem zkusil na to inet6 rozhraní dát adresu 192.168.3.1/24 a světe div se, na tu se z klienta dostanu, takže firewall by měl být ok.
dmesg nic zahozeného neukáže.
Bude to nějaká kulišárna, úplná blbost řekl bych. Vždycky to tak je, jen to člověk na první pohled hned nevidí.
-
Tohle ukáže wireshark...
-
Nemám firewalld, používám Shorewall.
Shorewall byl dřív oblíbenou nastavbou iptables, ale současné EL-like systémy už iptables nemají - je tam command iptables který je ale jen nějaký alias..? Není možný, že ta chyba je v tom?
-
Na zkoušku jsem kompletně odstranil všechna pravidla pro firewall a nechal vše na ACCEPT, stejně nefunguje, pes bude zakopán jinde :(
-
Routovací tabulka se mi zdá v pořádku...
2a03:3b40:200::xxx dev inet6 proto kernel metric 256 pref medium
2a03:3b40:xxx::/64 dev lan proto kernel metric 100 pref medium
2a03:3b40:xxx:1::/64 dev inet6 proto kernel metric 256 pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev tun1 proto kernel metric 256 pref medium
fe80::/64 dev inet proto kernel metric 1024 pref medium
fe80::/64 dev lan proto kernel metric 1024 pref medium
tak tedy jinak, packet požadavku na 2a03:3b40:xxx:1::1 přijde ze sítě 2a03:3b40:xxx::/64, ten přijme rozhraní lan (na tom je ještě vidět ve wiresharku), co se s ním děje pak, jak se dostane na inet6 v jehož rozsahu je adresa požadavku? Ke službě se, jak to vypadá, nedostane.
-
Routovací tabulka se mi zdá v pořádku...
hmmm, a máš to rozhraní inet6 - tedy endpoint tunelu, a lan opravdu v jiných sítích?
Není třeba jedna omylem podsítí druhé..?
-
Routovací tabulka se mi zdá v pořádku...
hmmm, a máš to rozhraní inet6 - tedy endpoint tunelu, a lan opravdu v jiných sítích?
Není třeba jedna omylem podsítí druhé..?
To by neměly, lan (2a03:3b40:xxx::/64) i wan (2a03:3b40:xxx:1::/64) mají různý prefix /64, tunel je pro /48.
Nemůže být problém, že wg inet6 rozhraní nemá jako jediné přiřazenu link-local adresu?
-
...
prosímtě hoď sem výstup ip a s
a tvoje specifický čtveřice nahraď třeba "beef". ať z toho není IPv6 coming out. Ale stejný 4-byty nahraď stejnou náhradou, a jiný jinou, ať je z toho jasný, co je stejný, a co je jiný.
Asi všichni tady tušíme, jakej má prefix VPSfree, takže ten začátek cenzurovat nemusíš.
-
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: inet: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:e0:4c:ab:37:be brd ff:ff:ff:ff:ff:ff
altname enp5s0
inet 46.11.11.18/29 brd 46.11.11.23 scope global noprefixroute inet
valid_lft forever preferred_lft forever
inet 46.11.11.19/29 brd 46.11.11.23 scope global secondary noprefixroute inet
valid_lft forever preferred_lft forever
inet 46.11.11.20/29 brd 46.11.11.23 scope global secondary noprefixroute inet
valid_lft forever preferred_lft forever
inet 46.11.11.21/29 brd 46.11.11.23 scope global secondary noprefixroute inet
valid_lft forever preferred_lft forever
inet6 fe80::16a6:140d:67e4:3984/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:1b:21:98:44:aa brd ff:ff:ff:ff:ff:ff
altname enp3s0
inet 192.168.1.1/24 brd 192.168.1.255 scope global noprefixroute lan
valid_lft forever preferred_lft forever
inet6 2a03:3b40:beef::1/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::884b:fc92:16a6:2fb6/64 scope link noprefixroute
valid_lft forever preferred_lft forever
25: inet6: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet6 2a03:3b40:beef:1::1/64 scope global
valid_lft forever preferred_lft forever
inet6 2a03:3b40:200::beef/128 scope global
valid_lft forever preferred_lft forever
-
musím říct, že tam nevidím nic vyloženě špatně.
Celkem mi přijde zajímavý, proč máš na tom wireguard iface dvě IP - tu druhou jsi tam přidal ručně, nebo si ji tam wireguard přidal sám?
A z toho serveru samotnýho ta služba je dostupná?
-
Tu sem tam přidal sám, ale to není důležité, kolik jich tam je, klient se nedostane ani na jednu.
[Interface]
Address = 2a03:3b40:200::beef, 2a03:3b40:beef:1::1/64
Zkusil jsem ještě s úplně stejnou konfigurací fw udělat to rozhraní pomocí sit tunelu na he.net, funguje bez problému, klient pingne adresu na inet6, nechápu, možná něco s wg adaptérem.
-
A z toho serveru samotnýho ta služba je dostupná?
IPv6 internet je dostupný jak ze serveru, tak od klienta, jediný problém je, že se klient nedostane na IP wanu wireguard rozhraní (inet6). Prostě záhada. Ale mělo by to jít lehce reprodukovat, stačí si vytvořit vpsFree wg tunel a nastavit na lan a wan dva různý /64 rozsahy.
-
Ten ipv6 forwarding si povoloval jak?
sysctl -w net.ipv6.conf.all.forwarding=1
-
Ten ipv6 forwarding si povoloval jak?
sysctl -w net.ipv6.conf.all.forwarding=1
To dělá Shorewall.
-
IPv6 internet je dostupný jak ze serveru, tak od klienta, jediný problém je, že se klient nedostane na IP wanu wireguard rozhraní
co to znamená nedostane? Nepřistoupí na službu na něm běžící? Nebo mu nejde ping?
A dostaneš se na tu službu z toho serveru samotnýho?
Ještě vyjeď sysctl -a | grep forw
-
Ten ipv6 forwarding si povoloval jak?
sysctl -w net.ipv6.conf.all.forwarding=1
To dělá Shorewall.
Jo? A mohl bych to videt? Plus rovnou vypis pravidel pro ipv6.
-
co to znamená nedostane? Nepřistoupí na službu na něm běžící? Nebo mu nejde ping?
A dostaneš se na tu službu z toho serveru samotnýho?
Z klienta nejde na wan (inet6) ping ani zadna jina sluzba (web, ...). Ze serveru vse samozrejme funguje.
Ještě vyjeď sysctl -a | grep forw
net.ipv4.conf.all.bc_forwarding = 0
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.bc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.enp4s0.bc_forwarding = 0
net.ipv4.conf.enp4s0.forwarding = 1
net.ipv4.conf.enp4s0.mc_forwarding = 0
net.ipv4.conf.inet.bc_forwarding = 0
net.ipv4.conf.inet.forwarding = 1
net.ipv4.conf.inet.mc_forwarding = 0
net.ipv4.conf.inet6.bc_forwarding = 0
net.ipv4.conf.inet6.forwarding = 1
net.ipv4.conf.inet6.mc_forwarding = 0
net.ipv4.conf.lan.bc_forwarding = 0
net.ipv4.conf.lan.forwarding = 1
net.ipv4.conf.lan.mc_forwarding = 0
net.ipv4.conf.lo.bc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.sit0.bc_forwarding = 0
net.ipv4.conf.sit0.forwarding = 1
net.ipv4.conf.sit0.mc_forwarding = 0
net.ipv4.conf.tap0.bc_forwarding = 0
net.ipv4.conf.tap0.forwarding = 1
net.ipv4.conf.tap0.mc_forwarding = 0
net.ipv4.conf.tun0.bc_forwarding = 0
net.ipv4.conf.tun0.forwarding = 1
net.ipv4.conf.tun0.mc_forwarding = 0
net.ipv4.conf.tun1.bc_forwarding = 0
net.ipv4.conf.tun1.forwarding = 1
net.ipv4.conf.tun1.mc_forwarding = 0
net.ipv4.conf.wg0.bc_forwarding = 0
net.ipv4.conf.wg0.forwarding = 1
net.ipv4.conf.wg0.mc_forwarding = 0
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.enp4s0.forwarding = 1
net.ipv6.conf.enp4s0.mc_forwarding = 0
net.ipv6.conf.inet.forwarding = 1
net.ipv6.conf.inet.mc_forwarding = 0
net.ipv6.conf.inet6.forwarding = 1
net.ipv6.conf.inet6.mc_forwarding = 0
net.ipv6.conf.lan.forwarding = 1
net.ipv6.conf.lan.mc_forwarding = 0
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.lo.mc_forwarding = 0
net.ipv6.conf.sit0.forwarding = 1
net.ipv6.conf.sit0.mc_forwarding = 0
net.ipv6.conf.tap0.forwarding = 1
net.ipv6.conf.tap0.mc_forwarding = 0
net.ipv6.conf.tun0.forwarding = 1
net.ipv6.conf.tun0.mc_forwarding = 0
net.ipv6.conf.tun1.forwarding = 1
net.ipv6.conf.tun1.mc_forwarding = 0
net.ipv6.conf.wg0.forwarding = 1
net.ipv6.conf.wg0.mc_forwarding = 0
Ale jak jsem psal vyse, s uplne stejnou konfiguraci, jen kdyz je ten interface inet6 vytvoren jako 6to4 pomoci sit na he.net, tak vse funguje, takze si myslim, ze tady byt problem nemuze. Uz si vazne zacinam myslet, ze je chyba ve wireguard modulu.
-
Ten ipv6 forwarding si povoloval jak?
sysctl -w net.ipv6.conf.all.forwarding=1
To dělá Shorewall.
Jo? A mohl bych to videt? Plus rovnou vypis pravidel pro ipv6.
Pokud myslis vypis nastaveni forwardovani, tak vyz vyse.
Jak jsem psal vyse nefunguje to ani kdyz ipv6 pravidla vymazu a vsechno nastavim na ACCEPT, plus jeste ze se stejnym nastavenim je ten inet6 interface dostupny pro klienta pokud je vytvoren pomoci sit namisto wireguard. Takze ve firewallu bych chybu nehledal.
-
Může to být něco se síťovým ovladačem Wireguardu, který je v některých ohledech trochu speciální. V každém případě dávat na rozhraní Wireguardu prefix /64 nedává smysl, v podstatě to říká, že část svého prefixu posíláš zpátky do upstreamu. Doporučuju přidat adresu prefix:1::1 třeba na loopback. nebo jakékoli jiné rozhraní. Ale beztak by v tom neměl být rozdíl v porovnání s tím, když budeš pro server používat adresu prefix::1. Na wireguardovém rozhraní pak nemusíš mít vůbec žádnou adresu.
-
Může to být něco se síťovým ovladačem Wireguardu, který je v některých ohledech trochu speciální. V každém případě dávat na rozhraní Wireguardu prefix /64 nedává smysl, v podstatě to říká, že část svého prefixu posíláš zpátky do upstreamu. Doporučuju přidat adresu prefix:1::1 třeba na loopback. nebo jakékoli jiné rozhraní. Ale beztak by v tom neměl být rozdíl v porovnání s tím, když budeš pro server používat adresu prefix::1. Na wireguardovém rozhraní pak nemusíš mít vůbec žádnou adresu.
To je můj workaroud, dát celý /48 rozsah třeba na lan rozhraní.
Nicméně problém je tady, že na wg rozhraní serveru se klient nedostane ať má jakoukoliv adresu třeba i jedinou a03:3b40:200::beef.
Taky věřím, že problém bude někde ve wireguardu ovladači.
Mohl by to někdo ověřit? Stačí mít dva stroje, jeden (server) s eth lan (/64 rozsah) a wg wan (jedna adresa nebo jiný /64 rozsah) a druhý stroj (klient), který dostane ip z rozsahu lan serveru. A zkusit z klienta pingnout wg wan rozhraní serveru.
-
To je můj workaroud, dát celý /48 rozsah třeba na lan rozhraní.
To mi připomnělo, že možná stojí za to upozornit všechny majitele IPv6 prefixu, kteří jej routují na obyčejném Linuxu, že je v každém případě rozhodně dobrý nápad nastavit celý prefix jako Unreachable (https://kb.vpsfree.cz/informace/projekty/ipv6tunel#nastavte_prideleny_blok_jako_unreachable). Jinak veškerý provoz pro nepřidělené podsítě zvoní na poslední míli. (To zní skoro až poeticky :D)
-
Mohl by to někdo ověřit? Stačí mít dva stroje, jeden (server) s eth lan (/64 rozsah) a wg wan (jedna adresa nebo jiný /64 rozsah)
Mám router s OpenWRT, na něm tunel, na jeho rozhraní je adresa prefix:200::XXX/128 a tahle adresa je zcela bez problému pingnutelná z vnitřní sítě používající zcela jiný prefix.
-
Mohl by to někdo ověřit? Stačí mít dva stroje, jeden (server) s eth lan (/64 rozsah) a wg wan (jedna adresa nebo jiný /64 rozsah)
Mám router s OpenWRT, na něm tunel, na jeho rozhraní je adresa prefix:200::XXX/128 a tahle adresa je zcela bez problému pingnutelná z vnitřní sítě používající zcela jiný prefix.
Zajímavé, asi to bude více specifické, možná závislé na verzi wireguard modulu.
Zkoušel jsem ještě OpenVPN interface jak si mi posílal konfiguraci (díky!) a ten je přístupný pro klienta bez problémů.
Zkusím to ještě na Mikrotiku nebo virtualním stroji, ať se vidí, kde je problém.
-
Zkusil jsem uplne cistou Fedoru 39 ve virtualu, uplne to samy, wg wan /128 nedostupny.
-
Jeste jsem zkusil Ubuntu Server 22.04.3 LTS (5.15.0), to same jako Fedora 39 (6.6.6).
-
Vaše adresy a jejich přiřazení k rozhraním mi přijdou špatně ze dvou důvodů:
1) adresa končící 64 nulovými bity (zápis končící :: se většinou používá jen k pravidlům pro rozsah, třeba ip -6 route... nebo ip6tables),
2) adresa přiděleného rozsahu na WAN rozhraní.
Na WAN ponechte pouze 2a03:3b40:200::xxx/128, která je pouze pro routovací účely od poskytovatele a leží mimo Váš rozsah.
2a03:3b40:xxx:1::/64 změňte na 2a03:3b40:xxx:1::1/64 a dejte na LAN rozhraní. Neobávejte se dostupnosti, tato adresa bude přístupná z veřejného internetu, pokud tomu nezabrání pravidlo v ip6tables.
Ještě mě napadá jedna finta, jak udělat funkční adresu končící nulami - větší rozsah, který má 64 nul uvnitř. Třeba zápisem 2a03:3b40:xxx:3::/63. (Všimněte si, že Vámi zmíněný 2a03:3b40:xxx::/64 je tím nedotčený, proto ta trojka místo jedničky.) To ale nemůže fungovat s radvd, které vyžaduje /64. Je to prostě akorát na zkoušku a v praxi prasárna. Zkuste to podle prvního odstavce a určitě to půjde. Držím palce!