Ontbrekende route?

[Kasper1985]

Mijn vraag
Ik ben al een aantal dagen bezig met iets te troubleshooten waarvan ik nu misschien de oorzaak gevonden heb.

Ik heb een tvheadend draaien op het ene vlan en de clients wil ik in een ander vlan hebben. Nou werkte dit voorheen door tvheadend te draaien op een rpi2. Daarop werkte het out of the box. Om redenen wilde ik echter de USB tuner verplaatsen naar de Ubuntu server die toch al draaide. Alleen dit krijg ik met geen mogelijkheid aan de praat.
Hier ben ik verbonden met VLAN 20 waar de clients in moeten komen naar het hoofd VLAN.

code:

 traceroute 192.168.1.6
traceroute to 192.168.1.6 (192.168.1.6), 30 hops max, 60 byte packets
 1  _gateway (192.168.20.1)  12.909 ms  12.909 ms  12.894 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *

Dat gaat dus niet goed. Zo te zien moet ik dus ergens een route toevoegen.

Dit is de interface op de Ubuntu server:

code:

# Ethernet
allow-hotplug eno1
auto eno1
iface eno1 inet static
  address 192.168.1.6
  netmask 255.255.255.0
  gateway 192.168.1.1
  dns-nameserver 192.168.1.1
  dns-nameserver 1.1.1.1
  dns-nameserver 1.0.0.1

Wat ik niet weet is waar ik die route dan moet toevoegen (server/router etc) en hoe.
...
Relevante software en hardware die ik gebruik
Edge router 4
Ubuntu 18 server (ifdown/up geen netplan)
2x Edge switches

Wat ik al gevonden of geprobeerd heb
Rond gezocht en geprobeerd om routes toe te voegen op de Edge router maar tot nu toe zonder veel succes

[Arthion-nl]

Kasper1985,

Ik ben met jou verhaal niet bekend maar mij valt dit op:

1 _gateway (192.168.20.1) 12.909 ms 12.909 ms 12.894 ms

en in de Ubuntu server:

netmask 255.255.255.0
gateway 192.168.1.1

Misschien mis ik iets of gaat dit buiten mijn kennis om maar ik zie dat je 1 subnet hebt en beide gateways zitten in andere subnet.

Ligt het probleem misschien daar?

[jvanhambelgium]

@Arthion-nl , da's een ander VLAN, de client zit in VLAN20 met range 192.168.20.x en die Ubuntu bak staat op een andere VLAN (zal de VLAN1 /standaard zijn met range 192.168.1.x
Je zou denken dat het vanzelf moet gaan, beide LAN-segmenten zijn "directly connected" op de L3-router (hier dus de Edge Router 4)

=> Kan je vanop de Edge Router vlot beide kanten pingen ?
=> Doet die EdgeRouter iets van "security" / filtering oid ?

[Kasper1985]

Hier is een screenshot van de routes in de Edgerouter 4:



@jvanhambelgium Het is uiteindelijk de bedoeling om VLAN 20 van VLAN 1 te scheiden dmv firewall regels en alleen selectief dingen door te laten. Maar die firewall regels staan nu volledig uit. Ze zijn niet gekoppelt aan een interface in de Edge router.


Hier ping ik ubuntu vanaf de edge router:

code:

 ping 192.168.1.6
PING 192.168.1.6 (192.168.1.6) 56(84) bytes of data.
64 bytes from 192.168.1.6: icmp_req=1 ttl=64 time=0.328 ms
64 bytes from 192.168.1.6: icmp_req=2 ttl=64 time=0.185 ms
64 bytes from 192.168.1.6: icmp_req=3 ttl=64 time=0.274 ms
64 bytes from 192.168.1.6: icmp_req=4 ttl=64 time=0.192 ms
64 bytes from 192.168.1.6: icmp_req=5 ttl=64 time=0.170 ms
64 bytes from 192.168.1.6: icmp_req=6 ttl=64 time=0.196 ms
64 bytes from 192.168.1.6: icmp_req=7 ttl=64 time=0.205 ms
^C
--- 192.168.1.6 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 5995ms
rtt min/avg/max/mdev = 0.170/0.221/0.328/0.055 ms

ping 192.168.20.107
PING 192.168.20.107 (192.168.20.107) 56(84) bytes of data.
64 bytes from 192.168.20.107: icmp_req=1 ttl=128 time=0.319 ms
64 bytes from 192.168.20.107: icmp_req=2 ttl=128 time=0.250 ms
64 bytes from 192.168.20.107: icmp_req=3 ttl=128 time=0.246 ms
64 bytes from 192.168.20.107: icmp_req=4 ttl=128 time=0.291 ms
64 bytes from 192.168.20.107: icmp_req=5 ttl=128 time=0.240 ms
64 bytes from 192.168.20.107: icmp_req=6 ttl=128 time=0.249 ms
64 bytes from 192.168.20.107: icmp_req=7 ttl=128 time=0.241 ms
64 bytes from 192.168.20.107: icmp_req=8 ttl=128 time=0.228 ms
64 bytes from 192.168.20.107: icmp_req=9 ttl=128 time=0.257 ms
^C
--- 192.168.20.107 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 7995ms
rtt min/avg/max/mdev = 0.228/0.257/0.319/0.034 ms

[Thralas]

jvanhambelgium schreef op woensdag 11 december 2019 @ 21:11:
Je zou denken dat het vanzelf moet gaan, beide LAN-segmenten zijn "directly connected" op de L3-router (hier dus de Edge Router 4)

Exact dit. Dat is wat een router doet, tenzij je zelf filtering rules toevoegt.

Uit het screenshot en de pings maak ik op dat je router beide subnets prima weet te bereiken, dus het probleem is waarschijnlijk een filter. En dat hoeft niet perse op de router te zijn - ik zou ook even de host firewalls checken tav. verkeer van buiten het eigen subnet.

En vergeet tcpdump niet. Als je op de Ubuntu-machine kijkt of je pings aankomen weet je direct waar het probleem zit.

Die statische route in het screenshot is overigens wel erg dubieus, maar gezien 'in FIB: no' lijkt me die niet actief - logisch ook, want de destination zou de router zelf zijn als ik het goed begrijp, maar hij zit zelf direct in dat subnet.

[jvanhambelgium]

"Firewall regels staan volledige uit" ? Zeker dat er geen default deny staat die verkeer tussen die segmenten kan verhinderen ? Totaal niks in de logs van de EdgeRouter te zien ?

Kan je als test vanaf de EdgeRouter nog eens beide kanten pingen MAAR nu wel het source-IP meegeven van de het ander segment ? Hopelijk kan je dit net zo simpel doen als op een Cisco.

Dus vb ping naar 192.168.20.107 met source 192.168.1.1
Ping naar 192.168.1.6 met source 192.160.20.107

[Kasper1985]

Thralas schreef op woensdag 11 december 2019 @ 21:39:
[...]


Exact dit. Dat is wat een router doet, tenzij je zelf filtering rules toevoegt.

Uit het screenshot en de pings maak ik op dat je router beide subnets prima weet te bereiken, dus het probleem is waarschijnlijk een filter. En dat hoeft niet perse op de router te zijn - ik zou ook even de host firewalls checken tav. verkeer van buiten het eigen subnet.

En vergeet tcpdump niet. Als je op de Ubuntu-machine kijkt of je pings aankomen weet je direct waar het probleem zit.

Die statische route in het screenshot is overigens wel erg dubieus, maar gezien 'in FIB: no' lijkt me die niet actief - logisch ook, want de destination zou de router zelf zijn als ik het goed begrijp, maar hij zit zelf direct in dat subnet.

Die static routes waren een (falende) poging van mij om het te fixen. Die heb ik alweer weg gehaald. Ik vind routing op de een of andere manier erg ingewikkeld.

Ja ik begin ook steeds meer de host te verdenken Ik heb IPtables volledig geflushed. ufw (wat ik altijd gebruikte) staat volledig uit sinds ik een edge router gebruik waar gewoon een firewall op draait.

Ik kan verder niet zoveel bedenken wat het zou kunnen zijn. Maar aangezien het op de rpi wel werkte is het inderdaad logisch dat het deze Ubuntu bak is.

Ik moet maar eens in tcpdump gaan duiken. Zou zo nu niet weten hoe ik dat hierop toe kan passen.

@jvanhambelgium Ik zou niet weten hoe ik een andere source kan toevoegen aan een ping? Wist niet eens dat dat mogelijk is

Bedankt zover!

Edit: @Thralas Ik heb dit uit de edgerouter packet capture weten te pakken. Dit is exact het verkeer waar het om gaat 192.168.20.108=Nvidia Shield 192.168.1.6=tvheadend server.

Ik heb alleen wat moeite met de interpretatie ervan

code:

 21:16:28.372604    IP 192.168.20.108.43098 > 192.168.1.6.9981: Flags [S], seq 653217421, win 65535, options [mss 1460,sackOK,TS val 24230966 ecr 0,nop,wscale 7], length 0
21:16:29.402483 IP 192.168.20.108.43098 > 192.168.1.6.9981: Flags [S], seq 653217421, win 65535, options [mss 1460,sackOK,TS val 24231224 ecr 0,nop,wscale 7], length 0
21:16:29.402560 IP 192.168.20.108.43098 > 192.168.1.6.9981: Flags [S], seq 653217421, win 65535, options [mss 1460,sackOK,TS val 24231224 ecr 0,nop,wscale 7], length 0
21:16:31.418499 IP 192.168.20.108.43098 > 192.168.1.6.9981: Flags [S], seq 653217421, win 65535, options [mss 1460,sackOK,TS val 24231728 ecr 0,nop,wscale 7], length 0
21:16:31.418569 IP 192.168.20.108.43098 > 192.168.1.6.9981: Flags [S], seq 653217421, win 65535, options [mss 1460,sackOK,TS val 24231728 ecr 0,nop,wscale 7], length 0
21:16:33.512255 IP 192.168.20.108.43100 > 192.168.1.6.9981: Flags [S], seq 1761391088, win 65535, options [mss 1460,sackOK,TS val 24232251 ecr 0,nop,wscale 7], length 0
21:16:33.512364 IP 192.168.20.108.43100 > 192.168.1.6.9981: Flags [S], seq 1761391088, win 65535, options [mss 1460,sackOK,TS val 24232251 ecr 0,nop,wscale 7], length 0
21:16:34.522621 IP 192.168.20.108.43100 > 192.168.1.6.9981: Flags [S], seq 1761391088, win 65535, options [mss 1460,sackOK,TS val 24232504 ecr 0,nop,wscale 7], length 0
21:16:34.522682 IP 192.168.20.108.43100 > 192.168.1.6.9981: Flags [S], seq 1761391088, win 65535, options [mss 1460,sackOK,TS val 24232504 ecr 0,nop,wscale 7], length 0
21:16:36.538743 IP 192.168.20.108.43100 > 192.168.1.6.9981: Flags [S], seq 1761391088, win 65535, options [mss 1460,sackOK,TS val 24233008 ecr 0,nop,wscale 7], length 0
21:16:36.538817 IP 192.168.20.108.43100 > 192.168.1.6.9981: Flags [S], seq 1761391088, win 65535, options [mss 1460,sackOK,TS val 24233008 ecr 0,nop,wscale 7], length 0
21:16:38.696121 IP 192.168.20.108.43102 > 192.168.1.6.9981: Flags [S], seq 2908920593, win 65535, options [mss 1460,sackOK,TS val 24233547 ecr 0,nop,wscale 7], length 0
21:16:38.696262 IP 192.168.20.108.43102 > 192.168.1.6.9981: Flags [S], seq 2908920593, win 65535, options [mss 1460,sackOK,TS val 24233547 ecr 0,nop,wscale 7], length 0
21:16:39.706861 IP 192.168.20.108.43102 > 192.168.1.6.9981: Flags [S], seq 2908920593, win 65535, options [mss 1460,sackOK,TS val 24233800 ecr 0,nop,wscale 7], length 0
21:16:39.706924 IP 192.168.20.108.43102 > 192.168.1.6.9981: Flags [S], seq 2908920593, win 65535, options [mss 1460,sackOK,TS val 24233800 ecr 0,nop,wscale 7], length 0

[ Voor 51% gewijzigd door Kasper1985 op 11-12-2019 22:22 ]

[Thralas]

Dat zegt al een heleboel, ondanks het feit dat je niet expliciet maakt op welke interface dat is.

Je ziet namelijk ieder pakketje (TCP SYN, in dit geval) viermaal, waarvan tweemaal met exact dezelfde timestamp. Dat kan niet anders betekenen dan dat je met deze capture zowel de inkomende als uitgaande interface captured, en je hier dus een pakketje de router ziet binnenkomen én verlaten.

De interval van 1s met hetzelfde sequence no. is een retransmit, want de TS val is wél anders

Dat betekent dat je ervanuit kunt gaan dat je Ubuntu-machine het verkeer wel ontvangt (bonus: ga dit na dmv. tcpdump aldaar) en dáár het probleem zit.

Ik vermoed dat je een firewall hebt op je Ubuntu-machine en die het dropt.

[Kasper1985]

@Thralas Dankjewel!

Ik tast echt in het duister. Ik heb vanmiddag al de IPtables volledig geflushed. VPN staat uit. UFW staat uit.

Het enige wat ik me kan bedenken is dat docker rare dingen aan het uithalen is met IPtables. Heb weleens vaker meegemaakt dat docker aanpassingen maakt aan iptables die niet helemaal gewenst zijn.

Ik ga er verder induiken. Dankjewel!

[Kasper1985]

@Thralas ongelofelijk... maar er was inderdaad *iets* op de host dat fout stond.

Ik heb gelukkig /home en de rest op aparte partities staan. Heb Ubuntu opnieuw geinstalleerd en voila het werkt.

Nu maar hopen dat het blijft werken als ik de rest installeer.