Android accepteert statische route niet van dnsmasq

[lenwar]

Mijn vraag:

Mijn Android telefoons accepteren geen statische routes die mijn DNSMasq mee stuurt.
Ik heb een VPSje draaien die met ik met een VPN-tunnel in m'n lokale netwerk beschikbaar wil maken. Ik heb hiervoor een Raspberry Pi met een Wireguard installatie.
Al mijn apparaten kunnen bij m'n VPSje, behalve m'n Android apparaten. Na een kort onderzoekje kwam ik er achter dat m'n Android toestellen geen statische routes overnemen van de DHCP-configuratie.

Ik heb dit probleem zowel met Android 7.x als 8.x.

M'n netwerk ziet er zo uit:
Lokaal netwerk

Netwerk:            192.168.0.0/24
Raspberry pi:       192.168.0.100
Wireguard:          10.0.0.1/24

VPS:

Wireguard:          10.0.0.2/24

Relevante DNSMasq configuratieregel op de raspberry pi:

dhcp-option=121,10.0.0.0/24,192.168.0.100

Mijn Windows client ontvangt netjes:

10.0.0.0    255.255.255.0   192.168.0.100   192.168.0.221     47

en kan dus gewoon communiceren.

Mijn Android toestellen lijken de dhcp-optie te negeren.
Na wat pluizen kwam ik er achter dat Android meerdere routeringstabellen gebruikt met prioritering.

# ip route
10.172.14.172/30 dev rmnet_data0  proto kernel  scope link  src 10.172.14.173
192.168.0.0/24 dev wlan0  proto kernel  scope link  src 192.168.0.235
# ip rule show
0:      from all lookup local
10000:  from all fwmark 0xc0000/0xd0000 lookup legacy_system
10500:  from all oif dummy0 uidrange 0-0 lookup dummy0
10500:  from all oif wlan0 uidrange 0-0 lookup wlan0
10500:  from all fwmark 0x40000/0x40000 oif rmnet_data0 uidrange 0-0 lookup rmnet_data0
13000:  from all fwmark 0x10063/0x1ffff lookup local_network
13000:  from all fwmark 0x10079/0x1ffff lookup wlan0
13000:  from all fwmark 0x50064/0x5ffff lookup rmnet_data0
14000:  from all oif dummy0 lookup dummy0
14000:  from all oif wlan0 lookup wlan0
14000:  from all fwmark 0x40000/0x40000 oif rmnet_data0 lookup rmnet_data0
15000:  from all fwmark 0x0/0x10000 lookup legacy_system
16000:  from all fwmark 0x0/0x10000 lookup legacy_network
17000:  from all fwmark 0x0/0x10000 lookup local_network
19000:  from all fwmark 0x79/0x1ffff lookup wlan0
22000:  from all fwmark 0x0/0xffff lookup wlan0
23000:  from all fwmark 0x0/0xffff uidrange 0-0 lookup main
32000:  from all unreachable
#
# ip route show table wlan0
default via 192.168.0.1 dev wlan0  proto static
192.168.0.0/24 dev wlan0  proto static  scope link

Ik heb vervolgens de route direct in de wlan0 tabel gezet:

# ip route show table wlan0
default via 192.168.0.1 dev wlan0  proto static
192.168.0.0/24 dev wlan0  proto static  scope link
#
# ip route add table wlan0 10.0.0.0/24 via 192.168.0.100
# ip route show table wlan0
default via 192.168.0.1 dev wlan0  proto static
10.0.0.0/24 via 192.168.0.100 dev wlan0
192.168.0.0/24 dev wlan0  proto static  scope link

Nu kan hij dus wel communiceren met mijn VPSje:

# ping mijnvps.local.lan
PING mijnvps.local.lan (10.0.0.2) 56(84) bytes of data.
64 bytes from mijnvps.local.lan (10.0.0.2): icmp_seq=1 ttl=63 time=29.5 ms
64 bytes from mijnvps.local.lan (10.0.0.2): icmp_seq=2 ttl=63 time=47.6 ms
64 bytes from mijnvps.local.lan (10.0.0.2): icmp_seq=3 ttl=63 time=68.0 ms

Heeft iemand een idee hier over?
- Is het mogelijk om via DNSMasq aan te geven dat de route in een specifieke tabel moet komen?
- Ik wil liever niet m'n raspberry pi als standaardroute gebruiken
- Ik wil liever ook niet via Tasker (oid) een taakje maken dat de route toevoegd zodra ik op m'n lokale netwerk in log
- Ik wil eigenlijk dat het gewoon via de DHCP-configuratie gaat

[Brahiewahiewa]

Hoe geef je de route door? Via optie 121, classless routing?
Dan moet je ook de default gateway als classless route opgeven

[Snake]

Brahiewahiewa schreef op vrijdag 9 maart 2018 @ 00:49:
Hoe geef je de route door? Via optie 121, classless routing?
Dan moet je ook de default gateway als classless route opgeven

Doet hij toch?

code:

dhcp-option=121,10.0.0.0/24,192.168.0.100

En ik zit even mee te kijken op Google, en je bent niet de enigste met dit probleem.

[lenwar]

Brahiewahiewa schreef op vrijdag 9 maart 2018 @ 00:49:
Hoe geef je de route door? Via optie 121, classless routing?
Dan moet je ook de default gateway als classless route opgeven

Daar heb je een goed punt. Ik heb de RFC er is bijgepakt en inderdaad. Onder het kopje "client behaviour"

   If the DHCP server returns both a Classless Static Routes option and
   a Router option, the DHCP client MUST ignore the Router option.

wat inderdaad impliceert dat de default gateway ook opgenomen moet worden als classless route. Verderop staat het er ook woordelijk:

DHCP Server Administrator Responsibilities

   Many clients may not implement the Classless Static Routes option.
   DHCP server administrators should therefore configure their DHCP
   servers to send both a Router option and a Classless Static Routes
   option, and should specify the default router(s) both in the Router
   option and in the Classless Static Routes option.

   When a DHCP client requests the Classless Static Routes option and
   also requests either or both of the Router option and the Static
   Routes option, and the DHCP server is sending Classless Static Routes
   options to that client, the server SHOULD NOT include the Router or
   Static Routes options.

Ik ga hier vanavond is naar kijken en laat wel weten of het goed gekomen is
Wel jammer dat nog Android, nog Microsoft, nog Apple (iOS apparaten lijken hetzelfde te reageren als Android) zich aan de RFC houdt. (uiteraard om de boel draaiend te houden, maar het maakt het troubleshooten niet makkelijker )
En tevens is het jammer dat dnsmasq de SHOULD NOT niet naleeft.

[Belgar]

Dan ga je ervan uit dat de client dus een "Classless Static Routes" aanvraag doet. Ik denk niet dat je DNSMASQ zonder meer kunt beschuldigen zich niet aan de standaard te houden zonder te verifiëren of de gestuurde DHCP request daaraan voldoet. Als de telefoon geen optie 55-33 meegeeft dan is dnsmasq in principe niet fout.

zeg niet dat het zo is, maar het hoeft geen fout in dnsmasq te zijn

[lenwar]

Voor allen die het interessant vinden. Ik ben er uit. Android vraagt geen Classless Static Routes aan. Ik heb even de uitgebreide DHCP-logging van dnsmasq aangezet en die laat netjes zien wat er wordt aangevraagd en wat er wordt aangeboden.

Android verzoekt:

requested options: 1:netmask, 3:router, 6:dns-server, 15:domain-name,
requested options: 26:mtu, 28:broadcast, 51:lease-time, 58:T1,
requested options: 59:T2, 43:vendor-encap

Windows verzoekt:

requested options: 1:netmask, 3:router, 6:dns-server, 15:domain-name,
requested options: 31:router-discovery, 33:static-route, 43:vendor-encap,
requested options: 44:netbios-ns, 46:netbios-nodetype, 47:netbios-scope,
requested options: 121:classless-static-route, 249, 252

iOS verzoekt

requested options: 1:netmask, 121:classless-static-route, 3:router,
requested options: 6:dns-server, 15:domain-name, 119:domain-search,
requested options: 252

Android is dus de enige van de drie die geen 121:classless routes aanvraagt.
To zover mijn probeersel dus... MAAR. dnsmasq heeft een 'feature' (aldanniet gedocumenteerd), dat als er geen Default Gateway wordt geconfigureerd (dhcp optie 3), dan stuurt hij hetgeen op dat hij hetgeen dat bij optie 121 staat als extra default gateway.

Dit biedt dus mogelijkheden.
Android apparaten krijgt de routes via Classless Static Routes (die uiteindelijk als Default Gateways opgestuurd worden waardoor de Android apparaten dus twee default gateways krijgen. Niet optimaal maar functioneel werkt het in elk geval.
En niet-android apparaten krijgen een Default Gateway en ook de Classless Static Routes opgestuurd:

dhcp-vendorclass=set:telefoons,android-dhcp
dhcp-option=tag:telefoons,121,10.0.0.0/24,192.168.0.100,0.0.0.0/0,192.168.0.1
dhcp-option=tag:#telefoons,3,192.168.0.1
dhcp-option=tag:#telefoons,121,10.0.0.0/24,192.168.0.100

En voor @Belgar. Ik heb nu dus even gelijk kunnen controleren: dnsmasq stuurt naar Windows als iOS zowel de classless static routes als de default routes op.

Typerend genoeg houden die beide DHCP-clients zich ook niet aan de RFC, want ze gebruiken de Default Gateway van optie 3.

[ik222]

Maar waarom zorg je niet gewoon dat je VPS via de default gateway van je clients bereikbaar is? Dat is in mijn ogen veel netter en handiger dan wat je nu doet.

[Brahiewahiewa]

lenwar schreef op vrijdag 9 maart 2018 @ 20:31:
...Typerend genoeg houden die beide DHCP-clients zich ook niet aan de RFC, want ze gebruiken de Default Gateway van optie 3.

Ik heb een paar jaar geleden een korte discussie gehad met de auteur van DHClient. Die stelde zich idd op het standpunt dat de RFC zegt dat het zo moet. De dhcp-stack van windows en iOS zijn wat vergevingsgezinder, net als die van freeBSD

[lenwar]

ik222 schreef op vrijdag 9 maart 2018 @ 20:55:
Maar waarom zorg je niet gewoon dat je VPS via de default gateway van je clients bereikbaar is? Dat is in mijn ogen veel netter en handiger dan wat je nu doet.

Ben ik helemaal met je eens. Maar ik kan geen routes om mijn Horizon box instellen. En ik heb geen andere router in m'n netwerk (en wil m'n raspberry pi niet als default gateway gaan gebruiken)

[lenwar]

Brahiewahiewa schreef op vrijdag 9 maart 2018 @ 21:14:
[...]

Ik heb een paar jaar geleden een korte discussie gehad met de auteur van DHClient. Die stelde zich idd op het standpunt dat de RFC zegt dat het zo moet. De dhcp-stack van windows en iOS zijn wat vergevingsgezinder, net als die van freeBSD

Dan vraag ik me oprecht af hoe ze onderstaande interpreteren: (onder het kopje Client Behavior)

   If the DHCP server returns both a Classless Static Routes option and
   a Router option, the DHCP client MUST ignore the Router option.

Daar staat toch vrij letterlijk MUST ignore, waar MUST betekend (RFC 2119/BCP 14)

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

Volgens mij laat het weinig aan de fantasie over, maar ik ben dan ook geen software developer, misschien dat die een andere kijk op taal hebben

Maar goed. Onder aan de streep heb ik nu een werkende situatie, al vraag ik me af waar Android nu m'n default gateway vandaan verzint (192.168.0.1) want die wordt nergens aangeboden aan m'n Android apparaten.