Автор Тема: nfs + samba как ? (Прочитано 4299 раз)

winmasta · « **Ответ #15 :** 05 Ноября 2013, 06:54:35 »

с клиента

sudo nmap -sU -p 1194 109.194.33.177

Starting Nmap 6.00 ( http://nmap.org ) at 2013-11-05 09:53 NOVT
Nmap scan report for 109x194x33x177.static-business.tomsk.ertelecom.ru (109.194.33.177)
Host is up (0.0014s latency).
PORT     STATE         SERVICE
1194/udp open|filtered openvpn

Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds

на сервере

Код: [Выделить]

sudo netstat -tulpan | grep 1194
udp        0      0 0.0.0.0:1194            0.0.0.0:*                           2180/openvpn

AnrDaemon · « **Ответ #16 :** 05 Ноября 2013, 07:11:32 »

iptables-save с сервера.
И клиента тоже, до кучи.

ArcFi · « **Ответ #17 :** 05 Ноября 2013, 08:12:25 »

Кстати, выхлоп nmap в данном случае ни о чём не говорит, т.к. там на любом UDP-порту "open|filtered".

AnrDaemon · « **Ответ #18 :** 05 Ноября 2013, 08:16:36 »

А ещё я не понимаю, зачем использовать UDP... но это так, к делу прямого отношения не имеет.

fisher74 · « **Ответ #19 :** 05 Ноября 2013, 08:43:31 »

вроде как udp считается приоритетным для OpenVPN. Вроде как снижение нагрузки на каналы и оборудование.
Но в случае косяков, для проведения диагностики, предлагается временно перевести на tcp.

AnrDaemon · « **Ответ #20 :** 05 Ноября 2013, 09:14:10 »

UDP как протокол при туннелировании трафика гораздо более чувствителен к потерям пакетов, чем TCP (read: вызывает больше повторов передачи на каждый потерянный пакет), создавая бОльшую нагрузку на сеть.
У меня целая PDF'ка лежит(лежала? искать надо) с исследованием этого вопроса. Не помню, где брал, и яндекс, зар-раза, не выдаёт ничего вразумительного.

fisher74 · « **Ответ #21 :** 05 Ноября 2013, 10:13:48 »

Я Вам открою тайну: время диалапмопедов кануло в лету. И при современных технологиях передачи данных потеря пакетов уже не так актуальна как в прошлом веке. За какой год исследования, если Вы уже PDF-ку потеряли?

ЗЫ не касается WiFi, WiMAX, сателлитсвязь и т.п.

AnrDaemon · « **Ответ #22 :** 05 Ноября 2013, 10:16:24 »

Цитата: fisher74 от 05 Ноября 2013, 10:13:48

ЗЫ не касается WiFi, WiMAX, сателлитсвязь и т.п.

т.е. не касается всех "современных" видов связи?

ArcFi · « **Ответ #23 :** 05 Ноября 2013, 10:19:56 »

Кстати, если TCP такой хороший, то почему в дефолтном конфиге UDP?
Маловероятно, что разрабы его туда от балды засунули.
Но для тестирования и отладки, согласен, есть резон поменять.

Karl500 · « **Ответ #24 :** 05 Ноября 2013, 10:43:13 »

Вот обе точки зрения:
1. Почему UDP лучше: http://sites.inka.de/~W1011/devel/tcp-tcp.html (к сожалению, на русском я в свое время не нашел)
2. Почему TCP не так уж и плох: http://barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf (это не та PDF-ка?)

На мой не вполне профессиональный взгляд, первая точка зрения более верна.

fisher74 · « **Ответ #25 :** 05 Ноября 2013, 10:45:12 »

Цитата: AnrDaemon от 05 Ноября 2013, 10:16:24

Цитата: fisher74 от 05 Ноября 2013, 10:13:48
ЗЫ не касается WiFi, WiMAX, сателлитсвязь и т.п.
т.е. не касается всех "современных" видов связи?

И снова приглашаю в 21 век, в котором нормой считается связь по ВОЛС. А всё что связано с радио- и проводной связью - решение "последней мили"

AnrDaemon · « **Ответ #26 :** 05 Ноября 2013, 11:07:04 »

Karl500, прочитай PDF'ку повнимательнее.

Karl500 · « **Ответ #27 :** 05 Ноября 2013, 11:20:57 »

Читал. Могу сказать, что использую OpenVPN уже давно, причем в варианте UDP. Пользователей подключается с пару десятков из разных городов и (естественно) от разных провайдеров. Проблемы были два раза. Оба раза - на стороне провайдеров (насколько помню, связано было с тем, что у них был запрещен ICMP трафик, приходилось вручную у пользователя подбирать размер фрагментации пакетов.
Пробовал (успешно) соединяться буквально отовсюду, в том числе и из других стран по крайне хреновому WiFi.
Переходить на TCP даже и не думал.

UPD: Вот эта фраза из PDF-ки, кмк, означает, что при действительно хреновом канале UDP предпочтительнее: "Конечно, не стоит забывать о таком эффекте, как вытеснение TCP потока (TCP-starvation/UDP-dominance) именно за счет его управляемости. То есть, если два типа трафика смешиваются в одной полосе регулирования, то TCP трафик, поддающийся регулирующему воздействию, будет уступать полосу UDP".

winmasta · « **Ответ #28 :** 05 Ноября 2013, 16:24:52 »

iptables-save сервера

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# Generated by iptables-save v1.4.12 on Tue Nov  5 19:23:18 2013
*mangle
:PREROUTING ACCEPT [23192588:50655534945]
:INPUT ACCEPT [9495173:43670828032]
:FORWARD ACCEPT [13697322:6984701424]
:OUTPUT ACCEPT [9147001:12839387066]
:POSTROUTING ACCEPT [22849667:19825405786]
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Tue Nov  5 19:23:18 2013
# Generated by iptables-save v1.4.12 on Tue Nov  5 19:23:18 2013
*nat
:PREROUTING ACCEPT [224572:18623959]
:INPUT ACCEPT [131719:10382444]
:OUTPUT ACCEPT [100652:7101750]
:POSTROUTING ACCEPT [2159877:272034167]
-A PREROUTING -i eth0 -p tcp -m multiport --dports 80,8080 -j REDIRECT --to-ports 3128
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.31
-A PREROUTING -s 109.194.35.69/32 -d 109.194.33.177/32 -i eth1 -p udp -m udp --dport 54236 -j DNAT --to-destination 192.168.1.1:1149
-A PREROUTING -s 217.18.140.129/32 -i eth1 -p tcp -m tcp --dport 46654 -j DNAT --to-destination 192.168.1.14
-A PREROUTING -s 195.225.38.62/32 -i eth1 -p tcp -m multiport --dports 52000,60671 -j DNAT --to-destination 192.168.1.36
-A PREROUTING -i eth1 -p tcp -m tcp --dport 365 -j DNAT --to-destination 192.168.1.29
-A PREROUTING -i eth1 -p tcp -m tcp --dport 367 -j DNAT --to-destination 192.168.1.9
-A PREROUTING -i eth1 -p tcp -m tcp --dport 368 -j DNAT --to-destination 192.168.1.10
-A PREROUTING -s 195.208.161.154/32 -i eth1 -p tcp -m multiport --dports 80,443,902,903,1368 -j DNAT --to-destination 192.168.1.100
-A PREROUTING -s 109.194.35.69/32 -i eth1 -p tcp -m multiport --dports 80,443,902,903,1368 -j DNAT --to-destination 192.168.1.100
-A PREROUTING -s 195.208.161.154/32 -i eth1 -p tcp -m tcp --dport 9100 -j DNAT --to-destination 192.168.1.43
-A PREROUTING -i eth1 -p tcp -m tcp --dport 9786 -j DNAT --to-destination 192.168.1.15
-A PREROUTING -s 109.194.35.69/32 -i eth1 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.1.2
-A PREROUTING -s 195.208.161.154/32 -i eth1 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.1.2
-A PREROUTING -s 195.208.161.206/32 -i eth1 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.1.2
-A PREROUTING -s 90.188.88.230/32 -i eth1 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.1.2
-A PREROUTING -s 90.188.88.229/32 -i eth1 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.1.2
-A PREROUTING -s 90.188.88.82/32 -i eth1 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.1.2
-A PREROUTING -s 109.194.35.69/32 -i eth1 -p tcp -m tcp --dport 5900 -j DNAT --to-destination 192.168.1.9
-A PREROUTING -s 195.208.161.154/32 -i eth1 -p tcp -m tcp --dport 5900 -j DNAT --to-destination 192.168.1.9
-A PREROUTING -s 195.208.161.206/32 -i eth1 -p tcp -m tcp --dport 5900 -j DNAT --to-destination 192.168.1.9
-A PREROUTING -i eth1 -p tcp -m tcp --dport 6881 -j DNAT --to-destination 192.168.1.9
-A PREROUTING -i eth1 -p udp -m udp --dport 6881 -j DNAT --to-destination 192.168.1.9
-A POSTROUTING -o eth1 -j SNAT --to-source 109.194.33.177
COMMIT
# Completed on Tue Nov  5 19:23:18 2013
# Generated by iptables-save v1.4.12 on Tue Nov  5 19:23:18 2013
*filter
:INPUT DROP [22084:2304833]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [9147021:12839392042]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth0 -p tcp -m multiport --dports 21,22,53,80,111,139,366,389,445,636,2049,3128,3142,6881 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth0 -p udp -m multiport --dports 53,111,123,137,138,139,631,750,2049,5351,6881 -j ACCEPT
-A INPUT -s 195.208.161.206/32 -d 109.194.33.177/32 -i eth1 -p tcp -m multiport --dports 139,445 -j ACCEPT
-A INPUT -s 109.194.35.69/32 -d 109.194.33.177/32 -i eth1 -p tcp -m tcp --dport 5900 -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j LOG --log-prefix "NEW not SYN: "
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -d 109.194.33.177/32 -i eth1 -p tcp -m multiport --dports 366 -j ACCEPT
-A INPUT -s 195.208.161.154/32 -d 109.194.33.177/32 -i eth1 -p tcp -m multiport --dports 111,139,445,2049 -j ACCEPT
-A INPUT -s 195.208.161.154/32 -d 109.194.33.177/32 -i eth1 -p udp -m multiport --dports 111,137,138,2049 -j ACCEPT
-A INPUT -s 109.194.35.69/32 -d 109.194.33.177/32 -i eth1 -p tcp -m multiport --dports 139,445,2049 -j ACCEPT
-A INPUT -s 109.194.35.69/32 -d 192.168.1.1/32 -i eth1 -p udp -m multiport --dports 1149 -j ACCEPT
-A INPUT -m limit --limit 3/min --limit-burst 3 -j LOG --log-prefix "IPT INPUT packet died: " --log-level 7
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -i eth0 -j ACCEPT
-A FORWARD -d 192.168.1.31/32 -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARD -s 217.18.140.129/32 -d 192.168.1.14/32 -i eth1 -p tcp -m tcp --dport 46654 -j ACCEPT
-A FORWARD -s 195.225.38.62/32 -d 192.168.1.36/32 -i eth1 -p tcp -m multiport --dports 52000,60671 -j ACCEPT
-A FORWARD -d 192.168.1.29/32 -i eth1 -p tcp -m multiport --dports 365 -j ACCEPT
-A FORWARD -d 192.168.1.9/32 -i eth1 -p tcp -m multiport --dports 367,5900,6881 -j ACCEPT
-A FORWARD -d 192.168.1.10/32 -i eth1 -p tcp -m tcp --dport 368 -j ACCEPT
-A FORWARD -s 195.208.161.154/32 -d 192.168.1.100/32 -i eth1 -p tcp -m multiport --dports 80,443,902,903,1368 -j ACCEPT
-A FORWARD -s 109.194.35.69/32 -d 192.168.1.100/32 -i eth1 -p tcp -m multiport --dports 80,443,902,903,1368 -j ACCEPT
-A FORWARD -d 192.168.1.2/32 -i eth1 -p tcp -m tcp --dport 3389 -j ACCEPT
-A FORWARD -d 192.168.1.9/32 -i eth1 -p tcp -m tcp --dport 6881 -j ACCEPT
-A FORWARD -d 192.168.1.9/32 -i eth1 -p udp -m udp --dport 6881 -j ACCEPT
-A FORWARD -s 195.208.161.154/32 -d 192.168.1.43/32 -i eth1 -p tcp -m multiport --dports 9100 -j ACCEPT
-A FORWARD -d 192.168.1.15/32 -i eth1 -p tcp -m tcp --dport 9786 -j ACCEPT
-A FORWARD -m limit --limit 3/min --limit-burst 3 -j LOG --log-prefix "IPT FORWARD packet died: " --log-level 7
COMMIT
# Completed on Tue Nov  5 19:23:18 2013

iptables-save клиента - пусто

Пользователь решил продолжить мысль 05 Ноября 2013, 16:35:22:

переехал на tcp, в конфигах сменил udp на tcp и tun на tap

лог на сервере

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

winmasta@server:~$ sudo cat /var/log/openvpn.log 
Tue Nov  5 19:28:55 2013 OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Feb 27 2013
Tue Nov  5 19:28:55 2013 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Nov  5 19:28:55 2013 Diffie-Hellman initialized with 1024 bit key
Tue Nov  5 19:28:55 2013 Control Channel Authentication: using 'keys/ta.key' as a OpenVPN static key file
Tue Nov  5 19:28:55 2013 Outgoing Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
Tue Nov  5 19:28:55 2013 Incoming Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
Tue Nov  5 19:28:55 2013 TLS-Auth MTU parms [ L:1572 D:164 EF:64 EB:0 ET:0 EL:0 ]
Tue Nov  5 19:28:55 2013 Socket Buffers: R=[87380->131072] S=[16384->131072]
Tue Nov  5 19:28:55 2013 ROUTE default_gateway=109.194.33.254
Tue Nov  5 19:28:55 2013 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Tue Nov  5 19:28:55 2013 OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.5.0
Tue Nov  5 19:28:55 2013 TUN/TAP device tap0 opened
Tue Nov  5 19:28:55 2013 TUN/TAP TX queue length set to 100
Tue Nov  5 19:28:55 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Nov  5 19:28:55 2013 /sbin/ifconfig tap0 10.8.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Tue Nov  5 19:28:55 2013 Data Channel MTU parms [ L:1572 D:1450 EF:40 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Nov  5 19:28:55 2013 GID set to nogroup
Tue Nov  5 19:28:55 2013 UID set to nobody
Tue Nov  5 19:28:55 2013 Listening for incoming TCP connection on [undef]
Tue Nov  5 19:28:55 2013 TCPv4_SERVER link local (bound): [undef]
Tue Nov  5 19:28:55 2013 TCPv4_SERVER link remote: [undef]
Tue Nov  5 19:28:55 2013 MULTI: multi_init called, r=256 v=256
Tue Nov  5 19:28:55 2013 IFCONFIG POOL: base=10.8.0.2 size=253, ipv6=0
Tue Nov  5 19:28:55 2013 MULTI: TCP INIT maxclients=5 maxevents=9
Tue Nov  5 19:28:55 2013 Initialization Sequence Completed

лог на клиенте

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

Tue Nov  5 19:29:50 2013 OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Feb 13 2013
Tue Nov  5 19:29:50 2013 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Nov  5 19:29:52 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Nov  5 19:29:52 2013 WARNING: file '/etc/openvpn/keys/wh.key' is group or others accessible
Tue Nov  5 19:29:52 2013 Control Channel Authentication: using '/etc/openvpn/keys/ta.key' as a OpenVPN static key file
Tue Nov  5 19:29:52 2013 Outgoing Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
Tue Nov  5 19:29:52 2013 Incoming Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
Tue Nov  5 19:29:52 2013 LZO compression initialized
Tue Nov  5 19:29:52 2013 Control Channel MTU parms [ L:1572 D:164 EF:64 EB:0 ET:0 EL:0 ]
Tue Nov  5 19:29:52 2013 Socket Buffers: R=[87380->131072] S=[16384->131072]
Tue Nov  5 19:29:52 2013 Data Channel MTU parms [ L:1572 D:1450 EF:40 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Nov  5 19:29:52 2013 Local Options hash (VER=V4): '9e6a0b8d'
Tue Nov  5 19:29:52 2013 Expected Remote Options hash (VER=V4): 'e6045f71'
Tue Nov  5 19:29:52 2013 Attempting to establish TCP connection with [AF_INET]109.194.33.177:54236 [nonblock]
Tue Nov  5 19:29:53 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:29:59 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:30:05 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:30:11 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:30:17 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:30:23 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:30:29 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:30:35 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:30:41 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:30:47 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:30:53 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:30:59 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:31:05 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:31:11 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:31:17 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:31:23 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:31:29 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:31:35 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:31:41 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:31:47 2013 TCP: connect to [AF_INET]109.194.33.177:54236 failed, will try again in 5 seconds: Connection refused
Tue Nov  5 19:31:53 2013 NOTE: --mute triggered...

fisher74 · « **Ответ #29 :** 05 Ноября 2013, 18:08:37 »

Код: [Выделить]

sudo iptables -A INPUT -d 109.194.33.177/32 -i eth1 -p tcp -m multiport --dports 1194 -j ACCEPT
Хотя возможно и пропустил в листинге

Форум русскоязычного сообщества Ubuntu

Автор Тема: nfs + samba как ? (Прочитано 4299 раз)

winmasta

Re: nfs + samba как ?

AnrDaemon

Re: nfs + samba как ?

ArcFi

Re: nfs + samba как ?

AnrDaemon

Re: nfs + samba как ?

fisher74

Re: nfs + samba как ?

AnrDaemon

Re: nfs + samba как ?

fisher74

Re: nfs + samba как ?

AnrDaemon

Re: nfs + samba как ?

ArcFi

Re: nfs + samba как ?

Karl500

Re: nfs + samba как ?

fisher74

Re: nfs + samba как ?

AnrDaemon

Re: nfs + samba как ?

Karl500

Re: nfs + samba как ?

winmasta

Re: nfs + samba как ?

fisher74

Re: nfs + samba как ?