Android hotspot: provoz odchází na data místo do WireGuardu

Mám problém s "prostřelením" trafficu  zařízení připojených na Hotspot android telefonu, jehož spojení do internetuju jsou klasicky data LTE. Chci komunikovat do sítě 10.0.2.0/24 (rozsah adres wg interface) a 192.168.6.0/24 (propojená síť na třetím peerovi). Přímo z telefonu samotného mi vše funguje OK (to znamená že se v pořádku dostanu na  interní rozsah tunelu 10.0.2.x ale i na .192.168.6.x na naroutové síti na třetím peeru za 2 naty po schodech nahoru a třetí zatáčka vlevo)

Telefon má jedno wg rozhraní s jedním peerem (veřejná IP). Tento PC má 2 peery (zmíněný telefon a klienta právě pro připojení té naroutované sítě. Pro jednoduchost lze uvažovat, jako kdyby naroutovaná sít 192.168.6.0 byla na tom veřejném PC. Z toho důvodu, že na zadaný stroj totiž žádný paket nedorazí  (traffic původem z hotspot klienta ne, ale z samotného smartphonu ano )- viz dole

Zjištění: na veřejný PC nedorazí žádný traffic (na any rozhraní) pokud si chci z zařízení na hotpotu připojit na 192.168.6.x i 10.0.2.x

Na smartphonu je hotspot řešen s geniální fíčurkou že síť hotspotuje je 192.168.RANDOM.0/24 a je natován samozřejmě (projistotu z 192.168.RANDOM.random  :o ).
Z telefonu naopak odchází pakety z CGNAT adresy 100.x.x.x na 192.168 nebo 10.0. z rozhraní rmnet_dataX (ihned potom, co je přijat paket z wlan0 z 192.168.164.123 )
To je podle mě klíčový problém , tipl bych špatné pořadí pravidel pro wg a pro hotspot / PREROUTING a POSTROUTING. Zkoušel  jsem samozřejmě volbu Allow hotspot clients to use VPN On/off. a taky různé pořadí zapnutí wg a hotspotu
 
Jistě, ať má zařízení na hotspotu jakoukoli ip, a ť mu ji přiděluje dhcp an tom androidu, ale ať mi to funguje (současně ale se to musí nějak natovat, abych na protější peerovi nemusel laborovat s allowed-ips)

Chci to vyřešit nějak seamless, abych při každém zapnutí nemusel hledat , které číslo z 192.168.(2-254).0 je rozsah sítě  nebo si vzpomínat že mám přidávat další iptables pravidlo. Telefon má LineageOS < Android 11. Jak to řešit pokud možno elegantně? 

 !!! Dle mě jde nějakou ch

Další pozorování: tento wireguard program dle mého zjištění v telefonu není považován z VPN jako takovou.
Nezkoušel jsem Options Disable kernel module backend.

Mám oficiální com..wireguard.android nástroj
 Konfig je:
Interface: Adresa 10.0.2.10/24
Peer: Allowed 10.0.2.0/24,192,168.6/24, endpoint : blažek.com:99999  :-X


ip r hlásí
(default routa na androidech jaksi schází ve výpisu)
10.0.2.0/24 dev wg-phone src ... _.2.10
100.116.123.40/30 dev rmnetdata src ... _.123.42
192.168.69.0/24 dev wlan1 src ... _.69.234

root mám (jinak bych asi těžko spustil sudo -c  tcpdump ) . Ještě jednou, spojení do světa je přes LTE(100.x.x.x) a k wifině nejsem připojen (pro jistotu to zmiňuji), hotspot jen je zapnutý .  A připojení z samotného telefonu funguje bezvadně

« Poslední změna: 02. 09. 2022, 14:11:10 od Petr Krčmář »


Vyřeší routování na hotspotu androidu změna kernel/user-wireguardu
« Odpověď #1 kdy: 03. 09. 2022, 18:41:53 »
Má domněnka je, že pakety do rozhraní wireguardu v telefonu ani nepřitečou
Koukám, že se nikdo neosmělil. Má poznámka Nezkoušel jsem volbu userpsace režim oproti kernelspace backend v nastavení appky možná má určitou váhu.
 Jelikož wireguard pak:
  • skutečně se v androidu jeví jako VPN
  • rozhraní má ale jiné jméno (kernel: přímo název položky názvu rozhraní v appce ; userpace: tun0
  • sakra, vím že to byly 3 body, ale nevzpomenu si.


Jen bohužel, na nefunkčnost to nemá vliv. To jsem psal dřív (že to posílá traffic na LTE rohraní) teď už není pravda: (wlan1):192.168.123.44 → 10.0.2.naproti
(rmnetdata):100.119.123.456 → 10.0.2.naproti
,  nevím proč přesně , patrně tou změnou KERNEL → USER.)
Další poznámka:  Nyní. telefon na zpátky wifi klientům posílá ICMP  NETWORK unreachable.  Tato změna  (ICMP nebo misrouting))je způsobená Volbou ALLOW CLIENTS USE VPN,  kterou jsem zminoval

(užiteční: su; tcpdump -nti any "port 80 || icmp  || udp")


Proč to nejde, když se to jeví růžově (routa 10.0.2.0/24 je v ip route)?
« Poslední změna: 03. 09. 2022, 18:50:44 od Ħαℓ₸℮ℵ ␏⫢ ⦚ »