Nas toegangsprobleem vanaf intern netwerk [Opgelost]

[Briolet]

Het blijft natuurlijk vreemd dat het bij mij mis gaat en deze bug nergens anders gemeld wordt. Wat is bij mij anders. Ik weet wel dat ik een paar maand geleden een Wifi-dongel in de USB poort gestopt heb. Bij het aanmaken van de extra Wifi interface via DSM om de dongel als extra Wifi-accesspoint te kunnen gebruiken, zijn alle oude iptables gewist en waren mijn firewall rules weer leeg.

Dat was nog onder DSM 5.0 en is het enige wat misschien niet standaard is en wel met interfaces te maken heeft.

[BartS]

....Regel 8,9,10 zijn de IP adressen die Synology nodig heeft voor support, dan zie ik dus direct hoeveel data zij via telnet, ssh, poort 5000. bekeken hebben, of zie ik dat verkeerd?

Zoveel weet ik ook weer niet, dus dat kan ik je niet vertellen  . Maar is telnet echt nodig voor Synology? Ik heb ze nooit meer dan 22 en 5000 hoeven geven. Op zich heb je telnet zo wel dichtgetimmerd, maar toch...

Ik heb de meeste problemen opgelost zodat het werkbaar geworden is. Ik denk dat het beter is als Synology dit probleem oplost. Dan kunnen ze de oplossing van dit probleem ook in een volgende update verwerken zodat anderen er ook wat aan hebben. Ik gebruik alleen Synology pakketten, dus iets in hun software heeft dit probleem veroorzaakt.

Het wordt inderdaad wel een ingewikkeld verhaal... Het lijkt wel naar de NAS te wijzen, maar ik begin te vermoeden dat de firewall niet het probleem is. T.z.t. hoor ik natuurlijk graag wat Synology voor oorzaak heeft gevonden.

Het viel me wel op dat pingen zal gaan lukken vanaf de eerste 4 10.0.1.x adressen.

Waar maak je dat uit op? Een ping vanaf die adressen werkt niet en ook een ping vanaf de nas naar die adressen werkt niet.

Oeps, typefoutje. Ik bedoelde dat pingen naar de NAS zou moeten werken, maar alleen vanaf de 4 Mac's: voor de andere locale adressen staat er nergens ICMP of 'all protocol' open. Vandaar ook dat ik denk dat het probleem niet in de firewall zit.

En het is inderdaad alleen het 10.0.1.x subnet van de nas. Mijn router hangt al jaren achter een andere router in het 10.0.3.x subnet. Apparaten in dat subnet kan ik wel pingen. Ik heb nu ook in Security Station het IP adres van de kameras vervangen door het WAN IP van mijn router (10.0.3.10) Nu ik de cameras via dat subnet benader, ziet de nas ze weer.

Ik gebruik Security Station niet, ik kan niet helemaal volgen wat je hebt gedaan. Heb je de camera's het adres van de router zelf gegeven, of heb je ze nu een adres gegeven in de 10.0.3.0 range?

Maar wat veroorzaakt het probleem dan? Het is dus alleen het eigen subnet wat niet goed werkt.
mDNS/Bonjour?: misschien omdat het broadcast/multicast address niet open staat?

Maar dan nog zou pingen van de NAS naar een 10.0.1.x adres moeten werken.
Toch een routeringsprobleem? Misschien toch de moeite waard om hier even naar te kijken met 'ip route' of 'netstat -r'? Misschien levert 'traceroute' ook wat interessants op.
En al geprobeerd om zonder de Wifi-dongle te starten (ik weet niet of dat veel werk is?)

Je zei dat het ook niet werkt als je de firewall helemaal uitzet: dat is eigenlijk nog wel een indicatie dat die niet het probleem is (waren toen wel alle caches en tables refreshed?)
Als je firewall problemen toch wilt uitsluiten zou je kunnen loggen welke packets allemaal gedropped worden. Laat maar weten, dan post ik een kleine instructie.

(Misschien ben ik een beetje paranoide, maar misschien beter je firewall instellingen van het forum te halen?)

[Briolet]

Ik gebruik Security Station niet, ik kan niet helemaal volgen wat je hebt gedaan. Heb je de camera's het adres van de router zelf gegeven, of heb je ze nu een adres gegeven in de 10.0.3.0 range? …
…
(Misschien ben ik een beetje paranoide, maar misschien beter je firewall instellingen van het forum te halen?)

De oplossing voor Security Station is een beetje off-topic.
In de nas stond de camera op 10.0.1.31 met poort 80
Nu heb ik er staan 10.0.3.10 met poort xxxx
Dat is de WAN kant van de router en via nat-loopback en port forwarding verbindt hij gewoon weer op de camera 10.0.1.31 en poort 80. Alleen de nas ziet de camera nu als zijnde in een ander subnet.

Voor de firewall regels is het inderdaad paranoïde om ze te verbergen.

Maar is telnet echt nodig voor Synology? Ik heb ze nooit meer dan 22 en 5000 hoeven geven.

Ik weet het ook niet. Volgens hun mail wel:

Remote Access Instructions
===============================================================
1. Standard Ports we need you to open: 23, 80, 5000
2. Please enable the TELNET and SSH function in Web Management of your Synology NAS. ([Network Service] > [Terminal] )

Vreemd is natuurlijk dat in regel 1 helemaal geen poort 22 genoemd wordt en in regel 2 willen ze wel SSH toegang. 

Er kloppen wel meer dingen niet. Ik heb gisteren de bugmelding gedaan. Via de nieuwe support instelling in DSM heb ik alvast een syslog gedownload. Dat was een 19 MB groot bestand dat ik aan de bugmelding toegevoegd heb. Volgens die pagina mag het attachment 30MB groot zijn, toch kwam de melding terug dat het attachment te groot was.
Dus later die dag heb ik de melding nog eens gedaan en zag in het berichten centrum dat de melding verstuurd is en door de grote belangstelling voor DSM 5.0 kon een reactie wel 3 à 5 dagen duren.
Volgens mij bedoelen ze DSM 5.1, en is deze melding zelf ook nog een bug.

[BartS]

Ah ok, ik heb ook zoiets met loopback geknutseld voor OpenVPN: hoef ik het server adres niet aan te passen als ik lokaal wil testen.

Bij mij vonden ze SSH genoeg: blijkbaar verschillen de meningen daar.
En ach, wat kleine type-/update foutjes hier en daar... Zolang het maar niet in de config files is 

[Briolet]

Je zou met ip route, netstat, arp, nslookup etc. kunnen kijken of je iets raars ziet gebeuren

Ik heb een traceroute gedaan:

Code: [Selecteer]

iMac-DDR2-2:~ briolet $ traceroute gedeeldedata.local
traceroute to gedeeldedata.local (10.0.1.30), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  * * *
^C

[hier heb ik mijn switch (Netgear SG108) gereset]

iMac-DDR2-2:~ briolet$ ping 10.0.1.30
PING 10.0.1.30 (10.0.1.30): 56 data bytes
64 bytes from 10.0.1.30: icmp_seq=0 ttl=64 time=0.334 ms
64 bytes from 10.0.1.30: icmp_seq=1 ttl=64 time=0.238 ms
64 bytes from 10.0.1.30: icmp_seq=2 ttl=64 time=0.216 ms
64 bytes from 10.0.1.30: icmp_seq=3 ttl=64 time=0.247 ms
64 bytes from 10.0.1.30: icmp_seq=4 ttl=64 time=0.217 ms
64 bytes from 10.0.1.30: icmp_seq=5 ttl=64 time=0.215 ms
64 bytes from 10.0.1.30: icmp_seq=6 ttl=64 time=0.237 ms
64 bytes from 10.0.1.30: icmp_seq=7 ttl=64 time=0.242 ms
64 bytes from 10.0.1.30: icmp_seq=8 ttl=64 time=0.228 ms
64 bytes from 10.0.1.30: icmp_seq=9 ttl=64 time=0.300 ms
64 bytes from 10.0.1.30: icmp_seq=10 ttl=64 time=0.278 ms
64 bytes from 10.0.1.30: icmp_seq=11 ttl=64 time=0.269 ms
64 bytes from 10.0.1.30: icmp_seq=12 ttl=64 time=0.261 ms
^C

--- 10.0.1.30 ping statistics ---
13 packets transmitted, 13 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.215/0.252/0.334/0.034 ms
iMac-DDR2-2:~ briolet $ traceroute gedeeldedata.local
traceroute: unknown host gedeeldedata.local

Het probleem lijkt toch niet in de nas gezeten te hebben, maar in mijn switch. Maar waarom mijn twee iMacs, die aan dezelfde switch hangen als de nas, wel volledig op het interne netwerk kunnen komen is mij onduidelijk.
En waarom is dit probleem ontstaan bij de update. En als het alleen aan de switch lag, waarom het security station gedurende een reboot wel kort toegang tot de interne cameras. Het moet toch iets te maken hebben met de manier waarop de nas de switch aanspreekt.  (Als je naar Jumbo Frames overschakelt moet je ook altijd de switch resetten.)

Ik zie nu ook dat Cloud Station op mijn twee iMacs weer gaat synchroniseren.

Wat ik nog vreemd vind aan het traceroute commando, is dat hij bij de eerste keer het IP van de host vind, en na de reset, praat over een 'unknown' host.