Пустой сетевой адаптер Debian 9 - работает на локальном компьютере, но не на удаленном?

Я пытаюсь настроить туннель IPSEC между моим удаленным внешним сервером и локальной машиной. У моего пульта есть голый публичный IP4 в дата-центре. У моего ближайшего сервера есть локальный скрытый адрес NAT 192.168.xy, однако я перенаправил на него все необходимые порты и протоколы; UDP 500, UDP 4500, ах, esp, а также удаление привязок помощника маршрутизатора. Оба работают под управлением Debian 9 Stretch. Мой роутер в порядке, это уже разобрано. Удаленный сервер может видеть локальный на ESP, AH и IKE, используя nmap.

На локальном я так и сделал (внутренний диапазон 100 IP изменился)

modprobe dummy
ip link add name dummy0 type dummy
ip address add 100.64.1.1/32 dev dummy0

и когда я делаю

ifconfig

это проявляется вот так

dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet 100.64.1.1  netmask 255.255.255.255  broadcast 0.0.0.0
        inet6 fe80::xxxx:xxxx:xxxx:xxxx  prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 189  bytes 70950 (69.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Когда мы идем на внешний сервер,

modprobe dummy

это появляется с lsmod:

root@host:~# lsmod  | grep dummy
dummy                  16384  0
root@host:~#

и команда ifconfig не показывает фиктивный виртуальный порт Ethernet после выполнения аналогичного набора последующих команд.

Почему dummy0 не отображается?

Есть идеи, что не так?

[Редактировать - добавлено 13/10/2018 22:18 BST] Я добавил эту диаграмму для ясности. Это то, что я настраиваю:

, Туннель для репликации Cyrus запущен.

Источник

1 ответ

Решение

Причина, по которой изначально был выбран "фиктивный" адаптер eth, была описана здесь:

https://wiki.strongswan.org/issues/722

"Нет необходимости создавать дополнительные интерфейсы (например, TUN) или псевдонимы (например, eth0:1, которые в любом случае являются старой концепцией). Если вы хотите использовать частные IP-адреса внутри туннелей IPsec, просто добавьте их к одному из существующих интерфейсов. (eth0 или lo) с помощью ip addr add ".

Итак, мне нужно привязать конечную точку IP туннеля к адаптеру. Я не хотел связывать его с eth0, потому что он имеет публичный IP-адрес сервера. Кажется "неправильным" связывать это с Ло. Поэтому я изначально решил попробовать создать dummy0.

Из опыта людей с различными дистрибутивами и платформами кажется, что фиктивный интерфейс периодически ненадежен, а также очень трудно надежно запустить его во время загрузки скрипта. Это то, что я тоже нашел.

https://bugzilla.redhat.com/show_bug.cgi?id=1120823

https://askubuntu.com/questions/994669/why-does-ip-link-add-not-work-in-rc-local

https://unix.stackexchange.com/questions/335284/how-can-we-create-multiple-dummy-interfaces-on-linux

https://community.nethserver.org/t/virtual-network-interface-for-virtual-machines/7728/10

Мое рабочее решение создает устройство TUN. Несмотря на то, что через него не проходят никакие пакеты, он работает как надежная точка привязки для IP-адреса в каждой конечной точке. Хотя это все еще не рекомендуемая практика, я обнаружил, что она дает очевидное представление о том, почему адрес привязан к нему, когда вы вводите

ifconfig

TUN легко и надежно вызывать в скриптах загрузки системы.

В диаграмме моего вопроса замените dummy0: для tun0: на рабочее решение.

Используйте что-то вроде этого:

ip tuntap add name tun0 mode tun
ip link set dev tun0 up
ip address add 100.64.2.1/32 dev tun0
route add -net 100.64.1.0/24 gw 100.64.2.1

довести привязку конечной точки IP.

[Изменить 17/09/2018 00:50] Репликация почтового ящика Cyrus теперь работает отлично.

Источник
Другие вопросы по тегам