файл отрицательного размера

Как ни странно, SmokePing – это программа для отслеживания состояния компьютерных сетей и рисования соответствующих графиков, чтоб было удобнее посмотреть эти состояния за прошлое время.

Если кому интересно, исходники можно скачать с GitHub‘а.

Оригинал этой записи в личном блоге.

Но оказалось, что это

Оригинал этой записи в личном блоге.

Позавчера попробовал поставить у себя на десктопе в virtualbox’е виртуальную машинку с pfsense’ом, чтобы проверить, где он глючит. Но скопировать оригинальный диск с VMware’ного сервера не удалось — типа, ошибка случилась. Непонятно какая.. Короче, пришлось установить заново с нуля, и скопировать туда конфиг с той рабочей машинки.

Pfsense’овые WAN и LAN прикрутил к виртуальным host-only сеткам, чтоб можно было туда зайти с десктопа. Зашёл и по ssh, и через веб, стал менять настройки VPNов.
Дефектов в config.xml не случилось, но некоторые изменения почему-то внезапно вызывали перезагрузку машины.. Хотя после перезагрузок она нормально читала свой конфиг и успешно запускалась.

А вчера начальник предложил проапгрейдить этот тестовый pfsense до свежей версии, чтобы проверить, будет ли и там глючить. Но для этого виртуальную машинку нужно было прицепить к интернетам, чтоб она скачала себе новую прошивку. Казалось бы, это элементарно, но.. как всегда, встретились грабли.

Первым делом попробовал на десктопе прикрутить NAT через eth0 к тому host-only интерфейсу vboxnet0, на котором у десктопа как раз и был адрес gateway, использовавшийся pfsense’ом. Но почему-то не сработало. Похоже, эти vboxnet’ы управляются только virtualbox’ом, а нормальные сетевые утилиты на них не работают.

Потом попробовал соединить в бридж pfsense’овый WAN с десктопным eth0. Это, естественно, тоже не сработало, потому что у pfsense’а там был статический публичный адрес из своей сети, и она использовала в качестве gateway адрес из той же сети, которого в местной сетке вовсе не было.

Ну, отключил там на WAN статический адрес, включил DHCP, pfsense получил адрес из местной сетки и правильный gateway, но.. почему-то всё равно никуда соединиться не мог. Запустил tcpdump, и оказалось, что несмотря на полученный по DHCP адрес, pfsense почему-то отправлял пакеты наружу со своего публичного CARP-адреса, который тоже был из той же публичной сети, потому он в местной сетке не работал: пакеты наружу не проходили, но даже если б прошли, ответы бы всё равно не вернулись.

Попробовал выключить в pfsense этот CARP-адрес, а не дают — типа, он используется в настройках многих VPN’ов, поэтому нельзя его удалить..

Выходит, надо использовать тот статический адрес и NAT’ить его самим virtualbox’ом. Вернул адрес, прицепил WAN к virtulabox’овому NAT, — тоже не работает. Кажись, virtualbox там свои адреса использует, из 192.168..

Тогда создал в virtualbox’е отдельную NAT Network, явно приписав туда сетку, которую использовал pfsense, и на стороне сервера приделал туда адрес gateway. А фиг, всё равно наружу не ходит, и даже этот gateway не пингается, хотя он там точно должен быть.

Долго думал, как бы всё же организовать связь с интернетами. Разве что поставить туда ещё одну виртуальную машинку в качестве gateway, и на ней организовать NAT.. Но приделывать к маршрутизатору дополнительный маршрутизатор — это ж бред..

В конце концов грабли удалось обойти следующим образом:

Оригинал этой записи в личном блоге.

Условие: у вас есть локальная сеть с кучкой компьютеров, использующих приватные адреса. В сети также есть маршрутизатор с публичным адресом, в который он NAT’ит приватные адреса при выходе в интернеты. На маршрутизаторе через публичный интернет также включены VPNы, через которые к вашей сети подключено несколько других сетей, также использующих у себя внутри приватные адреса. Соединения от всех (ну или, может, только некоторых) компьютеров вашей сети должны обеспечиваться к компьютерам во всех удалённых сетях, и обратно – из всех тех сетей в вашу.

Оригинал этой записи в личном блоге.

Один юзер из Англии жаловался, что его ноутбук периодически ругается, что выданный ему (по DHCP) адрес уже кем-то используется, и wifi отваливается. Ethernet’а у него в ноутбуке нет, поэтому местные айтишники выдали ему usb’шный ethernet-адаптер и подключили кабелем вместо wifi. А ноутбук продолжает жаловаться на то же самое. Тогда в DHCP-сервере на MAC-адрес этого адаптера зарегистрировали псевдостатический IP (10.20.30.120), но и это не помогло.

Когда он в очередной раз пожаловался, я зашёл на тамошний маршрутизатор (.1) и попробовал попингать этот .120 . Картина получилась офигенная:

# ping 10.20.30.120
PING 10.20.30.120 (10.20.30.120): 56 data bytes
36 bytes from 10.20.30.8: Redirect Host(New addr: 10.20.30.120)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 8b9e   0 0000  40  01 d88d 10.20.30.1  10.20.30.120 

Попингал ещё раз, запустив tcpdump, и в натуре увидел ICMP redirect от какого-то хоста .8 :

13:36:51.823988 IP (tos 0x0, ttl 64, id 35742, offset 0, flags [none], proto ICMP (1), length 84)
    10.20.30.1 > 10.20.30.120: ICMP echo request, id 34137, seq 0, length 64
13:36:51.824530 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.20.30.120 tell 10.20.30.8, length 46
13:36:51.824535 IP (tos 0x0, ttl 255, id 47957, offset 0, flags [none], proto ICMP (1), length 56)
    10.20.30.8 > 10.20.30.1: ICMP redirect 10.20.30.120 to host 10.20.30.120, length 36
	IP (tos 0x0, ttl 64, id 35742, offset 0, flags [none], proto ICMP (1), length 84)

Посмотрел в arp-таблицу, оказалось, что на оба адреса — .8 и .120 — отзывался один и тот же MAC: e8:8d:28:*.*.* . Apple’овский.. Спросил у тамошних айтишников, что это за машинка, и оказалось, что это у них там wifi’ная точка доступа — Apple AirPort Extreme, со статическим адресом .8 .

Так какого фига она перехватывает чужой IP .120, сначала отвечая своим MAC’ом на ARP-запросы к .120, а потом, получая IP-пакеты на этот адрес, делает вид, что это не она, отправляя ARP-запрос на .120, но не получив ответа, посылает запрашивающего нафиг (ICMP-redirect’ом на сам .120)?

Upd: в результате гугления оказалось, что это “нормальное” поведение Bonjour Sleep Proxy, встроенного в AirPort Extreme: https://discussions.apple.com/thread/2160614. Не, нах эти уродские эппловские продукты.

Оригинал этой записи в личном блоге.

Через /etc/network/interfaces, а не совсем вручную.
1) tun/tap:
iface tap10 inet manual
pre-up ip tuntap add tap10 mode tap user root
up ip link set dev tap10 up
post-down ip link del dev tap10

2) trunk, разделящий пакеты от разных VLANов по псевдоинтерфейсам, как оказалось, конфигурируется исключительно просто:
iface eth1.1 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1

iface eth1.5 inet static
address 192.168.20.30
netmask 255.255.255.0
Число после точки в имени интерфейса – это номер VLAN’а. Только чтобы оно заработало, в системе должен быть установлена программа vconfig (из пакета vlan).

3) Несколько IPшников, возможно, из разных подсетей, на одном интерфейсе. Типичный случай, когда в одном физическом сегменте используется несколько подсетей, или когда одна машина должна отзываться на несколько адресов:
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
gateway 192.168.0.1

iface eth0:0 inet static
address 192.168.100.150
netmask 255.255.255.0

iface eth0:1 inet static
address 192.168.200.10
netmask 255.255.255.0

На одном из этих eth0* можно вместо статического адреса использовать DHCP:
iface eth0 inet dhcp

4) А вот если хочется на одном физическом интерфейсе получить несколько разных адресов по DHCP, то придётся поизвращаться. Поскольку DHCP-сервер привязывает выдаваемые IP к MAC-адресам, а MAC-то у физического интерфейса только один, то больше одного IP ему не дадут. Так что придётся добавить к физическому интерфейсу (скажем, eth0) фейковый интерфейс с другим MAC-адресом:
iface eth0 inet dhcp

iface ethFake inet dhcp
pre-up ip link add link eth0 name ethFake address 00:01:02:03:04:05 type macvlan
up ip link set dev ethFake up
post-down ip link del dev ethFake
MAC указывать не обязательно. Если его нет, то ip link add сгенерирует случайный адрес.

А теперь хитрый вопрос для продвинутых сисадминов: поскольку обычно DHCP-сервер выдаёт клиенту адрес гейта, а DHCP-клиент приделывает его в качестве дефолтового маршрута (причём с указанием клиентского IP в качестве src), то при начальном конфигурировании этих двух интерфейсов и при последующих обновлениях дефолтовый маршрут будет перебрасываться с eth0 на ethFake и обратно, и тем ломать маршрутизацию и ронять установленные на тот момент соединения с другого клиентского IP. Как этого избежать?
(Если чё, я знаю ответ :)

Оригинал этой записи в личном блоге.

По случаю запустил в домашней сети броадкастный пинг. С удивлением обнаружил, что один хост на него отозвался. Угадайте, какой?
Правильно, ойфон. Остальные имеющиеся в сети винды, линуксы и андроиды не отозвались. Потому что их разработчики эту опасную штуку давно поотключали. И только быдлокодеры из Apple до сих пор не знают про атаку типа smurf, известную с 90-х годов прошлого века. Не удивлюсь, если оно и в MacOS не отключено.

Оригинал этой записи в личном блоге.

Получите:

Нет, это не фотошоп, это в магазине такое реально продаётся.

Оригинал этой записи в личном блоге.

из разбираемой серверной.

Много-много гигабайт, все они поедут на свалку:

Оригинал этой записи в личном блоге.

В частности, по Scientific Atlanta, которых купила Cisco. Или по DOCSIS вообще.

Если вдруг есть, отзовитесь.  Вопрос есть.

Оригинал этой записи. Комментировать можно тут или там.