Задачка по Openvpn



  • Помогиге разобраться пожалуйста c настройкой openvpn.

    Настроил сервер, создал ключи, скопировал сключи на ubuntu. Поднялосьс соединение, выдался ip.

    Вот настройки pfsense https://www.dropbox.com/gallery/31210635/1/pfsense?h=3c5e9a

    root@ubuntu ~# ifconfig tun0
    tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              inet addr:10.129.0.6  P-t-P:10.129.0.5  Mask:255.255.255.255
              UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:100
              RX bytes:0 (0.0 B)  TX bytes:1176 (1.1 KB)
    

    С pfsense

    ovpns1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
            options=80000 <linkstate>inet6 fe80::20c:29ff:fe35:5818%ovpns1 prefixlen 64 scopeid 0xb
            inet 10.129.0.1 --> 10.129.0.2 netmask 0xffffffff
            nd6 options=3 <performnud,accept_rtadv>Opened by PID 4816</performnud,accept_rtadv></linkstate></up,pointopoint,running,multicast>
    

    Но пинги не идут.
    C ubuntu ни на 10.129.0.5 ни на 192.168.1.0 сеть, но идут на 10.129.0.1.
    Из pfsense пинг идет на 10.129.0.6, но не идет на 10.129.0.5

    Откуда взялись эти адреса 10.129.0.5, 10.129.0.6 я не пойму

    Локальная сеть на pfsense 192.168.1.0/24
    Удаленная сеть на ubuntu 192.168.9.0/24
    Туннельная 10.129.0.0/24

    логи openvpn c ubuntu

    Thu Aug 18 00:02:11 2011 Initialization Sequence Completed
    Thu Aug 18 01:02:08 2011 VERIFY OK: depth=1, /C=RU/ST=Powolje/L=Penza/O=PRO/emailAddress=sc@mail$
    Thu Aug 18 01:02:08 2011 VERIFY OK: depth=0, /C=RU/ST=Powolje/L=Penza/O=PRO/emailAddress=sc@mail$
    Thu Aug 18 01:02:09 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Thu Aug 18 01:02:09 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authenticati$
    Thu Aug 18 01:02:09 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Thu Aug 18 01:02:09 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authenticati$
    Thu Aug 18 01:02:09 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
    Thu Aug 18 02:02:08 2011 TLS: tls_process: killed expiring key
    Thu Aug 18 02:02:09 2011 TLS: soft reset sec=0 bytes=36960/0 pkts=704/0
    Thu Aug 18 02:02:10 2011 VERIFY OK: depth=1, /C=RU/ST=Powolje/L=Penza/O=PRO/emailAddress=sc@mail$
    Thu Aug 18 02:02:10 2011 VERIFY OK: depth=0, /C=RU/ST=Powolje/L=Penza/O=PRO/emailAddress=sc@mail$
    Thu Aug 18 02:02:11 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Thu Aug 18 02:02:11 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authenticati$
    Thu Aug 18 02:02:11 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Thu Aug 18 02:02:11 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authenticati$
    Thu Aug 18 02:02:11 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
    Thu Aug 18 03:02:09 2011 TLS: tls_process: killed expiring key
    Thu Aug 18 03:02:12 2011 VERIFY OK: depth=1, /C=RU/ST=Powolje/L=Penza/O=PRO/emailAddress=sc@mail$
    Thu Aug 18 03:02:12 2011 VERIFY OK: depth=0, /C=RU/ST=Powolje/L=Penza/O=PRO/emailAddress=sc@mail$
    Thu Aug 18 03:02:13 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Thu Aug 18 03:02:13 2011 NOTE: --mute triggered...
    
    

    вот конфиг

    remote 85.234.37.82 1194
    client
    dev tun
    proto udp
    resolv-retry infinite
    nobind
    user nobody
    group nogroup
    persist-key
    persist-tun
    ca /etc/openvpn/keys/serverca.crt
    cert /etc/openvpn/clients/kamenka.crt
    key /etc/openvpn/clients/kamenka.key
    tls-client
    #tls-auth /etc/openvpn/clients/ta.key
    auth SHA1
    comp-lzo
    verb 3
    mute 20
    route 192.168.1.0 255.255.255.0
    log /var/log/openvpn.log
    


  • в общем-то пинг c ubuntu до pfsense 192.168.1.200 идет, но не идет на другие машины в сети…
    Но с pfsense не идет пинг до ubuntu клиента 192.168.9.254, но идет до виртуального ip 10.129.0.6
    Где -то напутано с маршрутами, вот только где....

    [2.0-RC3][root@pfsense.gbu.local]/root(5): netstat -rn
    Routing tables
    
    Internet:
    Destination Gateway Flags Refs Use Netif Expire
    default 85.234.37.1 UGS 0 4512457 em1
    8.8.8.8 85.234.37.1 UGHS 0 7454 em1
    10.129.0.0/24 10.129.0.2 UGS 0 342 ovpns1
    10.129.0.1 link#11 UHS 0 0 lo0
    10.129.0.2 link#11 UH 0 0 ovpns1
    85.234.32.35 85.234.37.1 UGHS 0 95 em1
    85.234.37.0/24 link#2 U 0 186445 em1
    85.234.37.82 link#2 UHS 0 0 lo0
    127.0.0.1 link#4 UH 0 36 lo0
    192.168.1.0/24 link#8 U 0 6907831 em0_vl
    192.168.1.200 link#8 UHS 0 0 lo0
    192.168.3.0/24 192.168.1.254 UGS 0 33 em0_vl
    192.168.101.0/24 link#10 U 0 1166405 em0_vl
    192.168.101.254 link#10 UHS 0 0 lo0
    
    root@lamp ~# route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    80.95.33.101 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
    10.67.15.11 0.0.0.0 255.255.255.255 UH 0 0 0 ppp9
    10.67.15.4 0.0.0.0 255.255.255.255 UH 0 0 0 ppp4
    10.129.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
    10.67.15.16 0.0.0.0 255.255.255.255 UH 0 0 0 ppp5
    10.67.15.17 0.0.0.0 255.255.255.255 UH 0 0 0 ppp2
    10.67.15.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1
    10.129.0.1 10.129.0.5 255.255.255.255 UGH 0 0 0 tun0
    10.67.15.3 0.0.0.0 255.255.255.255 UH 0 0 0 ppp3
    192.168.1.0 10.129.0.5 255.255.255.0 UG 0 0 0 tun0
    192.168.9.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
    0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 
    

    Как можно прописать маршрут на pfsense 2.0
    192.168.9.0 tun0
    ????????????



  • up, можно ли хотя бы посмотреть формируемый конфиг openvpn?



  • попробуй добавить в настройках пфсенса push "route " с сеткой пфсенса.



  • не покатило, может какие правила разрешающие для LAN нужны в FW???



  • ну вообще то - файрвол отключается\делается правило -разрешить все и всем на период подобных отладок…причем на обоих сторонах...
    с этого надо было начинать...



  • так оно и есть, FW открыты с обоих сторон:
    пинг идет на шлюз, но компы за ним не пингует.
    С сервера (pfsense) пинг идет только на openvpn_сеть.

    root@lamp ~# iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    Chain FORWARD (policy ACCEPT)
    target prot opt source destination
    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination
    root@lamp ~# ping 192.168.1.200
    PING 192.168.1.200 (192.168.1.200) 56(84) bytes of data.
    64 bytes from 192.168.1.200: icmp_seq=1 ttl=64 time=87.2 ms
    64 bytes from 192.168.1.200: icmp_seq=2 ttl=64 time=86.5 ms
    ^C
    –- 192.168.1.200 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1001ms
    rtt min/avg/max/mdev = 86.583/86.932/87.282/0.457 ms
    root@lamp ~# ping 192.168.1.254
    PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
    ^C
    --- 192.168.1.254 ping statistics ---
    9 packets transmitted, 0 received, 100% packet loss, time 8055ms

    и на pfsense все разрешено.
    дОСТИГ определенных результатов, теперь пинг с клиента идет на машины за сервером, но только если шлюзом в них прописан pfsense.
    Сеть с сервера за клиентом попрежнему не видна...



  • default gateway для сетей 192.168.1.0/24 и 192.168.9.0/24 кто?



  • @alexandrnew:

    default gateway для сетей 192.168.1.0/24 и 192.168.9.0/24 кто?

    для сети 192.168.1.0.24 - pfsense 192.168.1.200
    для 192.168.9.0/24 - он сам, тоесть его WAN (85.234.x.x)

    ping идет только от клиента на компы в сеть за pfsense, у которых прописан шлюзом сам pfsense.
    от сервера пинг не идет как на клиентский IP (192.168.9.254), так и на машины в сети.

    сделал iptables -L на клиенте:

    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
    ACCEPT tcp -- 192.168.1.0/24 anywhere tcp dpt:3128
    ACCEPT all -- anywhere anywhere
    ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
    open_vpn all -- anywhere anywhere
    Chain FORWARD (policy DROP)
    target prot opt source destination
    open_vpn all -- anywhere anywhere
    open_vpn all -- anywhere anywhere
    NFQUEUE all -- anywhere anywhere NFQUEUE num 0
    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT tcp -- anywhere anywhere tcp spt:ssh
    NFQUEUE tcp -- anywhere 192.168.1.0/24 tcp spt:3128 NFQUEUE num 0
    ACCEPT all -- anywhere anywhere
    ACCEPT tcp -- anywhere anywhere tcp spt:ssh
    open_vpn all -- anywhere anywhere
    Chain open_vpn (4 references)
    target prot opt source destination
    ACCEPT all -- anywhere 10.16.0.0/24
    ACCEPT all -- 10.16.0.0/24 anywhere
    ACCEPT all -- 192.168.9.0/24 anywhere
    ACCEPT all -- anywhere 192.168.9.0/24
    ACCEPT all -- anywhere 192.168.1.0/24
    ACCEPT all -- 192.168.1.0/24 anywhere 
    

    пробовал и с отключенным iptables, пробовал прописывать правило всем разрешено все, все равно так же…

    сделал tcpdump c pfsense (ping c ubuntu комп за сетью pfsense)

    [2.0-RC3][root@pfsense.gbu.local]/root(25): tcpdump -pnvi ovpns1
    tcpdump: listening on ovpns1, link-type NULL (BSD loopback), capture size 96 bytes
    21:33:56.416511 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
        10.16.0.6 > 192.168.1.11: ICMP echo request, id 11021, seq 1, length 64
    21:33:56.417170 IP (tos 0x0, ttl 127, id 16093, offset 0, flags [none], proto ICMP (1), length 84)
        192.168.1.11 > 10.16.0.6: ICMP echo reply, id 11021, seq 1, length 64
    21:33:57.416823 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
        10.16.0.6 > 192.168.1.11: ICMP echo request, id 11021, seq 2, length 64
    21:33:57.417167 IP (tos 0x0, ttl 127, id 16094, offset 0, flags [none], proto ICMP (1), length 84)
    

    tcpdump c pfsense на LAN: (ping c ubuntu комп за сетью pfsense)

    21:19:39.138313 IP 10.16.0.6 > pool-192.168.1.11.local: ICMP echo request, id 267, seq 17, length 64
    21:19:39.138661 IP pool-192.168.1.11.local > 10.16.0.6: ICMP echo reply, id 267, seq 17, length 64
    

    tcpdump c ubuntu на tun0: (пинг с pfsense 192.168.9.254)
    ничего.

    где-то и как-то pfsense не пускает пакетики в сеть 192.168.9.0/24 с себя.

    хотя маршрут имеется:

    [2.0-RC3][root@pfsense.gbu.local]/root(26): netstat -rn
    Routing tables
    
    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            85.234.37.1        UGS         0   472469    em1
    10.16.0.0/24       10.16.0.2          UGS         0     1993 ovpns1
    10.16.0.1          link#11            UHS         0        0    lo0
    10.16.0.2          link#11            UH          0        0 ovpns1
    85.234.37.0/24     link#2             U           0    20667    em1
    85.234.37.82       link#2             UHS         0        0    lo0
    127.0.0.1          link#4             UH          0       29    lo0
    192.168.1.0/24     link#8             U           0  3635160 em0_vl
    192.168.1.200      link#8             UHS         0        0    lo0
    192.168.3.0/24     192.168.1.254      UGS         0        0 em0_vl
    192.168.9.0/24     10.16.0.2          UGS         0      324 ovpns1
    192.168.101.0/24   link#10            U           0   455881 em0_vl
    192.168.101.254    link#10            UHS         0        0    lo0
    




  • т.е. опвн сервер и клиент друг-друга пингуют
    а клиенты из их сетей друг-друга нет?



  • да, все так.
    сервера пингуются по виртуальным ip.
    сеть за клиентом пингует виртуальные ip сервера, но не пингует локальные ip. Комп с клиентом пингует локальгый ip адрес сервера.
    Сервер не пингует локальный IP клиента.

    Может все дело в vmware, у меня pfsense стоит на ESXi 4.1



  • тогда Вам надо роутинг в опенвпн донастраивать
    в 1.2.3
    у меня в кастом
    route 192.168.10.0 255.255.255.0; - чтобы роутер про клиентскую сеть 10.х знал
    push "route 192.168.3.0 255.255.255.0"; - чтобы клиент знал про сеть 3.х сервера
    плюс в Client-specific добавляю
    iroute 192.168.10.0 255.255.255.0 -я так понимаю это серверу дается куда сеть 10.х отдавать



  • Спасибо большое, пошел сдвиг. Облазил кучу форумов, оказалось нужно в Client-specific маршрут добавить, если честно сначала думал, что это закладка для настройки pfsense в качестве клиента openvpn…



  • Как писал выше, продвинулся, осталось чуть-чуть.
    Серваки пингуют друг друга по локальным и туннельным адресам. Сервак с ubuntu может пинговать сеть за pfsense, но вот pfsense не может пинговать сеть за ubuntu, соответственно и клиенты за ubuntu не могут пинговать сеть за pfsense.  
    Как можно исправить, я так понимаю клиенты не знают маршрут… В какую сторону копнуть?
    Сейчас посмотрел, пинг даже с локальной машины сервера (traffpro) не идет во внутреннюю сеть. Хотя интернет у всех работает нормально.

    
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.67.15.28     0.0.0.0         255.255.255.255 UH    0      0        0 ppp7
    10.16.0.5       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
    10.67.15.60     0.0.0.0         255.255.255.255 UH    0      0        0 ppp2
    10.67.15.31     0.0.0.0         255.255.255.255 UH    0      0        0 ppp3
    10.67.15.41     0.0.0.0         255.255.255.255 UH    0      0        0 ppp5
    10.67.15.25     0.0.0.0         255.255.255.255 UH    0      0        0 ppp4
    10.67.15.43     0.0.0.0         255.255.255.255 UH    0      0        0 ppp10
    10.67.15.59     0.0.0.0         255.255.255.255 UH    0      0        0 ppp1
    80.95.33.102    0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
    10.67.15.37     0.0.0.0         255.255.255.255 UH    0      0        0 ppp6
    10.67.15.36     0.0.0.0         255.255.255.255 UH    0      0        0 ppp8
    10.67.15.54     0.0.0.0         255.255.255.255 UH    0      0        0 ppp12
    10.67.15.51     0.0.0.0         255.255.255.255 UH    0      0        0 ppp11
    10.16.0.0       10.16.0.5       255.255.255.0   UG    0      0        0 tun0
    10.67.15.0      10.16.0.5       255.255.255.0   UG    0      0        0 tun0
    192.168.1.0     10.16.0.5       255.255.255.0   UG    0      0        0 tun0
    192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
    0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
    
    


  • у клиентов ПК с ОпенВПН должны быть или шлюзами по умолчанию или шлюзы по умолчанию в их подсети должны знать куда роутить трафик для конкретных подсетей



  • шлюзы по умолчанию в  подсети должны знать куда роутить трафик для конкретных подсетей

    Да, именно в этом скорее косяк. вот только не пойму в каком месте…

    Траффпро работает уже 3 месяца. Клиенты выходят в интернет через PPPoE.
    WAN - PPPoE Static IP
    LAN - 192.168.9.254
    DHCP раздает такие адреса всем:
    ip 192.168.9.10-192.168.9.100
    netmask 255.255.255.0
    gw 192.168.9.254

    C сервера никак не могу  достучаться до клиентских машинок с local ip, даже ping не идет. Хотя клиенты нормально получают DHCP адреса с того же сервера и через PPPoE выходят через него же в инет. трафик, считается и тп...
    Клиенты так же не могут пинговать сервер. 0_о
    Вот таблица маршрутизации с сервера:

    root@lamp ~# route -n
    Kernel IP routing table
    Destination	 Gateway		 Genmask		 Flags Metric Ref	Use Iface
    10.67.15.28	 0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp7
    10.16.0.5	   0.0.0.0		 255.255.255.255 UH	0	  0		0 tun0
    10.67.15.60	 0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp2
    10.67.15.47	 0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp9
    10.67.15.31	 0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp3
    85.92.31.101	0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp0
    10.67.15.41	 0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp5
    10.67.15.25	 0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp4
    10.67.15.59	 0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp1
    10.67.15.37	 0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp6
    10.67.15.54	 0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp12
    10.67.15.51	 0.0.0.0		 255.255.255.255 UH	0	  0		0 ppp11
    10.16.0.0	   10.16.0.5	   255.255.255.0   UG	0	  0		0 tun0
    192.168.1.0	 10.16.0.5	   255.255.255.0   UG	0	  0		0 tun0
    192.168.10.0	0.0.0.0		 255.255.255.0   U	 0	  0		0 eth0
    0.0.0.0		 0.0.0.0		 0.0.0.0		 U	 0	  0		0 ppp0
    

    а вот с клиента:

    Активные маршруты:
    Сетевой адрес		   Маска сети	  Адрес шлюза	   Интерфейс  Метрика
    		  0.0.0.0		  0.0.0.0	  10.67.15.37	 10.67.15.37	   1
    		  0.0.0.0		  0.0.0.0   192.168.10.254   192.168.10.12	   21
    	  10.67.15.37  255.255.255.255		127.0.0.1	   127.0.0.1	   50
       10.255.255.255  255.255.255.255	  10.67.15.37	 10.67.15.37	   50
    		127.0.0.0		255.0.0.0		127.0.0.1	   127.0.0.1	   1
    	 192.168.10.0	255.255.255.0	192.168.10.12   192.168.10.12	   20
    	192.168.10.12  255.255.255.255		127.0.0.1	   127.0.0.1	   20
       192.168.10.254  255.255.255.255	  10.67.15.37	 10.67.15.37	   1
       192.168.10.255  255.255.255.255	192.168.10.12   192.168.10.12	   20
    		224.0.0.0		240.0.0.0	192.168.10.12   192.168.10.12	   20
    		224.0.0.0		240.0.0.0	  10.67.15.37	 10.67.15.37	   1
      255.255.255.255  255.255.255.255	  10.67.15.37	 10.67.15.37	   1
      255.255.255.255  255.255.255.255	  10.67.15.37			   3	   1
      255.255.255.255  255.255.255.255	192.168.10.12   192.168.10.12	   1
    Основной шлюз:		 10.67.15.37
    
    

    iptables-save:

    # Generated by iptables-save v1.4.4 on Mon Sep 19 09:21:42 2011
    *nat
    :PREROUTING ACCEPT [1387473:103236579]
    :POSTROUTING ACCEPT [1306517:93445583]
    :OUTPUT ACCEPT [1947798:146149985]
    -A POSTROUTING -o ppp0 -j MASQUERADE
    COMMIT
    # Completed on Mon Sep 19 09:21:42 2011
    # Generated by iptables-save v1.4.4 on Mon Sep 19 09:21:42 2011
    *mangle
    :PREROUTING ACCEPT [15816628:5096781475]
    :INPUT ACCEPT [3796648:626876795]
    :FORWARD ACCEPT [33946751:24415528825]
    :OUTPUT ACCEPT [3731124:476678886]
    :POSTROUTING ACCEPT [18370446:19338407950]
    -A PREROUTING -i lo -j ACCEPT
    -A PREROUTING -i ppp0 -j ACCEPT
    -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A FORWARD -o ppp9 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A FORWARD -o ppp5 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A FORWARD -o ppp12 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A FORWARD -o ppp11 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A FORWARD -o ppp6 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A FORWARD -o ppp7 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A FORWARD -o ppp4 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A FORWARD -o ppp3 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A FORWARD -o ppp2 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A FORWARD -o ppp1 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS																		  --clamp-mss-to-pmtu
    -A POSTROUTING -o lo -j ACCEPT
    -A POSTROUTING -o ppp0 -j ACCEPT
    COMMIT
    
    

    В чем может быть проблема? в iptables не взуб ногой….



  • фаер был закрытый…



  • @schmel:

    фаер был закрытый…

    т.е. решил? если нет, то FILTER бы ещё табличку посмотреть…



  • пока решаю…
    никак не могу понять как разрешить пакетам свободно "ходить" через eth0.
    Сервер никак локальных клиентов не может пинговать =(
    iptables -L

    Chain INPUT (policy DROP)
    target     prot opt source               destination
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh
    NFQUEUE    all  --  anywhere             anywhere            NFQUEUE num 0
    ACCEPT     all  --  anywhere             anywhere
    
    Chain FORWARD (policy DROP)
    target     prot opt source               destination
    NFQUEUE    all  --  anywhere             anywhere            NFQUEUE num 0
    
    Chain OUTPUT (policy DROP)
    target     prot opt source               destination
    ACCEPT     tcp  --  anywhere             anywhere            tcp spt:ssh
    NFQUEUE    all  --  anywhere             anywhere            NFQUEUE num 0
    ACCEPT     all  --  anywhere             anywhere
    

    iptables-save

    root@lamp ~# iptables-save
    # Generated by iptables-save v1.4.4 on Tue Sep 20 11:40:35 2011
    *filter
    :INPUT DROP [0:0]
    :FORWARD DROP [1:71]
    :OUTPUT DROP [0:0]
    -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
    -A INPUT -i ppp0 -j NFQUEUE --queue-num 0
    -A INPUT -j ACCEPT
    -A FORWARD -j NFQUEUE --queue-num 0
    -A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT
    -A OUTPUT -o ppp0 -j NFQUEUE --queue-num 0
    -A OUTPUT -j ACCEPT
    COMMIT
    # Completed on Tue Sep 20 11:40:35 2011
    # Generated by iptables-save v1.4.4 on Tue Sep 20 11:40:35 2011
    *nat
    :PREROUTING ACCEPT [51266:3564685]
    :POSTROUTING ACCEPT [33160:2361210]
    :OUTPUT ACCEPT [48506:3621584]
    -A POSTROUTING -o ppp0 -j SNAT --to-source 85.237.46.30
    COMMIT
    # Completed on Tue Sep 20 11:40:35 2011
    # Generated by iptables-save v1.4.4 on Tue Sep 20 11:40:35 2011
    *mangle
    :PREROUTING ACCEPT [493942:304717401]
    :INPUT ACCEPT [98561:14431403]
    :FORWARD ACCEPT [969762:741240740]
    :OUTPUT ACCEPT [95875:11804316]
    :POSTROUTING ACCEPT [486840:437728486]
    -A PREROUTING -i lo -j ACCEPT
    -A PREROUTING -i lo -j ACCEPT
    -A PREROUTING -i ppp0 -j ACCEPT
    -A FORWARD -o ppp10 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss                                                             -to-pmtu
    -A POSTROUTING -o lo -j ACCEPT
    -A POSTROUTING -o lo -j ACCEPT
    -A POSTROUTING -o ppp0 -j ACCEPT
    COMMIT
    # Completed on Tue Sep 20 11:40:35 2011
    


  • Какие странные правила… кто их создавал?



  • traffpro.
    На форуме у них сказали вот что:

    судя по правилам сам traffpro всё поставил, но вот интересный момент, у вас все порты закрыты кроме 22го, у вас сам файрвол по умолчанию закрыт, либо настройте и включите защиту в traffpro (она откроет во внутреннюю сеть карту), либо настройте вайрвол по умолчанию, либо просто добавьте в файл traffpro_rule.cfg правила iptables для открытия нужных портов и протоколов.

    На этом и застрял. Traffpro сам добавляем определенные правила в iptables. Если нужны свои, то нужно добавлять в traffpro_rule.cfg
    У меня в этом файле:

    # Позволит не потерять контроль над сервером при включённой защите сервера.
    iptables -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT
    iptables -A OUTPUT -m tcp -p tcp --sport 22 -j ACCEPT
    
    modprobe ip_conntrack_ftp
    modprobe ip_nat_ftp
    

    Защиту сервера включил, не помогло. На тамошнем форуме молчат http://www.traffpro.ru/forum/topic_2216/1



  • попробуй добавить

    iptables -A FORWARD -p icmp -j ACCEPT
    

    если не поможет, то

    iptables -A INPUT -p icmp -j ACCEPT
    iptables -A FORWARD -p icmp -j ACCEPT
    iptables -A OUTPUT -p icmp -j ACCEPT
    

    и покажи после этого опять```
    iptables -L -nv



  • iptables -A FORWARD -p icmp -j ACCEPT

    Спасибо за помощь.
    С этим правилом вроде пинг идет (а может он шел и без правила, просто из-за трудности проверить клиентские компы (в 150 километрах), я не заметил), но если у пользователя отключено pppoe соединение. Как только соединение устанавливается, сервер перестает пинговать клиента по локальному IP.

    route print при включенном PPPoE

    Активные маршруты:
    Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
              0.0.0.0          0.0.0.0       10.67.15.7      10.67.15.7       1
              0.0.0.0          0.0.0.0   192.168.10.254   192.168.10.12       21
           10.67.15.7  255.255.255.255        127.0.0.1       127.0.0.1       50
       10.255.255.255  255.255.255.255       10.67.15.7      10.67.15.7       50
            127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
         192.168.10.0    255.255.255.0    192.168.10.12   192.168.10.12       20
        192.168.10.12  255.255.255.255        127.0.0.1       127.0.0.1       20
       192.168.10.254  255.255.255.255       10.67.15.7      10.67.15.7       1
       192.168.10.255  255.255.255.255    192.168.10.12   192.168.10.12       20
            224.0.0.0        240.0.0.0    192.168.10.12   192.168.10.12       20
            224.0.0.0        240.0.0.0       10.67.15.7      10.67.15.7       1
      255.255.255.255  255.255.255.255       10.67.15.7      10.67.15.7       1
      255.255.255.255  255.255.255.255       10.67.15.7               3       1
      255.255.255.255  255.255.255.255    192.168.10.12   192.168.10.12       1
    Основной шлюз:          10.67.15.7
    

    при отключенном PPPoE:

    Активные маршруты:
    Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
              0.0.0.0          0.0.0.0   192.168.10.254   192.168.10.12       20
            127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
         192.168.10.0    255.255.255.0    192.168.10.12   192.168.10.12       20
        192.168.10.12  255.255.255.255        127.0.0.1       127.0.0.1       20
       192.168.10.255  255.255.255.255    192.168.10.12   192.168.10.12       20
            224.0.0.0        240.0.0.0    192.168.10.12   192.168.10.12       20
      255.255.255.255  255.255.255.255    192.168.10.12   192.168.10.12       1
      255.255.255.255  255.255.255.255    192.168.10.12               3       1
    Основной шлюз:      192.168.10.254
    


  • Это таблица маршрутизации с сервера? Какой локальный IP клиента пингуем?



  • это с клиента.
    с сервера вот:

    root@lamp ~# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.16.0.5       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
    10.67.15.9      0.0.0.0         255.255.255.255 UH    0      0        0 ppp6
    80.95.33.102    0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
    10.67.15.1      0.0.0.0         255.255.255.255 UH    0      0        0 ppp1
    10.67.15.3      0.0.0.0         255.255.255.255 UH    0      0        0 ppp3
    10.16.0.0       10.16.0.5       255.255.255.0   UG    0      0        0 tun0
    192.168.1.0     10.16.0.5       255.255.255.0   UG    0      0        0 tun0
    192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
    0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
    

    С сервера пингую 192.168.10.12 (клиентский комп за сетью с traffpro)



  • стоп, запутался, где iptables - на сервере или клиенте?



  • iptables на сервере. Клиенты - это рабочии станции.
    Сервер:
    Внешний интерфейс ppp0 - со статически выдаваемым белым IP.
    Клиенты подключаются через PPPoE, получают адреса из подсети 10.67.15.0/24.  В интернет выходят нормально. Но вот только при работающем PPPoE не пингуются клиенты с сервера по локальным IP. И клиенты не могут пинговать сервер по локальному IP и IP за OpenVPN. Как только отключить PPPoE на клиенте, все нормально…
    Тут скорее в маршрутизации затык и фаере...



  • а на клиентах есть firewalls?
    Попробуй на сервере

    tcpdump -ni eth0 icmp or arp
    

    и пингуй при поднятом PPPoE и опущенном.



  • При поднятом:

    root@lamp ~# tcpdump -ni eth0 icmp or arp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
    08:12:18.396627 ARP, Request who-has 192.168.10.12 tell 192.168.10.254, length 28
    08:12:18.396826 ARP, Reply 192.168.10.12 is-at 6c:f0:49:dd:1d:7e, length 46
    08:12:18.396837 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 1, length 64
    08:12:19.402716 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 2, length 64
    08:12:20.410708 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 3, length 64
    08:12:20.530090 ARP, Request who-has 192.168.1.29 tell 192.168.1.44, length 46
    08:12:20.530254 ARP, Request who-has 192.168.1.44 tell 192.168.1.29, length 46
    08:12:21.418707 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 4, length 64
    08:12:22.426220 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 5, length 64
    08:12:23.434707 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 6, length 64
    08:12:24.079936 ARP, Request who-has 192.168.1.21 tell 192.168.1.44, length 46
    08:12:24.442662 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 7, length 64
    08:12:25.450172 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 8, length 64
    08:12:26.458209 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 9, length 64
    08:12:27.466209 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 10, length 64
    
    

    При отключенном:

    08:53:03.322004 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 1, length 64
    08:53:04.330730 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 2, length 64
    08:53:05.338207 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 3, length 64
    08:53:06.346213 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 4, length 64
    08:53:06.346427 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 4, length 64
    08:53:07.345210 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 5, length 64
    08:53:07.345444 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 5, length 64
    08:53:08.344218 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 6, length 64
    08:53:08.344362 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 6, length 64
    08:53:09.345254 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 7, length 64
    08:53:09.345466 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 7, length 64
    08:53:10.348279 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 8, length 64
    08:53:10.348498 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 8, length 64
    08:53:11.348148 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 9, length 64
    
    


  • Ну вот, правила на сервере не при чём.
    Клиент почему-то не отвечает при поднятом VPN, ковыряй клиентов. Не в курсе, как с OpenVPN, но с некоторыми типами VPN клиент маршрутизирует весь трафик через поднятый канал, и ничего не разрешается через другие интерфейсы (в целях безопасности), может у тебя что-то похожее.



  • Спасибо буду "пинать" клиентов. VPN на сервере работает, а у клиентов обычное PPPoE соединение для выхода в инет.



  • а на виндовых клиентах роуты бывает неотрабатываются



  • @schmel:

    Спасибо буду "пинать" клиентов. VPN на сервере работает, а у клиентов обычное PPPoE соединение для выхода в инет.

    Тогда не знаю, на клиентах бы ещё потисипидампить…



  • Клиент - 192.168.10.12
    Сервер - 192.168.10.254
    PPPoE IP - 10.67.15.9
    вот tcpdum с клиентов c включенным PPPoE:
    1. ping сервера (192.168.10.254)

    2. ping сервера за openvpn 192.168.1.200

    3. ping клиента с сервера

    Еще раз напишу, при подключении PPPoE связь с удаленным сервером за OpenVPN, теряется (192.168.1.200)
    Как только отключается PPPoE то все нормально.



  • Вот при таких правилах связь есть по локалке
    iptables -A FORWARD -p icmp -j ACCEPT
    iptables -I FORWARD 1 -i eth0 -o tun0 -j ACCEPT
    iptables -I FORWARD 1 -o eth0 -i tun0 -j ACCEPT

    а как сделать подобное еще и для ppp интерфейсов?
    Каждый подключенный пользователь рандомно получает ppp интерфейс (всмыле ppp1, ppp2 и тп.)


Log in to reply