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

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

Модератор: Olej

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

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

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

kit_D писал(а):Выкладываю новую версия кода.
Слегка изменилась архитектура. После загрузки модуля появляется новое устройство crypto, но оно пока не ассоциировано с реальным(подчиненным, slave) устройством. Для того чтобы сделать такую ассоциацию надо вызвать команду:
./crypto_us wlan0
Она назначает устройству crypto подчиненное устройство wlan0. Вероятно это будет работать если подчиненное устройство eth<N> - не знаю, не проверял.
1. Мне так кажется, что модуль (драйвер) xxx реализующий виртуальный интерфейс yyy должен был бы а). получать параметром загрузки модуля имя родительского интерфейса (zzz), на который он должен подсесть и б). должен делать это подсаживание именно в инициализирующей части модуля.

2. Если же даже, в силу каких-то ТЗ условий, этот параметр нужно устанавливать позже, runtime, то я уж точно не делал бы это ioctl(): а). из-за безконтролькости ioctl(), а значит его опасности, б). это старый, отживающий механизм, в) если это так сильно надо, то сделать это чтением-записью через /proc или /sys: viewtopic.php?f=18&t=1617

3. После чего активизировать (подымать) новый интерфейс с IP в отдельной подсети... чтобы потоки данных yyy & zzz могли динамически различаться. И не исключено, что и MAC этому интерфейсу присвоить совершенно фиктивный.

4. Мне так кажется, что не нужно весь поток zzz (родителя) подменять потоком yyy.

5. На приёме это функция (в примере):

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

rx_handler_result_t handle_frame( struct sk_buff **pskb ) {
...
Как мне кажется, нужно очень тщательно ещё раз разобраться-перепробовать с возвращаемыми значениями такой функции, то, что описано в комментариях:
http://lxr.free-electrons.com/source/in ... ce.h?v=3.0

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

393 /*
394  * enum rx_handler_result - Possible return values for rx_handlers.
395  * @RX_HANDLER_CONSUMED: skb was consumed by rx_handler, do not process it
396  * further.
397  * @RX_HANDLER_ANOTHER: Do another round in receive path. This is indicated in
398  * case skb->dev was changed by rx_handler.
399  * @RX_HANDLER_EXACT: Force exact delivery, no wildcard.
400  * @RX_HANDLER_PASS: Do nothing, passe the skb as if no rx_handler was called.
401  *
402  * rx_handlers are functions called from inside __netif_receive_skb(), to do
403  * special processing of the skb, prior to delivery to protocol handlers.
404  *
405  * Currently, a net_device can only have a single rx_handler registered. Trying
406  * to register a second rx_handler will return -EBUSY.
407  *
408  * To register a rx_handler on a net_device, use netdev_rx_handler_register().
409  * To unregister a rx_handler on a net_device, use
410  * netdev_rx_handler_unregister().
411  *
412  * Upon return, rx_handler is expected to tell __netif_receive_skb() what to
413  * do with the skb.
414  *
415  * If the rx_handler consumed to skb in some way, it should return
416  * RX_HANDLER_CONSUMED. This is appropriate when the rx_handler arranged for
417  * the skb to be delivered in some other ways.
418  *
419  * If the rx_handler changed skb->dev, to divert the skb to another
420  * net_device, it should return RX_HANDLER_ANOTHER. The rx_handler for the
421  * new device will be called if it exists.
422  *
423  * If the rx_handler consider the skb should be ignored, it should return
424  * RX_HANDLER_EXACT. The skb will only be delivered to protocol handlers that
425  * are registred on exact device (ptype->dev == skb->dev).
426  *
427  * If the rx_handler didn't changed skb->dev, but want the skb to be normally
428  * delivered, it should return RX_HANDLER_PASS.
429  *
430  * A device without a registered rx_handler will behave as if rx_handler
431  * returned RX_HANDLER_PASS.
432  */
433 
434 enum rx_handler_result {
435         RX_HANDLER_CONSUMED,
436         RX_HANDLER_ANOTHER,
437         RX_HANDLER_EXACT,
438         RX_HANDLER_PASS,
439 };
440 typedef enum rx_handler_result rx_handler_result_t;
441 typedef rx_handler_result_t rx_handler_func_t(struct sk_buff **pskb);
И (перехватывать) перенаправлять имело бы смысл только те skb, которые относятся к новому интерфейсу yyy, но не затрагивать родной поток родителя ... и тогда не будет разрушаться работа WiFi. А различаться они должны, наверное, по IP подсетей, если они отличаются.

5. И то же самое на передаче, когда перенаправляются пакеты в zzz, в:

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

netdev_tx_t crypto_xmit( struct sk_buff *skb, struct net_device *dev ) {

P.S. я там, кстати, совсем не понял там:

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

skb->priority = 1;
- это что?

6. Конечно, сначала это всё лучше отыгрывать на проводном eth0 или виртуальном p2p1. И только потом wlan0.

7. А чем вы смотрите "работает - не работает"?
Чтоб не строить здесь соображения на догадках.
Я так понимаю, что это нужно на физический интерфейс вешать tcpdump, и хоть это громоздко и противно - подбирать его фильтры и наблюдать выборочно свои потоки.

Вот это всё хочется попробовать.

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

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

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

>> Если же даже, в силу каких-то ТЗ условий, этот параметр нужно устанавливать позже, runtime, то я уж точно не делал бы это ioctl():
Ну это да, но мне кажется надо добиться правильной работы модуля, о потом уже подправлять интерфейсы.
И да, базовый WiFi интерфейс может подключаться-отключаться из за особенностей работы на мобильном девайсе. В этом случае надо будет переасаоциировать подчиненный интерфейс.

>>После чего активизировать (подымать) новый интерфейс с IP в отдельной подсети... чтобы потоки данных yyy & zzz
>>могли динамически различаться. И не исключено, что и MAC этому интерфейсу присвоить совершенно фиктивный
Нет, так не пойдет. МАК должен быть тот же - идея то в том, что извне и не видно никакого фиктивного интерфейса, ни его фиктивного МАКа ни его фиктивного IP. Наружу все должно идти так, как шло бы если бы никакого фиктивного интерфейса не было - в этом вся идея! Ну и конечно же криптование пейлоада фрейма. Иначе, фиктивный МАК адрес точка доступа не пропустит, фиктивный IP зарежет фаервол, шлюз..
Так что тут без вариантов!

>>Мне так кажется, что не нужно весь поток zzz (родителя) подменять потоком yyy.
В том то и дело что нужно, но кроме тех пакетов которые поддерживают базовую WiFi сеть в работоспособном состоянии. А именно, точка доступа и станция переодически обмениваются EAP пакетами с информацией о ключах шифрования, это по стандарту 802.1x (авторизация), 802.11i (WPA2). Вот их то и надо принимать на реальном интерфейсе, а остальные, так сказать сам трафик надо передавать на крипто - ведь он то и должен быть зашифрован/расшифрован!!!

>>И (перехватывать) перенаправлять имело бы смысл только те skb, которые относятся к новому интерфейсу yyy,
>> но не затрагивать родной поток родителя ... и тогда не будет разрушаться работа WiFi.
>> А различаться они должны, наверное, по IP подсетей, если они отличаются.
В том то и дело, что отличаться они не будут, IP тот же, МАК тот же, поэтому сказать какому интерфейсу предназначены нельзя, но ведь это и есть то что надо - извне никакого внутреннего интерфейса не видно, а он то есть, да еще и шифрует/дешифрует трафик

И еще, по-поводу одинаковых IP адресов. Идея такой реализации с перекладыванием исходящих пакетов из псевдо-интерфейса в реальный у меня появилась на основе двух вещей
1) Трафик шейпер, написанный Аланом Коксом работает на том же принципе: http://lwn.net/1998/1119/shaper.html
Цитата: The host/address, mask, and broadcast parameters need to match those of the underlying physical interface.

2) Insane инетрфейс, который эмулирует потерю пакетов используя аналогичный принцип: http://www.linux.it/~rubini/docs/vinter/vinter.html
Цитата:
borea# insmod insane ; # load module
borea# ifconfig insane borea ; # give same IP as eth0
Обратите на єто внимание пожалуйста - интересные модули, которые как раз и реализуют половину моей идеи - только отправку пакетов, в отличие от моего модуля, который делает еще и прием.

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

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

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

>> 7. А чем вы смотрите "работает - не работает"?
>> Чтоб не строить здесь соображения на догадках.
>> Я так понимаю, что это нужно на физический интерфейс вешать tcpdump, и хоть это громоздко и противно -
>> подбирать его фильтры и наблюдать выборочно свои потоки.
Во первых - самый надежный способ - пинг. Для этого надо чтобы маршрутизация указывала именно на crypto. В этом смысле работает, даже АРП разрешается

Во-вторых - tcpdump. В нем на физическом интерфейсе вы наверное увидите только исходящие пакеты, ведь входящие я перекладываю. Скорее всего так и будет.
Кроме того я уже давно пользуюсь wireshark - гуи для tcpdump. Весьма удобно.
А насчет ключей - их подбирать не надо, надо только указать имя интерфейса. В случае с tcpdump:
tcpdump -i crypto
tcpdump -i wlan0
Еще полезно:
arp -n

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

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

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

rx_handler_result_t handle_frame( struct sk_buff **pskb )
Как мне кажется, нужно очень тщательно ещё раз разобраться-перепробовать
с возвращаемыми значениями такой функции, то, что описано в комментариях:

Вы вероятно намекаете на RX_HANDLER_ANOTHER ? Стоит попробовать.

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

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

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

kit_D писал(а): >>После чего активизировать (подымать) новый интерфейс с IP в отдельной подсети... чтобы потоки данных yyy & zzz
>>могли динамически различаться. И не исключено, что и MAC этому интерфейсу присвоить совершенно фиктивный
Нет, так не пойдет. МАК должен быть тот же - идея то в том, что извне и не видно никакого фиктивного интерфейса, ни его фиктивного МАКа ни его фиктивного IP. Наружу все должно идти так, как шло бы если бы никакого фиктивного интерфейса не было - в этом вся идея! Ну и конечно же криптование пейлоада фрейма. Иначе, фиктивный МАК адрес точка доступа не пропустит, фиктивный IP зарежет фаервол, шлюз..
Так что тут без вариантов!
Что значит должен быть?
Меня в этой связи интересует аналогия с OpenVPN, который садится на активный физический интерфейс.
(и не только OpenVPN, ... любой - CiscoSystemsVPNClient ... кстати, он есть в исходниках, и я его собирал под новые ядра, потому что там править нужно, родной он не собирается - может исходники сюда выкинуть?)
И там тоже везде закрытый шифрованный канал.
И здесь интересный вопрос ... я пока поработал с ними - задался:
- у меня есть WiFi и проводной eth0, ...
- если подключить кабель eth0, то WiFi отключается - это что-то с работой Network Menager ... то, что не может быть 2-х интерфейсов с одной подсеткой;
- но OpenVPN, когда подымаеся - всегда запускается над тем интерфейсом, который сейчас активный.

А если вам нужен хакинг, кого-то надурить, чтобы трафик ваш выглядел точно так же (IP, MAC) как с WiFi интерфейса - так это совсем другая задача, вы тогда на уровне протокола (сетевого, транспортного) интерфейса wlan0 ставите фильтр, который будет криптографировать ваш поток, туда и обратно, но уже к исходному интерфейсу wlan0.

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

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

Непрочитанное сообщение Olej » 15 мар 2012, 23:31

Olej писал(а): Меня в этой связи интересует аналогия с OpenVPN, который садится на активный физический интерфейс.
(и не только OpenVPN, ... любой - CiscoSystemsVPNClient ... кстати, он есть в исходниках, и я его собирал под новые ядра, потому что там править нужно, родной он не собирается - может исходники сюда выкинуть?)
И там тоже везде закрытый шифрованный канал.
И здесь интересный вопрос ... я пока поработал с ними - задался:
- у меня есть WiFi и проводной eth0, ...
- если подключить кабель eth0, то WiFi отключается - это что-то с работой Network Menager ... то, что не может быть 2-х интерфейсов с одной подсеткой;
- но OpenVPN, когда подымаеся - всегда запускается над тем интерфейсом, который сейчас активный.
Смотрите!

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

[olej@notebook ~]$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:15:60:C4:EE:02  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:16 
...
wlan0     Link encap:Ethernet  HWaddr 00:13:02:69:70:9B  
          inet addr:192.168.1.22  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::213:2ff:fe69:709b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14383 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13153 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8547337 (8.1 MiB)  TX bytes:3064305 (2.9 MiB)
- вот интерфейсы, когда VPN не поднят, и роутинг:

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

[olej@notebook ~]$ 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 wlan0
192.168.1.0     *               255.255.255.0   U     2      0        0 wlan0
А вот я подымаю VPN ... ровно в ту сильно удалённую сеть компании, в которой вы сидите и где делаете эксперименты :lol: :

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

[olej@notebook ~]$ ifconfig
...
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.27.231  P-t-P:192.168.27.231  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1412  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:837 (837.0 b)  TX bytes:408 (408.0 b)

wlan0     Link encap:Ethernet  HWaddr 00:13:02:69:70:9B  
          inet addr:192.168.1.22  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::213:2ff:fe69:709b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14406 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13174 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8551415 (8.1 MiB)  TX bytes:3069462 (2.9 MiB)
- над wlan0 поднялся интерфейс из совсем другой подсетки (близкой, но другой) + посмотрите какой MAC у tun0, и тут же под него перестроился роутинг:

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

[olej@notebook ~]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         ajeetsachan.syn 0.0.0.0         UG    0      0        0 wlan0
140.85.0.0      *               255.255.0.0     U     0      0        0 tun0
141.146.128.0   *               255.255.128.0   U     0      0        0 tun0
144.23.128.0    *               255.255.128.0   U     0      0        0 tun0
148.87.64.0     *               255.255.192.0   U     0      0        0 tun0
148.87.128.0    *               255.255.128.0   U     0      0        0 tun0
172.16.0.0      *               255.255.0.0     U     0      0        0 tun0
172.17.48.0     *               255.255.240.0   U     0      0        0 tun0
172.17.128.0    *               255.255.240.0   U     0      0        0 tun0
172.22.0.0      *               255.255.0.0     U     0      0        0 tun0
172.24.0.0      *               255.255.0.0     U     0      0        0 tun0
172.25.0.0      *               255.255.0.0     U     0      0        0 tun0
172.28.0.0      *               255.255.0.0     U     0      0        0 tun0
192.168.0.0     *               255.255.248.0   U     0      0        0 tun0
192.168.1.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.27.0    *               255.255.255.0   U     0      0        0 tun0
ip195-234-72-5. ajeetsachan.syn 255.255.255.255 UGH   0      0        0 wlan0
и роутинг прописан отдельно через 2 интерфейса! 192.168.1.0 - через wlan0 (это моя LAN), а конкретные подсети (172.17.48.0 etc.).

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

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

Непрочитанное сообщение kit_D » 16 мар 2012, 01:06

Ну Олег Иванович, tun интерфейс єто совсем отдельная история. В линуксе есть 2 спец интерфейса, tun и tap. Их огромная особенность в том, что они отправляют трафик не в сеть, не в нет девайс, а в специальный сокет, который специальным образом открывается из юзерспейс приложения. Tun интерфейс отправляет в такой сокет IP пакеты, а его аналог, tap интерфейс, отправляет туда L2 фреймы. Далеее что делает OpenVPN это отправляет перехваченные таким образом фреймы по SSL/TCP через маршрут по умолчанию указаный в таблице маршрутизации . Все. Мне такой путь не подходит, мне надо не TCP/UDP инкапсуляция, а шифрование пайлоада фреймов и их отправка в WiFi.

>>И здесь интересный вопрос ... я пока поработал с ними - задался:
>>- у меня есть WiFi и проводной eth0, ...
>>- если подключить кабель eth0, то WiFi отключается - это что-то с работой Network Menager ... то, что не может быть 2-х интерфейсов с одной подсеткой;

У нас на самом деле один интерфейс, а второй - просто абстракция. Что значит WiFi отключается? В чем это выражается? Вероятно трафик выходит не туда, так как таблица маршрутизации приходит в неправильное состояние. Подправьте ее если надо. ДА и вообще, не надо подключать 2 реальных интерфейса в одну подсеть, это действительно не кашерно, в отличие от моего виртуального + реального с которого он забирает весь трафик. Отключите eth0, загрузите мой модуль, заассоциируйте устройства crypto и wlan0, подправьте таблицу маршрутизации и шлите пинг в крипто. В результате, АРП выйдет в вай фай, абонент ответит на МАК адрес реального устройства (помним, что у crypto и wlan0 они совпадают), реальное устройство примет АРП ответ (МАК то правильный), наш хук переложит АРП ответ из wlan0 в cryptо, и в АРП кеше появится нужная запись, далее ICMP пакет выйдет в вай фай (уже с правильным dst MAC адресом и src адресом равным реальному устройству, также как если бы мы вообще не использовали crypt), абонент ответит, мі перехватим ответ и отдадим его вверх в сетевой стек. Вот как это работает и именно такая работа и задумана была.
Одна оговорочка, WiFi настройте как открытую сеть без шифрования, иначе после загрузки crypto, через несколько минут WiFi отвалится, потому что, как я уже говорил, служебные EAP пакеты, которыми общаются точка доступа и сетевая карта для поддержки авторизованного доступа в WiFi сеть будут поглащены интерфейсом crypto и, соответственно, авторизованный доступ перекроется.

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

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

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

Olej писал(а):Вот это всё хочется попробовать.
Начал я пробовать... а "пробую" я всегда переписывая дотла - и тут почалось :-o :oops:
Все предыдущие примеры по сети, из конспекта http://rus-linux.net/MyLDP/BOOKS/Moduli ... index.html, которые заимствованы из книжки:
Jerry Cooperstein, 2009, "Linux Device Drivers" - не собираются в ядре 3.2 :-?
Не собираются элементарно, по понятным вещам: #ifdef разнообразные ... но это теперь все-все примеры нужно переписать и проверить.

Ну вы меня и сподвигли на работу! :-o

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

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

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

kit_D писал(а):Ну Олег Иванович, tun интерфейс єто совсем отдельная история. В линуксе есть 2 спец интерфейса, tun и tap. Их огромная особенность в том, что они отправляют трафик не в сеть, не в нет девайс, а в специальный сокет, который специальным образом открывается из юзерспейс приложения. Tun интерфейс отправляет в такой сокет IP пакеты, а его аналог, tap интерфейс, отправляет туда L2 фреймы. Далеее что делает OpenVPN это отправляет перехваченные таким образом фреймы по SSL/TCP через маршрут по умолчанию указаный в таблице маршрутизации . Все. Мне такой путь не подходит, мне надо не TCP/UDP инкапсуляция, а шифрование пайлоада фреймов и их отправка в WiFi.
Ну про tun и tap я как-то догадывался... ;-)
Но допустим.

P.S. здесь вот есть в тему обсуждение "OpenVPN. tun vs tap": http://forum.ubuntu.ru/index.php?topic=184209.0 - может кому любопытно будет?

Но вот снимок интерфейсов когда работает CiscoSystemsVPNClient, без тунельного интерфейса:

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

[olej@notebook net]$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN.
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 00:15:60:c4:ee:02 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:13:02:69:70:9b brd ff:ff:ff:ff:ff:ff
4: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
5: cipsec0: <NOARP> mtu 1356 qdisc noop state DOWN qlen 1000
    link/ether 00:0b:fc:f8:01:8f brd ff:ff:ff:ff:ff:ff
10: mynet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff

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

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

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

kit_D писал(а): У нас на самом деле один интерфейс, а второй - просто абстракция.
А и вправду, зачем вам 2?
На уровне протоколов (сетевого или транспортного) включите фильтр skb, который их будет уродовать под ваши требования... не то? :-(
P.S. это я имею в виду фильтры что-то из групп API dev_add_pack() и inet_add_protocol().
kit_D писал(а): Что значит WiFi отключается? В чем это выражается?
kit_D писал(а): Одна оговорочка, WiFi настройте как открытую сеть без шифрования, иначе после загрузки crypto, через несколько минут WiFi отвалится, потому что, как я уже говорил, служебные EAP пакеты, которыми общаются точка доступа и сетевая карта для поддержки авторизованного доступа в WiFi сеть будут поглащены интерфейсом crypto и, соответственно, авторизованный доступ перекроется.
Вот в том и выражается ;-)

Ответить

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

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

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