Виртуальное сетевой устройство с криптованием

Вопросы программного кода и архитектуры Linux

Модератор: Olej

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Виртуальное сетевой устройство с криптованием

Непрочитанное сообщение Olej » 16 мар 2012, 19:11

Olej писал(а): Сначала я грешил на то, что делаю запуск wireshark удалённо на X11 в LAN, по ssh, как-то так:

Код: Выделить всё

[olej@notebook ~]$ ssh -X olej@192.168.1.20
Address 192.168.1.20 maps to nvidia, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
olej@192.168.1.20's password: 
Last login: Fri Mar 16 14:51:46 2012 from notebook
/usr/bin/xauth:  file /home/olej/.Xauthority does not exist
[olej@nvidia ~]$ wireshark
Но и окно wireshark и окно ошибки прорисовывается на удалённом дисплее X11...
Запустил я таки удалённо wireshark из VM в сессии ssh, но уж совсем через задницу:

Код: Выделить всё

[olej@nvidia ~]$ su -c wireshark
Пароль: 
Wireshark_VM.png
Wireshark_VM.png (78.23 КБ) 7884 просмотра
- вот оно, с теми дурацкими интерфейсами p2p1, p7p1 ...
- со всеми предупреждениями, естественно, о грядущих неприятностях...
Теперь появилось окно для наблюдения: что ж там в VM происходит? ;-)

Но хотелось бы помощь зала: можно его как-то более нормально запускать?

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Виртуальное сетевой устройство с криптованием

Непрочитанное сообщение Olej » 16 мар 2012, 20:16

kit_D писал(а): Вот что надо сделать чтобы заставить эту адскую смесь работать:

insmod crypto0.ko
ifconfig crypto down
ifconfig crypto 172.28.155.7
./crypto_us wlan0
route del -net 172.28.155.0/24 wlan0
ifconfig crypto up

Обратите внимание, что crypto будет иметь тот же MAC и IP адрес что и wlan0. Это пока не совсем очевидно, надо подумать.
В результате, пинг на 172.28.155.3 успешно проходит через crypto и принимается ответ от 172.28.155.3. ARP таблица также показываеть правильно заполненный кеш с записями соответствующими crypto интерфейсу.
kit_D писал(а):
Вы вероятно намекаете на RX_HANDLER_ANOTHER ? Стоит попробовать.
Выкладываю последние изменения в модуле. Действительно подправив немного rx_handler_result_t handle_frame тоже работает. Часть кода соответственно ушла в небытие.
Похоже, что по какой то причине проблема с отключение WiFi сети тоже отпала - не уверен почему.
Медленно и по шагам ;-)

Код: Выделить всё

[olej@nvidia virt]$ sudo insmod crypto2.ko 
[olej@nvidia virt]$ lsmod | head -n4
Module                  Size  Used by
crypto2                12664  0 
bluetooth             209810  0 
rfkill                 20448  1 bluetooth
[olej@nvidia virt]$ ifconfig
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:29013 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29013 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:11504028 (10.9 MiB)  TX bytes:11504028 (10.9 MiB)

p2p1      Link encap:Ethernet  HWaddr 08:00:27:47:CF:BE  
          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe47:cfbe/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:57224 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45676 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:42274762 (40.3 MiB)  TX bytes:14048549 (13.3 MiB)

p7p1      Link encap:Ethernet  HWaddr 08:00:27:B0:D2:2E  
          inet addr:192.168.56.102  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feb0:d22e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:63 errors:0 dropped:0 overruns:0 frame:0
          TX packets:65 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:17902 (17.4 KiB)  TX bytes:11113 (10.8 KiB)
Мне уже к этому месту странно, что модуль есть, а интерфейска ещё нет, зачем же вы сразу делаете down?:

Код: Выделить всё

[olej@nvidia virt]$ sudo ifconfig crypto down
[olej@nvidia virt]$ 
[olej@nvidia virt]$ dmesg | tail -n3
[16332.909530] device p2p1 left promiscuous mode
[16333.132988] device p2p1 entered promiscuous mode
[19563.994248] loaded
[olej@nvidia virt]$ sudo ifconfig crypto 192.168.56.102
здесь что-то произошло (хотя up не было):

Код: Выделить всё

[olej@nvidia virt]$ dmesg | tail -n10
[19940.904095] crypto: crypto_xmit
[19941.047382] crypto: crypto_xmit
[19941.769858] crypto: crypto_xmit
[19942.927460] crypto: crypto_xmit
[19942.960100] crypto: crypto_xmit
[19943.120096] crypto: crypto_xmit
[19946.490446] SELinux: initialized (dev fuse, type fuse), uses genfs_contexts
[19947.072157] crypto: crypto_xmit
[19947.128134] crypto: crypto_xmit
[19948.130058] crypto: no IPv6 routers present

Код: Выделить всё

[olej@nvidia virt]$ sudo ./crypto_us p7p1
[olej@nvidia virt]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 p2p1
192.168.1.0     *               255.255.255.0   U     1      0        0 p2p1
192.168.56.0    *               255.255.255.0   U     0      0        0 crypto
192.168.56.0    *               255.255.255.0   U     1      0        0 p7p1

Код: Выделить всё

[olej@nvidia virt]$ sudo route del -net 192.168.56.0/24 p7p1
[olej@nvidia virt]$ sudo ifconfig crypto up
[olej@nvidia virt]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 p2p1
192.168.1.0     *               255.255.255.0   U     1      0        0 p2p1
192.168.56.0    *               255.255.255.0   U     0      0        0 crypto
ОК?

Код: Выделить всё

[olej@nvidia virt]$ ifconfig
crypto    Link encap:Ethernet  HWaddr 08:00:27:B0:A9:72  
          inet addr:192.168.56.102  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feb0:a972/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:129 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:668 (668.0 b)  TX bytes:12678 (12.3 KiB)
...
p7p1      Link encap:Ethernet  HWaddr 08:00:27:B0:D2:2E  
          inet addr:192.168.56.102  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feb0:d22e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:66 errors:0 dropped:0 overruns:0 frame:0
          TX packets:170 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:18612 (18.1 KiB)  TX bytes:19141 (18.6 KiB)
как-то оно живёт, но очень-очень слабенько ;-)

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Виртуальное сетевой устройство с криптованием

Непрочитанное сообщение Olej » 16 мар 2012, 20:25

Olej писал(а):как-то оно живёт, но очень-очень слабенько ;-)
Вот с базовой системы, где стоит эта VM:

Код: Выделить всё

[olej@nvidia ~]$ arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.56.102           ether   08:00:27:b0:a9:72   C                     vboxnet0
192.168.1.22             ether   00:13:02:69:70:9b   C                     eth0
192.168.1.1              ether   c8:64:c7:8a:50:16   C                     eth0

Код: Выделить всё

[olej@nvidia ~]$ ping 192.168.56.102
PING 192.168.56.102 (192.168.56.102) 56(84) bytes of data.
^C
--- 192.168.56.102 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 16000ms
т.е. туда они уходят, но назад не возвращаются...
А вот соседняя VM рядом:

Код: Выделить всё

[olej@nvidia ~]$ ping 192.168.56.101
PING 192.168.56.101 (192.168.56.101) 56(84) bytes of data.
64 bytes from 192.168.56.101: icmp_req=1 ttl=64 time=1.91 ms
64 bytes from 192.168.56.101: icmp_req=2 ttl=64 time=0.244 ms
64 bytes from 192.168.56.101: icmp_req=3 ttl=64 time=0.250 ms
^C
--- 192.168.56.101 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.244/0.804/1.919/0.788 ms
Вложения
Wireshark-ping.png
Wireshark-ping.png (55.45 КБ) 7884 просмотра

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Виртуальное сетевой устройство с криптованием

Непрочитанное сообщение Olej » 16 мар 2012, 20:38

Olej писал(а): т.е. туда они уходят, но назад не возвращаются...
Что хорошо в этом модуле - так это то, что он хорошо выгружается :lol: :

Код: Выделить всё

[root@nvidia ~]# rmmod crypto2
[root@nvidia ~]# ifconfig p7p1 down
[root@nvidia ~]# ifconfig p7p1 up
и с хост-машины:

Код: Выделить всё

[olej@nvidia ~]$ ping 192.168.56.102
PING 192.168.56.102 (192.168.56.102) 56(84) bytes of data.
64 bytes from 192.168.56.102: icmp_req=1 ttl=64 time=0.362 ms
64 bytes from 192.168.56.102: icmp_req=2 ttl=64 time=0.213 ms
64 bytes from 192.168.56.102: icmp_req=3 ttl=64 time=0.163 ms
64 bytes from 192.168.56.102: icmp_req=4 ttl=64 time=0.205 ms
^C
--- 192.168.56.102 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.163/0.235/0.362/0.077 ms
Перезагружать VM не надо. ;-)

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Виртуальное сетевой устройство с криптованием

Непрочитанное сообщение Olej » 16 мар 2012, 21:58

kit_D писал(а):Конечно, wireshark можно выполнять только только рутом, так же как и tcpdump. Они оба используют такую вещь, которая если я не ошибаюсь называется BPF.
1. tcpdump далеко не всегда нужен root, это не потому, что он использует BPF (Bercley Packet Filter), а только когда он (если я не забыл) должен использовать promiscous mode интерфейса (он должен его туда переводить, а для этого нужен root).
2. wireshark, запущенный под root - нещадно ругается и обещает все беды на голову...
3. но противнее всего то, что wireshark в Fedora 12 прекрасно чувствует себя без root, ставился yum-ом из репозитария ... никаких фокусов:
Version 1.2.13,
Running on Linux 3.0.9, with libpcap version 1.0.0, GnuTLS 2.8.6, Gcrypt 1.4.4.
Built using gcc 4.4.4 20100630 (Red Hat 4.4.4-10).
... а wireshark в Fedora 16 - кочевряжится, и требует root:
Version 1.6.5 (SVN Rev Unknown from unknown)
Running on Linux 3.2.9-2.fc16.i686, with libpcap version 1.1.1, with libz 1.2.5,
GnuTLS 2.12.14, Gcrypt 1.5.0, without AirPcap.
Built using gcc 4.6.2 20111027 (Red Hat 4.6.2-1).

kit_D
Писатель
Сообщения: 52
Зарегистрирован: 13 мар 2012, 13:14
Откуда: Харьков
Контактная информация:

Re: Виртуальное сетевой устройство с криптованием

Непрочитанное сообщение kit_D » 17 мар 2012, 22:27

Кстати, один заокеанский товарищ подкинул мне такую ссылочку:

http://lwn.net/Articles/204435/

Тут функции шифрования (ccrypt_encrypt и ccrypt_decrypt) прямо вызываются из dev_queue_xmit() и netif_receive_skb() соответственно, путем патча ядра конечно. Что в моем случае неприемлемо, но все равно интересно посмотреть.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Виртуальное сетевой устройство с криптованием

Непрочитанное сообщение Olej » 19 мар 2012, 02:52

Olej писал(а):как-то оно живёт, но очень-очень слабенько ;-)
Очень осторожно нужно с этими функциями skb-перехватов, если в функции "перекладывания" на приёме записать вот так:

Код: Выделить всё

rx_handler_result_t handle_frame( struct sk_buff **pskb ) {
      ...
      skb->dev = child_dev;
      netif_receive_skb( skb );
      return RX_HANDLER_ANOTHER;
   }
- то получается сетевой интерфейс, который крнфигурируется, подымается ... но первейший на его адрес ping заваливает ядро Linux, что он и пикнуть не успевает...
Интересный получается эффект.
Конечно, такие вещи лучше отыгрывать на виртуальной машине.

kit_D
Писатель
Сообщения: 52
Зарегистрирован: 13 мар 2012, 13:14
Откуда: Харьков
Контактная информация:

Re: Виртуальное сетевой устройство с криптованием

Непрочитанное сообщение kit_D » 20 мар 2012, 11:40

...
skb->dev = child_dev;
netif_receive_skb( skb );
return RX_HANDLER_ANOTHER;
Погодите-ка, по моему мнению правильнее будет в этом месте написать:
skb->dev = child_dev;
return RX_HANDLER_ANOTHER;

Так как у меня и было написано в последней версии модуля.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: Виртуальное сетевой устройство с криптованием

Непрочитанное сообщение Olej » 20 мар 2012, 12:22

kit_D писал(а):
...
skb->dev = child_dev;
netif_receive_skb( skb );
return RX_HANDLER_ANOTHER;
Погодите-ка, по моему мнению правильнее будет в этом месте написать:
skb->dev = child_dev;
return RX_HANDLER_ANOTHER;

Так как у меня и было написано в последней версии модуля.
Абсолютно верно!
Так и есть.
Я только сказал, что если по неаккуратности написать так как показано у меня, то при первейшем ping-е Linux умирает даже пикнув не успевая (Ooops, вывод в консоль текстовую...).

Ответить

Вернуться в «Linux изнутри»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 4 гостя