Вопросы Теги

Mikrotik RouterOS - Как запретить всем устройствам в VLAN инициировать какие-либо подключения за пределами VLAN? [дубликат]

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

Имеет смысл 

[mrduki@mybox1~]$ nc -ul 40000
---
[mrduki@mybox2~]$ nc -zvuw2 mybox1.com 40000
Connection to mybox1.com 40000 port [udp/*] succeeded!

Не имеет смысла 

[mrduki@mybox1~]$ nc -ul 40000
[mrduki@mybox1~]$ ^C
---
[mrduki@mybox2~]$ nc -zvuw2 mybox1.com 40000
Connection to mybox1.com 40000 port [udp/*] succeeded!

Фактически, если я провожу сканирование портов из 40000-40100 , каждый порт будет успешным.

Если я провожу те же тесты без -u (чтобы он проверял TCP вместо UDP), я получаю 40000 (tcp) timed out: Operation now in progress error, как я и ожидал (поскольку у меня нет такой службы TCP, которая прослушивает 40000 ).

Выполнение sudo netstat -alnp | grep LISTEN на mybox1 , хотя не показывает, что такие службы прослушивают эти порты. Так что мне не хватает?

1
задан 19 August 2016 в 00:22
3 ответа

nc может быть не самым лучшим инструментом для тестирования состояния порта. Вы пробовали nmap? На самом деле это сканер портов. Я проверил файловый сервер в моей домашней сети и 127.0.0.1, оба сообщили, что UDP порт 40000 закрыт.

nmap

# nmap -sU -p 40000 igor

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-18 18:27 EDT
Nmap scan report for igor (192.168.1.125)
Host is up (0.00027s latency).
rDNS record for 192.168.1.125: igor.swass
PORT      STATE  SERVICE
40000/udp closed unknown
MAC Address: 68:05:CA:3A:BF:B7 (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds

Kernel + /dev

Для этого также можно использовать ядро. Но nmap наверное лучше.

# timeout 3 cat < /dev/udp/example.com/40000

Когда я пытался nc на том же сервере (igor) я получал те же результаты, что и Вы. Но я вернулся, чтобы попробовать еще раз, и теперь он не возвращает ни одного вывода (ни одного успешного сообщения), а wireshark показывает "Destination unreachable", отправляемого обратно по ICMP. Я ничего из этого не понимаю. Но я бы переключился на другой метод проверки состояния UDP-порта.

2
ответ дан 4 January 2021 в 09:54

UDP - протокол "без соединения". Если вы посылаете пакет и не получаете отказ (по ICMP), то он считается успешным. Это не зависит от того, ответит ли кто-нибудь. Невозможность получения на удаленном конце может рассматриваться как проблема с высоким уровнем сцепления, например, DNS, но это не сбой в том, что касается UDP.

Контрастируйте это с TCP, который имеет статус. Сбой при получении ответа (ACK) считается сбоем внутри TCP (обычно он отображается как "отфильтрованный"), так же как и отрицательные ответы (RST, который отображается как закрытый).

UDP: open|filtered закрыт. TCP: открыть закрытый фильтр

5
ответ дан 4 January 2021 в 09:54

Ни один блок брандмауэра не остановит успешную попытку UDP-соединения, поскольку соединение с UDP не подразумевает отправку чего-либо или прослушивание ответов. Функционально UDP-соединение - это то же самое, что и отправка до момента фактической отправки данных, то есть:

  1. обеспечивает привязку выбранного локального порта, если он был выбран.
  2. Если локальный порт не был выбран, он выбирает его.
  3. блокирует конечную точку так, чтобы она, по умолчанию, взаимодействовала с выбранным IP и портом и отбрасывала любые дейтаграммы, полученные с любого другого IP-адреса или порта.
  4. Система может изменить способ обработки некоторых типов ошибок.
  5. Вот и все.

Заметьте, что ничто из этого не мешает работе брандмауэра и не посылается по проводам.

1
ответ дан 4 January 2021 в 09:54

Теги

Похожие вопросы