FreeNAS via Subnet erreichen für CIFS Freigabe
-
ok…
Würdest Du mir das kurz näher erklären? Reicht es die Subnets, die auf den NAS sollen auf IPV6 umzustellen, oder wie darf ich das verstehen?
Eine andere Alternative wäre dann nur, alles was mit dem NAS kommunizieren soll, in ein Subnet zu packen?
oh man... :-[
-
Reicht es die Subnets, die auf den NAS sollen auf IPV6 umzustellen, oder wie darf ich das verstehen?
Die ausgehenden Rules noch IPV6 aktivieren, natürlich muss IPV6 auch auf NAS und PC aktiviert sein bzw. das unterstützen.
Bei IPV 6 ist Multicast aktuell, nicht mehr Broadcast.
Wissen tu ich 's auch nicht, aber vermuten….;-) -
Das mit IPV6 scheint aber auch nicht wirklich die Lösung unseres Problems zu sein.
Samba4 soll wohl auch noch nicht wirklich mit IPV6 umgehen können.
Als nächstes Problem habe ich mit OpenMediaVault und damit Debian-Wheezy nur ein Samba3.6 an Board.
Also weiter mit FTP oder NFS…..:(
Gruß orcape -
Hi,
habe das ganze nun nach Änderung der Samba-Version auf dem NAS in den Griff bekommen.
Weiterhin nur mit IPV4.
Allerdings ein reines Linux-Netz, zumindest meistens.;)
Auf den betreffenden Interfaces die Freigabe der Ports 137-139 oder eine any-to-any Rule.
Folgendes Tutorial….
http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-samba-network-browsing.html
Hier mal die Samba.conf des NAS….======================= Global Settings ======================= [global] workgroup = orca.net server string = NAS netbios name = skyflight interfaces = 127.0.0.0/8 172.16.7.0/24 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24 security = user domain master = yes local master = yes wins server = yes remote announce = 192.168.89.255 192.168.155.255 192.168.33.255 192.168.55.255 dns proxy = no log level = 0 syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 syslog only = yes panic action = /usr/share/samba/panic-action %d encrypt passwords = true passdb backend = tdbsam obey pam restrictions = yes unix password sync = no passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\$ pam password change = yes socket options = TCP_NODELAY IPTOS_LOWDELAY guest account = nobody load printers = no disable spoolss = yes printing = bsd printcap name = /dev/null unix extensions = yes wide links = no create mask = 0777 directory mask = 0777 use sendfile = yes aio read size = 16384 aio write size = 16384 null passwords = no time server = no wins support = yes #======================= Share Definitions ======================= [orca] path = /media/0dfd442f-28c4-421b-9b37-32570c3828e8/orca guest ok = no read only = no browseable = yes inherit acls = yes inherit permissions = no[global] workgroup = orca.net server string = server orca netbios name = orca interfaces = 127.0.0.0/8 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24 security = user encrypt passwords = true passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *p$ syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 os level = 64 local master = yes wins support = No wins server = 172.16.7.10 remote announce = 172.16.7.10 192.168.89.255 192.168.155.255 192.168.33.255 domain master = No dns proxy = No usershare allow guests = Yes panic action = /usr/share/samba/panic-action %d idmap config * : backend = tdb [orca] comment = Home Directories path = /home/orca/ valid users = %S admin users = root read only = No create mask = 0700 directory mask = 0700 guest ok = Yes public = Yes browseable = Yes ea support = no store dos attributes = no printable = no create mask = 0755 force create mode = 0644 directory mask = 0755 force directory mode = 0755 hide dot files = yes valid users = "orcape","Tino","orca","Kerstin" invalid users = read list = "Tino","Kerstin" write list = "orcape","orca"
Hier die Samba.conf eines Linux-Client….
[global] workgroup = orca.net server string = server orca netbios name = orca interfaces = 127.0.0.0/8 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24 security = user encrypt passwords = true passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *p$ syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 os level = 64 local master = yes wins support = No wins server = 172.16.7.10 remote announce = 172.16.7.10 192.168.89.255 192.168.155.255 192.168.33.255 domain master = No dns proxy = No usershare allow guests = Yes panic action = /usr/share/samba/panic-action %d idmap config * : backend = tdb [orca] comment = Home Directories path = /home/orca/ valid users = %S admin users = root read only = No create mask = 0700 directory mask = 0700 guest ok = Yes public = Yes browseable = Yes
Dabei befindet sich das NAS in einer DMZ an OPT1, Netzwerk 172.16.7.0/24.
Der Client im LAN, Netzwerk 192.168.155.0/24
Die Daten einfach entsprechend anpassen, sollte funktionieren.
Kleine Fehler in der Config sind mir zu verzeihen…..;)
Gruß orcape -
Ich weiß zwar nicht wie ihr von SMB/CIFS auf IPv6 kommt, aber die pfSense war bei solchen Problemen seltenst die Ursache. Meist ließ es sich runterbrechen auf:
- SAMBA war falsch konfiguriert (bspw. nur das Netz erlaubt, wo er drin steht und das andere Netz nicht)
- SMB Browsing hat nicht gepasst
- Freigaben falsch konfiguriert
- etc etc
Die pfSense an der Stelle ist höchst dumm zu betrachten und da Falke ja schon sagt, dass ihm Netzbrowsing wurscht ist, sollte dem auch nichts entgegen stehen. Ich hab hier ein NAS (Synology was ja Samba ist) im Netz stehen und keinerlei Problem von verschiedenen Netzen aus drauf zu browsen, selbst per Einwahl und OpenVPN ist das drin - und da wird auch nur geroutet und kein Broadcast oder sonstige dark magic (TM) vollzogen.
Insofern würde ich wie Rudi im anderen Thread raten, dir mal den FreeNAS genau anzusehen oder/und testweise einfach mal ne dumme Windows Kiste im gleichen Netz freizugeben und mit der mal zu testen (Vorsicht da die Firewall der Kiste). Am Ende ist es gar nicht die pfs (wie so oft) sondern ne ganz andere Stellschraube.
Grüße
-
Hi JeGr,
Ich weiß zwar nicht wie ihr von SMB/CIFS auf IPv6 kommt,
Zitat @flachfalke…
Beim eintichten habe ich mich eher auf die Benutzerechte konzentreirt und nicht an die Broadcast Probleme mit Windows Freigaben geadcht.
Da es Problem mit den Broadcasts bei IPV6 nicht mehr gibt, hatte ich das als Möglichkeit angesehen.
Leider habe ich dann hinterher gelesen, das Samba4 da auch noch Schwierigkeiten macht.…aber die pfSense war bei solchen Problemen seltenst die Ursache. Meist ließ es sich runterbrechen auf:
- SAMBA war falsch konfiguriert (bspw. nur das Netz erlaubt, wo er drin steht und das andere Netz nicht)
- SMB Browsing hat nicht gepasst
- Freigaben falsch konfiguriert
- etc etc
Das habe ich mittlerweile auch herausgefunden.
Bei mir lag nur das Problem vor, das ich auf dem OMV-NAS noch eine Samba3 Version laufen hatte.
Diese war nicht dazu zu überreden, mit meinen anderen Debian-Jessie PC ´s zusammen zu arbeiten, da hier schon Samba4 zum Einsatz kommt.
Jetzt habe ich das OMV (Wheezy) "gezwungen" Samba4 zu akzeptieren, was es mit einigem "murren" auch tut und schon funktioniert das NAS als domain master und die anderen PC ´s spielen mit.
Danke an @flachfalke, ich hätte ohne seinen Thread das Problem (welches eigentlich keines ist..;-)) wohl weiter vor mir hergeschoben.
Gruß orcape -
Diese war nicht dazu zu überreden, mit meinen anderen Debian-Jessie PC ´s zusammen zu arbeiten, da hier schon Samba4 zum Einsatz kommt.
Ja, 2x Samba unterschiedlicher Versionen… Unschön.
@flachfalke: aber auch in deinem Fall denke ich, dass es eben eher auf Samba Seite zu suchen ist, nicht an der pfSense. Hoffe du bleibst am Ball.
-
Danke an @flachfalke,…
Nicht dafür :) Aber freut mich, wenn man als Noob auch irgendwie etwas beitragen kann.
Ich bin absolut kein Crack und auf Linux basierten Dingen noch weniger. Darum zweifel ich grundlegend immer an meinem KnowHow und tue mich schwer ein Thread aufzumachen für Dinge, dir nach meiner Ansicht eigentlich funktionieren müssten.
Denn eigentlich will ich es nicht verstehen müssen, dass ein NAS keine CIFS über ein Subnet sichtbar bekommt für Windows…, aber nachdem orcape hier schrieb, dass ich besser meine Energie in ein Workaround stecke, hatte ich das vor. Aber bis heute bin ich zeitlich noch nicht dazu gekommen und freue mich grad auch darüber, denn JeGr macht mir doch wieder Hoffnung.
Den FreeNAS habe ich nämlich nur installiert in Sicht auf HDD und Dateisystem inkl. CIFS Freigaben und Benutzerrechten. SAMBA hab ich nicht konfiguriert/geändert. Hatte ich auch nie Bedarf dran, denn in meinem Netzwerk wo ich es eingerichtet habe bzw die Benutzerrechte und Co. getestet habe, steckte er immer im selben Netz mit allen Clients.
Aber wenn ich jetzt JeGr
- SAMBA war falsch konfiguriert (bspw. nur das Netz erlaubt, wo er drin steht und das andere Netz nicht)
lese und die ersten Zeilen von orcape Samba Config Datei, denke (und HOFFE) ich, dass dort mein Problem liegt. Denn da habe ich nie Hand dran angelegt.
Für mich allein war ich froh genug, dass ich von den Subnetzen pingen, nslookup und Co erfolgreich ausführen konnte und dachte damit ist die Sache geritzt?
Aber aus der Zeile hier:interfaces = 127.0.0.0/8 172.16.7.0/24 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24
von orcape entnehme ich peinlichst, dass man im SAMBA die Subnetze eintragen muss!? Zugegeben…sollte es daran liegen freu ich mir ja n Loch wohin, aber da wären wir auch wieder beim newbie meinerseits.
Hoffe du bleibst am Ball.
Wie du merkst, habt ihr mir Hoffnung gemacht. Ich bin gespannt…
Könnt ihr mir noch was mit auf den Weg für morgen geben? Also ich muss im NAS in der Samba Config die nötigen Subnetze hinzufügen und dann könnte es schon klappen?Greets!!
-
@flachfalke: ja man kann Samba durchaus beschränken, dass Anfragen nur aus bestimmten Netzen angenommen werden. Ob das bei dir der Fall ist kann ich nicht sagen, aber da wäre zumindest ein Ansatzpunkt :)
-
Gute Nachricht: Problem besteht nicht mehr!
Schlechte Nachricht: Keine Ahnung warum…Hab gestern Abend kreuz und quer gelesen und mir einige Dinge notiert, die ich ändern wollte:
- NETBIOS Namen müssen kleingeschrieben sein
- Allowed Hosts hinzufügen im NAS
- und noch mehr...
Aber als ich heute auf die "Baustelle" kam, hab ich mit dem NetBios Namen des NAS angefangen und nach dem Speichern, konnte ich ihn über den Windows Explorer erreichen :o
Zum gegencheck nochmal umgeändert, aber daran lag es wohl nicht. Also: Im Grunde habe ich nichts geändert, aber es klappt nun. Weiß der Geier warum.Am Wochenende hatte sich die pfSense zum zweiten mal in 9 Monaten verabschiedet und es fand ein Reboot statt. Aber wenn es daran liegen sollte...kann ich leider auch keine Erklärung dafür finden.
Natürlich freue ich mich, dass es klappt, aber es kommen die nächsten Probleme.Was nicht sein sollte, ist, dass wenn ich von verschiedenen PC's aus auf den NAS pinge, die Latenz stark schwankt. Von realen 1-3ms bis hin zu 150ms und mehr ist alles dabei.
Auffällig ist der Load average mit circa immer den Werten: 2.69, 2.38, 2.33, die auch mal über 3 klettern.
Die SystemActivity zeigt das dazu:
last pid: 69124; load averages: 2.48, 2.46, 2.37 up 0+03:56:43 19:10:06 185 processes: 9 running, 161 sleeping, 15 waiting Mem: 219M Active, 684M Inact, 548M Wired, 272K Cache, 414M Buf, 2461M Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 256 root 138 20 6908K 1404K CPU1 1 185:57 96.00% /usr/local/sbin/check_reload_status 10 root 171 ki31 0K 32K RUN 0 71:11 48.00% [idle{idle: cpu0}] 10 root 171 ki31 0K 32K RUN 1 131:15 19.97% [idle{idle: cpu1}] 67561 root 55 0 150M 38068K RUN 0 0:00 1.95% /usr/local/bin/php 0 root -16 0 0K 192K sched 0 0:57 0.00% [kernel{swapper}] 11 root -32 - 0K 272K RUN 0 0:52 0.00% [intr{swi4: clock}] 11 root -68 - 0K 272K RUN 0 0:31 0.00% [intr{irq257: re1}] 61062 root 76 0 157M 49568K accept 0 0:19 0.00% /usr/local/bin/php{php} 0 root -68 0 0K 192K - 0 0:13 0.00% [kernel{dummynet}] 3 root -8 - 0K 16K - 0 0:07 0.00% [g_up] 11 root -68 - 0K 272K WAIT 0 0:06 0.00% [intr{irq19: ath0 atap}] 29496 root 76 20 8296K 1888K wait 0 0:06 0.00% /bin/sh /var/db/rrd/updaterrd.sh 4 root -8 - 0K 16K - 0 0:04 0.00% [g_down] 13 root -16 - 0K 16K - 0 0:03 0.00% [yarrow] 11 root -32 - 0K 272K WAIT 0 0:02 0.00% [intr{swi4: clock}] 84962 root 64 20 12160K 7120K select 0 0:02 0.00% /usr/local/sbin/ntpd -g -c /var/etc/ntpd. 42964 root 64 20 5784K 1484K select 0 0:02 0.00% /usr/local/sbin/apinger -c /var/etc/aping 55780 root 44 0 24232K 4600K kqread 0 0:02 0.00% /usr/local/sbin/lighttpd -f /var/etc/ligh
alle paar Sekunden kommen die "savevoucher" und "filter_sync" PIDs dazu
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 256 root 134 20 6908K 1404K RUN 1 186:31 77.98% /usr/local/sbin/check_reload_status 79333 root 128 20 152M 33476K CPU0 0 0:00 53.96% /usr/local/bin/php -f /etc/rc.filter_sync 10 root 171 ki31 0K 32K RUN 1 131:41 43.99% [idle{idle: cpu1}] 68114 root 126 20 162M 50864K RUN 0 0:03 41.99% /usr/local/bin/php -f /etc/rc.savevoucher
Über die Suche nach "/usr/local/sbin/check_reload_status" kommen zig Threads hier im Forum, auf die es keine mir Verständliche Lösung gibt. Manche haben aufgrund dies die pfSense neu aufgesetzt oder geupdatet.
Einn Thread gibt es, wo alle 5 Minuten die Voucher und Firewall Regeln neu gesynct werden, was ihm auffällig vorkam. Bei mir, passiert das alle paar Sekunden!Feb 10 18:19:08 check_reload_status: Synching vouchers Feb 10 18:19:07 check_reload_status: Synching vouchers Feb 10 18:18:45 check_reload_status: Syncing firewall Feb 10 18:18:42 check_reload_status: Syncing firewall Feb 10 18:18:38 check_reload_status: Synching vouchers Feb 10 18:18:38 check_reload_status: Synching vouchers Feb 10 18:18:14 check_reload_status: Syncing firewall Feb 10 18:18:11 check_reload_status: Syncing firewall Feb 10 18:18:05 check_reload_status: Synching vouchers Feb 10 18:18:05 check_reload_status: Synching vouchers Feb 10 18:17:44 check_reload_status: Syncing firewall Feb 10 18:17:41 check_reload_status: Syncing firewall Feb 10 18:17:37 check_reload_status: Synching vouchers Feb 10 18:17:37 check_reload_status: Synching vouchers Feb 10 18:17:05 check_reload_status: Synching vouchers Feb 10 18:17:05 check_reload_status: Synching vouchers Feb 10 18:16:43 check_reload_status: Syncing firewall Feb 10 18:16:40 check_reload_status: Syncing firewall Feb 10 18:16:36 check_reload_status: Synching vouchers Feb 10 18:16:36 check_reload_status: Synching vouchers Feb 10 18:16:09 check_reload_status: Syncing firewall Feb 10 18:16:08 check_reload_status: Syncing firewall Feb 10 18:16:04 check_reload_status: Synching vouchers Feb 10 18:16:04 check_reload_status: Synching vouchers Feb 10 18:15:41 check_reload_status: Syncing firewall Feb 10 18:15:39 check_reload_status: Syncing firewall Feb 10 18:15:35 check_reload_status: Synching vouchers Feb 10 18:15:35 check_reload_status: Synching vouchers Feb 10 18:15:14 check_reload_status: Syncing firewall Feb 10 18:15:12 check_reload_status: Syncing firewall Feb 10 18:15:03 check_reload_status: Synching vouchers Feb 10 18:15:03 check_reload_status: Synching vouchers Feb 10 18:14:38 check_reload_status: Syncing firewall Feb 10 18:14:35 check_reload_status: Syncing firewall Feb 10 18:14:31 check_reload_status: Synching vouchers Feb 10 18:14:31 check_reload_status: Synching vouchers Feb 10 18:14:02 check_reload_status: Synching vouchers Feb 10 18:14:02 check_reload_status: Synching vouchers Feb 10 18:13:33 check_reload_status: Syncing firewall Feb 10 18:13:32 check_reload_status: Syncing firewall Feb 10 18:13:23 check_reload_status: Synching vouchers Feb 10 18:13:23 check_reload_status: Synching vouchers Feb 10 18:12:49 check_reload_status: Synching vouchers Feb 10 18:12:49 check_reload_status: Synching vouchers Feb 10 18:12:32 check_reload_status: Syncing firewall Feb 10 18:12:26 check_reload_status: Syncing firewall Feb 10 18:12:22 check_reload_status: Synching vouchers Feb 10 18:12:22 check_reload_status: Synching vouchers Feb 10 18:11:56 check_reload_status: Syncing firewall Feb 10 18:11:55 check_reload_status: Syncing firewall Feb 10 18:11:46 check_reload_status: Synching vouchers Feb 10 18:11:46 check_reload_status: Synching vouchers Feb 10 18:11:29 check_reload_status: Syncing firewall Feb 10 18:11:25 check_reload_status: Syncing firewall Feb 10 18:11:21 check_reload_status: Synching vouchers Feb 10 18:11:21 check_reload_status: Synching vouchers Feb 10 18:10:46 check_reload_status: Synching vouchers Feb 10 18:10:46 check_reload_status: Synching vouchers Feb 10 18:10:29 check_reload_status: Syncing firewall Feb 10 18:10:24 check_reload_status: Syncing firewall Feb 10 18:10:20 check_reload_status: Synching vouchers Feb 10 18:10:20 check_reload_status: Synching vouchers Feb 10 18:09:42 check_reload_status: Synching vouchers Feb 10 18:09:42 check_reload_status: Synching vouchers Feb 10 18:09:27 check_reload_status: Syncing firewall Feb 10 18:09:24 check_reload_status: Syncing firewall Feb 10 18:09:20 check_reload_status: Synching vouchers Feb 10 18:09:20 check_reload_status: Synching vouchers Feb 10 18:08:37 check_reload_status: Synching vouchers Feb 10 18:08:36 check_reload_status: Synching vouchers Feb 10 18:08:24 check_reload_status: Syncing firewall Feb 10 18:08:20 check_reload_status: Syncing firewall Feb 10 18:08:15 check_reload_status: Synching vouchers Feb 10 18:08:14 check_reload_status: Synching vouchers Feb 10 18:07:40 check_reload_status: Syncing firewall Feb 10 18:07:39 check_reload_status: Syncing firewall Feb 10 18:07:30 check_reload_status: Synching vouchers Feb 10 18:07:30 check_reload_status: Synching vouchers Feb 10 18:07:21 check_reload_status: Syncing firewall Feb 10 18:07:18 check_reload_status: Syncing firewall Feb 10 18:07:14 check_reload_status: Synching vouchers Feb 10 18:07:14 check_reload_status: Synching vouchers Feb 10 18:06:29 check_reload_status: Synching vouchers Feb 10 18:06:29 check_reload_status: Synching vouchers Feb 10 18:06:18 check_reload_status: Syncing firewall Feb 10 18:06:17 check_reload_status: Syncing firewall Feb 10 18:06:07 check_reload_status: Synching vouchers Feb 10 18:06:07 check_reload_status: Synching vouchers Feb 10 18:05:29 check_reload_status: Synching vouchers Feb 10 18:05:28 check_reload_status: Synching vouchers Feb 10 18:05:21 check_reload_status: Syncing firewall Feb 10 18:05:17 check_reload_status: Syncing firewall Feb 10 18:05:06 check_reload_status: Synching vouchers Feb 10 18:05:06 check_reload_status: Synching vouchers Feb 10 18:04:34 check_reload_status: Syncing firewall Feb 10 18:04:28 check_reload_status: Syncing firewall Feb 10 18:04:24 check_reload_status: Synching vouchers Feb 10 18:04:24 check_reload_status: Synching vouchers Feb 10 18:04:09 check_reload_status: Syncing firewall Feb 10 18:04:04 check_reload_status: Synching vouchers Feb 10 18:04:04 check_reload_status: Synching vouchers Feb 10 18:03:59 check_reload_status: Reloading filter Feb 10 18:03:59 check_reload_status: Syncing firewall Feb 10 18:03:23 check_reload_status: Synching vouchers Feb 10 18:03:23 check_reload_status: Synching vouchers Feb 10 18:03:08 check_reload_status: Syncing firewall Feb 10 18:03:06 check_reload_status: Syncing firewall Feb 10 18:03:02 check_reload_status: Synching vouchers Feb 10 18:03:02 check_reload_status: Synching vouchers Feb 10 18:02:28 check_reload_status: Syncing firewall Feb 10 18:02:26 check_reload_status: Syncing firewall Feb 10 18:02:14 check_reload_status: Synching vouchers Feb 10 18:02:14 check_reload_status: Synching vouchers Feb 10 18:02:07 check_reload_status: Syncing firewall Feb 10 18:02:04 check_reload_status: Syncing firewall Feb 10 18:02:01 check_reload_status: Synching vouchers Feb 10 18:02:00 check_reload_status: Synching vouchers Feb 10 18:01:14 check_reload_status: Syncing firewall Feb 10 18:01:12 check_reload_status: Synching vouchers Feb 10 18:01:12 check_reload_status: Synching vouchers Feb 10 18:01:12 check_reload_status: Syncing firewall Feb 10 18:01:01 check_reload_status: Syncing firewall Feb 10 18:00:36 check_reload_status: Synching vouchers Feb 10 18:00:36 check_reload_status: Synching vouchers Feb 10 18:00:16 check_reload_status: Syncing firewall Feb 10 18:00:12 check_reload_status: Syncing firewall
An Services habe ich folgende:
apinger captiveportal xx captiveportal xy cron dhcpd dnsmasq ntpd radiusd squid
Und in einem Thread kam man darauf, dass es vielleicht daran liegen kann, dass sich ein regestrierter Voucher auf mehreren Netzen (versucht) einzuloggen, was zu einem Problem dieser Art führen kann? Das konnte ich so direkt nicht bestätigen.
Im Grunde habe ich keinen Schimmer, wo ich anfangen muss. Das Problem wird die CPU Last sein? Aber die Ursache kann x-Möglicheiten sein, oder?
Hier mal ein Ping von der pfSense aus zur Veranschaulichung
PING 192.168.70.3 (192.168.70.3) from 192.168.60.1: 56 data bytes 64 bytes from 192.168.70.3: icmp_seq=0 ttl=128 time=3.597 ms 64 bytes from 192.168.70.3: icmp_seq=1 ttl=128 time=7.451 ms 64 bytes from 192.168.70.3: icmp_seq=2 ttl=128 time=71.085 ms 64 bytes from 192.168.70.3: icmp_seq=3 ttl=128 time=91.081 ms 64 bytes from 192.168.70.3: icmp_seq=4 ttl=128 time=58.562 ms 64 bytes from 192.168.70.3: icmp_seq=5 ttl=128 time=53.692 ms 64 bytes from 192.168.70.3: icmp_seq=6 ttl=128 time=54.931 ms 64 bytes from 192.168.70.3: icmp_seq=7 ttl=128 time=0.878 ms 64 bytes from 192.168.70.3: icmp_seq=8 ttl=128 time=97.305 ms 64 bytes from 192.168.70.3: icmp_seq=9 ttl=128 time=46.065 ms --- 192.168.70.3 ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.878/48.465/97.305/32.939 ms
Die Sense 2.1.5 läuft auf einer APU1C mit 4GB Ram. Angeschlossen ist sie an ein Cisco 10 Port managed Switch auf dem zwei WANs ankommen und in der pfSense zum MultiWan mutieren. Einmal aus einem DSL Modem im Bridgemode mit PPPOE und Nr.2 ist ein LTE Router per DHCP.
Dazu läuft wie man bei Services sehen kann Squid und zwei CP. Ein Gästenetz und ein HeimWlan. Beide via Voucher Zugang.
Alle "wichtigen" Clients sind verkabelt.Passt zwar nicht mehr in den Thread, aber möchte auch nicht einen aufmachen. Gibt zu der CPU Load Sache schon so viele. SChlau werd ich aus keinem.
Zwar läuft das Netzwerk, mit den beschriebenen Einschränkungen, aber eine Endlösung stellt es so nicht dar. Die Übertragungsrate auf den NAS z.B. bleibt bei 6MB/Sekunde stehen, obwohl dazwischen nur ein (GB) Switch ist. Das kann es ja nicht sein ;(
Aber aus Angst das Netz nun bei versuchen komplett zu killen, würde ich mit einer zweiten Apu anfangen es neu zu gestalten.
Oder ihr habt den einen heissen Ansatz, was da bei mir falsch läuft.Greets,
-
Da sich mit der neuen Version so einiges geändert hat, würde ich eher sagen mit 2.2 neu aufsetzen, dann hast du hoffentlich auch keine Stör- oder Seiteneffekte mehr, die sich jetzt vielleicht erledigt haben. Wenn du eh noch relativ am Anfang bist, würde ich dann auch gleich auf der neuen Codebasis anfangen aufzusetzen und nicht mit dem alten Stand - gerade was CP etc. angeht, wurde da ja einiges gestrickt.
-
Hi flachfalke,
nur mal noch so als Hinweis zu Samba und deren config…
Wenn Du die smb.conf händisch bearbeitest, weil da z.B. im GUI des FreeNAS auf Grund von Versions-Unterschieden keine Einstellungsmöglichkeiten sind und anschließen den Samba-Server neu startest ist das kein Problem.
Dann solltest Du aber nicht mehr über den GUI Änderungen vornehmen, der überschreibt sonst Deine händische Config.
Gruß orcape