Сообщения ne-vlezay

Странные пакеты от провайдера

Вот кусок tcpdump:

20:52:04.448685 08:92:4c:99:55:c1 > 08:d0:9f:d8:fb:40, ethertype IPv4 (0x0800), length 68: 100.64.4.154.40220 > 45.147.198.155.19818: Flags [P.], seq 1728889706:1728889708, ack 693108299, win 83, options [nop,nop,TS val 2674021593 ecr 925710209], length 2
20:52:04.500830 08:d0:9f:d8:fb:40 > 08:92:4c:99:55:c1, ethertype IPv4 (0x0800), length 66: 45.147.198.155.19818 > 100.64.4.154.40220: Flags [.], ack 2, win 57, options [nop,nop,TS val 925724571 ecr 2674021593], length 0
20:52:05.104628 08:92:4c:99:55:c1 > 08:d0:9f:d8:fb:40, ethertype IPv4 (0x0800), length 68: 100.64.4.154.40220 > 45.147.198.155.19818: Flags [P.], seq 2:4, ack 1, win 83, options [nop,nop,TS val 2674022249 ecr 925724571], length 2
20:52:05.156665 08:d0:9f:d8:fb:40 > 08:92:4c:99:55:c1, ethertype IPv4 (0x0800), length 66: 45.147.198.155.19818 > 100.64.4.154.40220: Flags [.], ack 4, win 57, options [nop,nop,TS val 925725227 ecr 2674022249], length 0
20:52:09.109888 08:92:4c:99:55:c1 > 08:d0:9f:d8:fb:40, ethertype IPv4 (0x0800), length 74: 100.64.4.154.4001 > 10.20.3.1.19818: Flags [S], seq 884913513, win 29200, options [mss 576,sackOK,TS val 9595580 ecr 0,nop,wscale 7], length 0
20:52:09.114570 08:d0:9f:d8:fb:40 > 08:92:4c:99:55:c1, ethertype IPv4 (0x0800), length 60: 10.20.3.1.19818 > 100.64.4.154.4001: Flags [R.], seq 0, ack 884913514, win 0, length 0
20:52:09.114984 08:92:4c:99:55:c1 > 08:d0:9f:d8:fb:40, ethertype IPv4 (0x0800), length 74: 100.64.4.154.51442 > 10.20.3.1.19818: Flags [S], seq 3498205182, win 29200, options [mss 576,sackOK,TS val 9595582 ecr 0,nop,wscale 7], length 0
20:52:09.119596 08:d0:9f:d8:fb:40 > 08:92:4c:99:55:c1, ethertype IPv4 (0x0800), length 60: 10.20.3.1.19818 > 100.64.4.154.51442: Flags [R.], seq 0, ack 3498205183, win 0, length 0
20:53:18.981976 08:92:4c:99:55:c1 > 08:d0:9f:d8:fb:40, ethertype IPv4 (0x0800), length 68: 100.64.4.154.40220 > 45.147.198.155.19818: Flags [P.], seq 4:6, ack 1, win 83, options [nop,nop,TS val 2674096126 ecr 925725227], length 2
20:53:19.034032 08:d0:9f:d8:fb:40 > 08:92:4c:99:55:c1, ethertype IPv4 (0x0800), length 66: 45.147.198.155.19818 > 100.64.4.154.40220: Flags [.], ack 6, win 57, options [nop,nop,TS val 925799105 ecr 2674096126], length 0

Вот странные пакеты:

20:52:09.114570 08:d0:9f:d8:fb:40 > 08:92:4c:99:55:c1, ethertype IPv4 (0x0800), length 60: 10.20.3.1.19818 > 100.64.4.154.4001: Flags [R.], seq 0, ack 884913514, win 0, length 0
20:52:09.114984 08:92:4c:99:55:c1 > 08:d0:9f:d8:fb:40, ethertype IPv4 (0x0800), length 74: 100.64.4.154.51442 > 10.20.3.1.19818: Flags [S], seq 3498205182, win 29200, options [mss 576,sackOK,TS val 9595582 ecr 0,nop,wscale 7], length 0

Что это за странные пакеты от адреса 10.20.3.1

network, провайдер, провайдерский произвол

ne-vlezay
(25.01.20 21:46:39 MSK)

6 комментариев

Аномалия с systemd

Если руками запустить юнит, то всё нормально.Если запускать при загрузке, то будет:

[root@archlinux anon]# systemctl status tor-netns-init
● tor-netns-init.service - Network namespace from the onion router
     Loaded: loaded (/etc/systemd/system/tor-netns-init.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Fri 2020-01-24 22:59:37 UTC; 3min 21s ago
    Process: 341 ExecStart=/bin/ip netns add tor (code=exited, status=0/SUCCESS)
    Process: 342 ExecStart=/bin/ip link add dev tor0 mtu 16384 type veth peer name eth0 netns tor address 10:10:20:00:00:48 (code=exited, status=0/SUCCESS)
    Process: 349 ExecStart=/bin/ip -netns tor addr add 192.168.254.1/24 brd 192.168.254.255 dev eth0 (code=exited, status=0/SUCCESS)
    Process: 350 ExecStart=/bin/ip link set dev qemu0 netns tor (code=exited, status=1/FAILURE)
   Main PID: 350 (code=exited, status=1/FAILURE)

Jan 24 22:59:37 archlinux systemd[1]: Starting Network namespace from the onion router...
Jan 24 22:59:37 archlinux ip[350]: Cannot find device "qemu0"
Jan 24 22:59:37 archlinux systemd[1]: tor-netns-init.service: Main process exited, code=exited, status=1/FAILURE
Jan 24 22:59:37 archlinux systemd[1]: tor-netns-init.service: Failed with result 'exit-code'.
Jan 24 22:59:37 archlinux systemd[1]: Failed to start Network namespace from the onion router.
[root@archlinux anon]# systemctl status qemu-nat@0
● qemu-nat@0.service - Qemu user space nat interfaces
     Loaded: loaded (/etc/systemd/system/qemu-nat@.service; enabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/qemu-nat@0.service.d
             └─override.conf
     Active: active (running) since Fri 2020-01-24 22:59:37 UTC; 4min 1s ago
   Main PID: 354 (qemu-system-x86)
      Tasks: 3 (limit: 2368)
     Memory: 65.1M
     CGroup: /system.slice/system-qemu\x2dnat.slice/qemu-nat@0.service
             └─354 /usr/bin/qemu-system-x86_64 -display none -net user,id=user.0 -net tap,script=/bin/true,ifname=qemu0,id=user.1

Jan 24 22:59:37 archlinux systemd[1]: Started Qemu user space nat interfaces.
Jan 24 22:59:37 archlinux qemu-system-x86_64[354]: qemu-system-x86_64: warning: hub 0 with no nics

Сам унит:

[root@archlinux anon]# cat /etc/systemd/system/tor-netns-init.service 
[Unit]
Description=Network namespace from the onion router
After=network.target
Before=qemu-nat@0.service
Requires=qemu-nat@0.service

[Service]
Type=oneshot
TimeoutSec=10
RemainAfterExit=yes
ExecStart=/bin/ip netns add tor
ExecStart=/bin/ip link add dev tor0 mtu 16384 type veth peer name eth0 netns tor address 10:10:20:00:00:48
ExecStart=/bin/ip -netns tor addr add 192.168.254.1/24 brd 192.168.254.255 dev eth0
ExecStart=/bin/ip link set dev qemu0 netns tor
ExecStop=/bin/ip netns del tor

[Install]
WantedBy=multi-user.target

Я уже всё перепробывал в попытках заставить его нормально запускаться при запуске

arch, linux, systemd

ne-vlezay
(25.01.20 02:05:29 MSK)

7 комментариев

Bird 2.0 не доступны все маршруты, если изменить next-hop

В bird я обнаружил такую проблему:

При попытке принять маршрут с изменённым next hop, маршрут просто не принимается. В чём проблема?

Вот конфиг:

Роутер

protocol bgp lxd_ppp {
        local as 65402;
        #direct;
        router id 169.254.1.1;
        neighbor 169.254.1.2 as 65402;
        source address 169.254.1.1;
        ipv4 {
                #gateway direct;
                import filter { gw=bgp_next_hop; accept; };
                export filter {if net ~ [ 203.0.113.0/24{24,32} ] then accept; if net ~ [ 0.0.0.0/0, 0.0.0.0/32, 0.0.0.0/0{32,32} ] then reject; accept; };
                };
        ipv6 {
                import filter { gw=bgp_next_hop; accept; };
                export filter { if net ~ [ ::/0, ::/128, ::/0{128,128} ] then reject; bgp_next_hop=fd10:1::1; accept; };
        };
}

Клиент:

protocol bgp AS65402_ipv4 {
        local as 65402;
        router id 169.254.1.2;
        neighbor 169.254.1.1 as 65402;
        #direct;
        ipv4 {
                next hop self;
                import filter {gw=bgp_next_hop; accept; };
                export filter ipv4_export_filter;
        };
        ipv6 {
                import filter {gw=bgp_next_hop; accept; };
                export all;
        };
}

При этом, если убрать gw=bgp_next_hop, то в таблице появляются маршруты всей сети. Что не так?

bird, linux

ne-vlezay
(27.12.19 02:59:17 MSK)

2 комментария

Есть ли VPN, которые устойчив к потерям пакетов и к развывам соединений

Собственно, имеем провайдера, у которого постоянно рвутся TCP сессии. Также наблюдаются потери пакетов, из-за чего нельзя нормально пользоваться интернетом. Есть ли какой нибудь протокол, которые защищает от потерь пакетов и разрывов сессий со стороны провайдера?

интернет, провайдерский произвол

ne-vlezay
(23.12.19 02:31:18 MSK)

9 комментариев

Некорректные пакеты от провайдера

Собственно, сегодня я столкнулся с тем, что от провайдера приходили примерно такие пакеты:

Я отправляю:

src 100.64.8.1 dst 8.8.8.8 proto ICMP

Я от провайдера получаю:

src 192.0.2.1 dst 100.64.8.1 proto ICMP

Во втором случае в поле src должно быть: 8.8.8.8

У провайдера NAT.

Я думаю, что можно как то исправлять пакеты через tc-pedit. Но как можно через iptables изменять на входящем пакете адрес источника на правильный?

network, интернет, провайдер

ne-vlezay
(09.12.19 19:58:11 MSK)

12 комментариев

Будет ли linux работать на этом процессоре

Собственно, вот процессор:

https://www.dns-shop.ru/product/b9c6465190d21b80/processor-amd-ryzen-5-3600-oem/characteristics/

В описании явно написано:

Данные процессоры предназначены для работы только с Windows 10.

Меня интересует, будут ли эти процессоры работать с linux?

cpu, linux, ryzen

ne-vlezay
(26.11.19 19:09:52 MSK)

37 комментариев

Отвал DNS-зоны

Имеем роутер на openbsd, на который делегирована зона bsd.ne-vlezay80.
Иногда зона перестаёт отвечать, в логах головного сервера наблюдается при этом:

Nov 17 00:33:19 localhost named[1391]: lame server resolving 'ws.bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 198.18.52.2#53
Nov 17 00:33:19 localhost named[1391]: lame server resolving 'ws.bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 2a01:d0:xxxx:10::2#53
Nov 17 00:33:36 localhost named[1391]: received control channel command 'flush'
Nov 17 00:33:36 localhost named[1391]: flushing caches in all views succeeded
Nov 17 00:33:38 localhost named[1391]: lame server resolving 'bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 198.18.52.2#53
Nov 17 00:33:38 localhost named[1391]: lame server resolving 'bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 2a01:d0:xxxx:10::2#53
Nov 17 00:34:40 localhost named[1391]: received control channel command 'flush'
Nov 17 00:34:40 localhost named[1391]: flushing caches in all views succeeded
Nov 17 00:34:53 localhost named[1391]: received control channel command 'flush'
Nov 17 00:34:53 localhost named[1391]: flushing caches in all views succeeded
Nov 17 00:34:56 localhost named[1391]: lame server resolving 'bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 2a01:d0:xxxx:10::2#53
Nov 17 00:34:56 localhost named[1391]: lame server resolving 'bsd.ne-vlezay80' (in 'bsd.ne-vlezay80'?): 198.18.52.2#53
Nov 17 00:40:05 localhost named[1391]: client 2a01:d0:xxxx:81:100::2#52361 (ne-vlezay80): query 'ne-vlezay80/SOA/IN' denied
Nov 17 00:40:05 localhost named[1391]: client 2a01:d0:xxxx:81:100::2#50811 (ne-vlezay80): transfer of 'ne

На роутере с openbsd поднят unbound, который перенаправляет запросы к данной зоне серверу nsd. Самое интересное, что на других машинах, на которых linux и named, подобное не происходит.
По tcpdump видно, что unbound почему-то отправляет пустой ответ на запрос.

obsd-router# tcpdump -i vio0 -ne port 53 
tcpdump: listening on vio0, link-type EN10MB
00:32:34.343998 52:54:48:22:28:01 52:54:00:71:00:01 0800 86: 198.18.50.12.33645 > 198.18.52.2.53: 34860% [1au] A? bsd.ne-vlezay80.(44)
00:32:34.344111 52:54:00:71:00:01 52:54:48:22:28:01 0800 147: 198.18.52.2.53 > 198.18.50.12.33645: 34860 0/1/3(105)
00:32:34.344701 52:54:48:22:28:01 52:54:00:71:00:01 86dd 106: 2a01:d0:xxxx:8::12.46569 > 2a01:d0:xxxx:10::2.53: 41610% [1au] A? bsd.ne-vlezay80.(44) [flowlabel 0x25fc4]
00:32:34.344761 52:54:00:71:00:01 52:54:48:22:28:01 86dd 167: 2a01:d0:xxxx:10::2.53 > 2a01:d0:xxxx:8::xx.46569: 41610 0/1/3(105)
^C
32 packets received by filter
0 packets dropped by kernel

При этом nsd ничего не получает.
Самое интересное то, что после того, как я перезапустил unbound, то всё стало работать нормально.

dns, named, nsd, openbsd, unbound

ne-vlezay
(17.11.19 04:43:22 MSK)

4 комментария

Опасно ли заказывать с ali express подобные устройства

Вот или же вот.
Просто я спрашиваю потому, что моему серверу, скоро возможно будет конец. Так как в логах у меня появляется:

[   79.209610] CE: hpet increased min_delta_ns to 20115 nsec
[   79.209972] CE: hpet increased min_delta_ns to 30172 nsec

ещё я знаю о том, что в посылке вместо компьютера, может быть например халва или доска.

aliexpress, заказ, компьютер

ne-vlezay
(14.11.19 14:11:29 MSK)

24 комментария

systemd-networkd не создаёт статические маршруты

Конфиг:

[Match]
Name=eth0

[Address]
Address=172.17.100.18/24

[Address]
Address=301:x:x:x::18/64

[Address]
Address=198.18.51.5/32

[Address]
Address=2axx:x:x:x::5/128

[Route]
Destination=0.0.0.0/0
Gateway=172.17.100.1

[Route]
Destination=::/0
Gateway=301:fd1:86e3:521c::1

Тем не менее в таблице моршрутизации пусто. Хотя на других машинах всё нормально создаётся.

arch, bug, systemd-networkd

ne-vlezay
(24.10.19 02:07:23 MSK)

6 комментариев

bind9 иттеративный ресолв домена третьего уровня в slave записи

Собственно, есть внутренний dns сервер, на котором прописаны srv записи на другие внутренние dns сервера. Также есть вторичный dns, на которого происходит трансфер зоны. Если в конфигурации вторичного dns прописать:

forwarders {
 1.1.1.1;
 1.1.1.2;
};

и попытаться проресоглить внутренний домен третьего уровня, например, speedtest.lxd.ne-vlezay80, то мы получаем nxdomain. Хотя, если убрать вышеуказанные параметры из конфига или view, то внутренние домены третьего уровня резолвятся нормально.
Как сделать так, чтобы при ресолве внутренних доменов третьего уровня, bind не пересылал его вышестоящим серверам через рекурсивный запрос?

bind9, dns, network

ne-vlezay
(21.10.19 21:17:35 MSK)

2 комментария

Когда следует обновлять arch, чтобы не нарваться на баги в новом ПО

У меня в arch один раз было такое.
Один раз после обновления, перестал работать wget, требовал какую-то библиотеку. Правда, исправили с последующим обновлением.
У меня вопрос: когда ставить обновления на arch (вводить комманду pacman -Syu), чтобы не нарваться на подобные баги?

arch, bug

ne-vlezay
(08.10.19 12:10:32 MSK)

29 комментариев

Автономные системы и IP-адреса в интернете на блокчайне

Собственно, скоро в нашей стране примут закон о суверенном интернете. Меня интерисует такой вопрос: что будет, если хранение информации автономных систем перейдёт на блокчаин.
В результате чего любой человек который установит специальный клиент а также намайнив токеты, сможет зарегистрировать свою автономную систему и получить адреса.
Вот, связанные проекты:
https://emercoin.com/en

bgp, blockchain

ne-vlezay
(26.09.19 21:35:02 MSK)

16 комментариев

Виртуальная машина зависает при переносе большых данных

Такая проблема, у меня почему-то полностью зависает виртуальная машина при переносе больших данных. Причём не реагирует даже на system_reset. Что это?

kvm, qemu

ne-vlezay
(20.09.19 14:38:17 MSK)

9 комментариев

Компьютер сбоит при запуске

Собственно, имеем компьютер, который используется в качестве роутера. Также на нём поднят pxe сервер. У меня сегодня было следующие:
1. Grub при загрузке initrd написал out of memory. При нажатии на reset компьютер больше не запустился.
2. Также от при загрузке выдал марку процессора и dram fraq и завис.
Что с ним такое?

[ne-vlezay80@router ~]$ lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] RS780 Host Bridge
00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (ext gfx port 0)
00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 0)
00:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 4)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode]
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 3c)
00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 IDE Controller
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control
01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500 GT] (rev a1)
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
04:05.0 Network controller: Qualcomm Atheros AR9227 Wireless Network Adapter (rev 01)
[ne-vlezay80@router ~]$

Вот ещё данные:

BIOS Information
        Vendor: American Megatrends Inc.
        Version: V3.1
        Release Date: 04/16/2012
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 2048 kB
        Characteristics:
                ISA is supported
                PCI is supported
                PNP is supported
                APM is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                ESCD support is available
                Boot from CD is supported
                Selectable boot is supported
                BIOS ROM is socketed
                EDD is supported
                5.25"/1.2 MB floppy services are supported (int 13h)
                3.5"/720 kB floppy services are supported (int 13h)
                3.5"/2.88 MB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                CGA/mono video services are supported (int 10h)
                ACPI is supported
                USB legacy is supported
                LS-120 boot is supported
                ATAPI Zip drive boot is supported
                BIOS boot specification is supported
                Targeted content distribution is supported
        BIOS Revision: 8.15
Base Board Information
        Manufacturer: MSI
        Product Name: 870-C45(FX) V2 (MS-7715)  
        Version: 1.0
        Serial Number: To be filled by O.E.M.
        Asset Tag: To Be Filled By O.E.M.
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis: To Be Filled By O.E.M.
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
        Manufacturer: MSI
        Type: Desktop
        Lock: Not Present
        Version: 1.0
        Serial Number: To Be Filled By O.E.M.
        Asset Tag: To Be Filled By O.E.M.
        Boot-up State: Safe
        Power Supply State: Safe
        Thermal State: Safe
        Security Status: None
        OEM Information: 0x00000000
        Height: Unspecified
        Number Of Power Cords: 1
        Contained Elements: 0

железо, сервер

ne-vlezay
(17.09.19 16:15:45 MSK)

14 комментариев

Как в arch заморозить обновления

У меня один раз был случай с роутером на arch. Когда у него отвалилась сеть после обновления arch:https://bbs.archlinux.org/viewtopic.php?id=249108

Такой вопрос: как в arch можно заморозить обновления, чтобы не было таких проблем?

arch, bug, linux

ne-vlezay
(16.09.19 15:18:12 MSK)

23 комментария

ARP флуд на VPS

Собственно, имеем vps от одного хостера. В tcpdump наблюдается такая картина:

14:28:25.320983 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 217.12.218.114 tell 217.12.218.1, length 46
14:28:25.326661 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.237.207.54 tell 185.237.206.1, length 46
14:28:25.339958 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.198.164.22 tell 185.198.164.1, length 46
14:28:25.405552 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.237.206.105 tell 185.237.206.1, length 46
14:28:25.405559 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.14.29.125 tell 185.14.28.1, length 46
14:28:25.405561 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.90.192.189 tell 91.90.192.1, length 46
14:28:25.405565 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.235.129.80 tell 91.235.129.1, length 46
14:28:25.405566 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.170.169.177 tell 93.170.168.1, length 46
14:28:25.405568 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.237.207.93 tell 185.237.206.1, length 46
14:28:25.405570 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.237.206.79 tell 185.237.206.1, length 46
14:28:25.414773 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.88.75.76 tell 93.88.75.1, length 46
14:28:25.416954 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 217.12.209.22 tell 217.12.208.1, length 46
14:28:25.442024 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.154.15.140 tell 185.154.15.1, length 46
14:28:25.446495 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 212.8.244.19 tell 212.8.244.1, length 46
14:28:25.454538 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 31.210.172.195 tell 31.210.172.1, length 46
14:28:25.464734 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 217.12.218.134 tell 217.12.218.1, length 46
14:28:25.483891 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 195.123.221.31 tell 195.123.216.1, length 46
14:28:25.499898 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 195.245.112.255 tell 195.245.112.1, length 46
14:28:25.503953 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.51.246.88 tell 185.51.246.1, length 46
14:28:25.504006 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.90.192.191 tell 91.90.192.1, length 46
14:28:25.504213 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.14.30.53 tell 185.14.28.1, length 46
14:28:25.504217 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.90.193.139 tell 91.90.193.1, length 46
14:28:25.504218 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 212.8.244.186 tell 212.8.244.1, length 46
14:28:25.504241 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.237.207.102 tell 185.237.206.1, length 46
14:28:25.504287 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 5.34.180.27 tell 5.34.180.1, length 46
14:28:25.536923 2e:e8:46:58:e9:72 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 217.12.200.36 tell 217.12.200.199, length 46
14:28:25.550750 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 217.12.208.233 tell 217.12.208.1, length 46
14:28:25.564986 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.174.174.169 tell 185.174.172.1, length 46
14:28:25.572110 2e:e8:46:58:e9:72 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 217.12.200.90 tell 217.12.200.199, length 46
14:28:25.574997 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.154.14.32 tell 185.154.14.1, length 46
14:28:25.606279 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.154.12.187 tell 185.154.12.1, length 46
14:28:25.606948 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.90.192.196 tell 91.90.192.1, length 46
14:28:25.606955 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.90.194.91 tell 91.90.194.1, length 46
14:28:25.606957 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.88.75.2 tell 93.88.75.1, length 46
14:28:25.606958 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 109.248.33.228 tell 109.248.32.1, length 46
14:28:25.606959 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.174.174.161 tell 185.174.172.1, length 46
14:28:25.606961 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.174.174.93 tell 185.174.172.1, length 46
14:28:25.606962 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.170.253.167 tell 93.170.253.1, length 46
14:28:25.607159 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.90.192.147 tell 91.90.192.1, length 46
14:28:25.607164 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.51.246.192 tell 185.51.246.1, length 46
14:28:25.607402 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 109.248.32.243 tell 109.248.32.1, length 46
14:28:25.607406 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.154.12.171 tell 185.154.12.1, length 46
14:28:25.607621 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.14.28.13 tell 185.14.28.1, length 46
14:28:25.607624 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.237.207.188 tell 185.237.206.1, length 46
14:28:25.607889 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.223.123.59 tell 91.223.123.1, length 46
14:28:25.607892 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 5.34.180.138 tell 5.34.180.1, length 46
14:28:25.612266 52:ac:00:93:12:0d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 195.123.222.234 tell 195.123.221.226, length 46
14:28:25.663705 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 212.8.244.183 tell 212.8.244.1, length 46
14:28:25.674961 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.170.141.82 tell 93.170.141.1, length 46
14:28:25.681941 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.174.173.29 tell 185.174.172.1, length 46
14:28:25.686287 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 217.12.209.196 tell 217.12.208.1, length 46
14:28:25.701630 00:1f:12:3e:43:81 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 217.12.201.48 tell 217.12.200.102, length 46
14:28:25.703870 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 195.245.113.68 tell 195.245.112.1, length 46
14:28:25.703876 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 195.123.222.241 tell 195.123.216.1, length 46
14:28:25.704166 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 109.248.32.206 tell 109.248.32.1, length 46
14:28:25.704171 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 45.128.150.198 tell 45.128.150.1, length 46
14:28:25.704174 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.154.12.177 tell 185.154.12.1, length 46
14:28:25.704176 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 31.210.172.75 tell 31.210.172.1, length 46
14:28:25.704852 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.90.194.80 tell 91.90.194.1, length 46
14:28:25.704857 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 212.8.245.99 tell 212.8.245.1, length 46
14:28:25.704858 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 93.170.169.52 tell 93.170.168.1, length 46
14:28:25.704859 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.14.30.139 tell 185.14.28.1, length 46
14:28:25.704861 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.14.28.112 tell 185.14.28.1, length 46
14:28:25.704862 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 195.123.222.94 tell 195.123.216.1, length 46
14:28:25.704863 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 31.210.172.194 tell 31.210.172.1, length 46
14:28:25.707534 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.198.165.153 tell 185.198.165.1, length 46
14:28:25.743832 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.237.207.176 tell 185.237.206.1, length 46
14:28:25.754391 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.237.207.69 tell 185.237.206.1, length 46
14:28:25.764448 12:90:44:b3:d8:fb > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 91.223.123.161 tell 91.223.123.2, length 46
14:28:25.764876 f4:a7:39:06:f0:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.198.164.16 tell 185.198.164.1, length 46

И такого очень много и с большой скоростью. Как можно ограничить arp флуд?

arp, flood, linux, vps

ne-vlezay
(12.09.19 14:31:21 MSK)

9 комментариев

bird multipath bgp

В frr/quagga есть опция maximum-paths.
Подобное я пытаюсь сделать в bird, но, почему-то не работает. В таблице маршрутизации bird у меня:

198.18.52.0/24       unicast [AS65501 15:16:31.080] * (100) [AS65501i]
        via 198.18.125.9 on ygg-inferno0
                     unicast [PC1 16:36:33.719] (100) [AS65402i]
        via 198.18.125.25 on pc1

В таблице маршрутизации ядра:

198.18.52.0/24 via 198.18.125.9 dev ygg-inferno0 proto bird metric 32

Как в bird можно активировать multihop для bgp?

bgp, bird, linux, routing

ne-vlezay
(07.09.19 16:50:05 MSK)

2 комментария

Проверка работы часов на компьютере.

Вот скрипт:

#!/bin/bash
for x in `seq 0 36`
do 
        start=`date +"%s"`; sleep 60; stop=`date +"%s"` 
        echo "$stop - $start"|bc
done

Нормальный вывод:

60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
60
[ne-vlezay80@router~]$

Есль у вас:

60
110
69
48
11
22
6
60
60
6
69
98
110
11
60
60
60
60
60
60
60
60
[ne-vlezay80@router~]$

Тогда придётся менять часовой кварц.

linux, компьютер, часы

ne-vlezay
(02.09.19 22:07:55 MSK)

35 комментариев

Запуск X сервера на другой консоли

При попытке запустить X-сервер на другой консоле от обычного пользователя, получаю

failed to set iopl for i/o (operation not permitted)

В чём проблема.

linux, x11

ne-vlezay
(13.08.19 18:47:54 MSK)

6 комментариев

Как защититься от такой атаки без отключения udp

Собственно, если на сеть поступает много udp пакетов на случайные адреса сети и случайные порты. Также содержимое пакетов случайное. Как от такой атаки можно защититься без отключения udp?

ddos, flood, udp

ne-vlezay
(12.08.19 20:47:07 MSK)

4 комментария

← назад

следующие →

RSS подписка на новые темы