У меня есть сервер, настроенный с несколькими интерфейсами и несколькими VLAN. Он отлично работает во всех локальных сетях, но по какой-то причине отбрасывает пакеты, пересылаемые через мой маршрутизатор. И это даже непоследовательно. Иногда я могу заставить его работать в течение пары дней, прежде чем он снова начнет отбрасывать пакеты. Я хотел бы продолжить копать, но единственные, но единственные результаты, которые я могу получить от Google, - это люди, которым нужна помощь в настройке iptables.
$ cat /etc/issue
Ubuntu 18.04.4 LTS \n \l
$ cat /etc/netplan/50-cloud-init.yaml
network:
version: 2
ethernets:
enp10s0:
dhcp4: true
dhcp6: true
enp6s0:
dhcp4: false
dhcp6: false
vlans:
vlan18:
id: 18
link: enp6s0
dhcp4: true
optional: true
vlan150:
id: 150
link: enp6s0
dhcp4: true
optional: true
vlan155:
id: 155
link: enp6s0
dhcp4: true
optional: true
Рассматриваемый интерфейс enp10s0. У меня было это на enp6s0 в VLAN на некоторое время, но переместил его на отдельный сетевой адаптер для изоляции переменных. Это ничего не изменило.
$ netstat -s enp10s0
Ip:
Forwarding: 2
4207683 total packets received
11 with invalid addresses
0 forwarded
0 incoming packets discarded
4197424 incoming packets delivered
2183348 requests sent out
21 outgoing packets dropped
Tcp:
1634 active connection openings
1615 passive connection openings
150 failed connection attempts
1100 connection resets received
43 connections established
4207863 segments received
2190261 segments sent out
596 segments retransmitted
0 bad segments received
222 resets sent
Я добавляю следующую первую строку в свою цепочку INPUT iptables:
-p tcp -m tcp --dport 22 -j LOG --log-prefix "IPTABLES SEEN: "
Смотрю трафик с помощью tcpdump:
tcpdump -n -e -vv -i enp10s0 port 22
С моего роутера 10.8.10.1 telnet к рассматриваемому серверу 10.8.10.11 port 22.
журнал iptables:
Jul 15 23:58:04 meji kernel: IPTABLES SEEN: IN=enp10s0 OUT= MAC=60:a4:4c:60:ce:ce:e0:63:da:21:c1:a5:08:00 SRC=10.8.10.1 DST=10.8.10.11 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=44677 DF PROTO=TCP SPT=48770 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0
журнал tcpdump:
23:58:04.335447 e0:63:da:21:c1:a5 > 60:a4:4c:60:ce:ce, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 44677, offset 0, flags [DF], proto TCP (6), length 60)
10.8.10.1.48770 > 10.8.10.11.22: Flags [S], cksum 0xbb2d (correct), seq 978415077, win 14600, options [mss 1460,sackOK,TS val 25150304 ecr 0,nop,wscale 7], length 0
SYN ACK следует, как и следовало ожидать, и все в порядке.
я использую nc -vz с моего удаленного сервера (34.73.148.195) для подключения к тому же ip / порту.
журнал tcpdump:
00:54:44.427670 e0:63:da:21:c1:a5 > 60:a4:4c:60:ce:ce, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 56, id 18829, offset 0, flags [DF], proto TCP (6), length 60)
34.73.148.195.50176 > 10.8.10.11.22: Flags [S], cksum 0x8c20 (correct), seq 1566819019, win 65320, options [mss 1420,sackOK,TS val 1249821436 ecr 0,nop,wscale 6], length 0
журнал iptables:
ничего. ничего не регистрируется.
Нет SYN ACK, и через мгновение выполняется попытка повторной передачи. Сетевая карта не сообщает об ошибках, iptables ничего не видит, и я остаюсь чесать голову. Куда мне вообще смотреть отсюда? Начать копаться в ядре? Сетевые драйверы?
$ ip route show
default via 10.8.8.1 dev vlan18 proto dhcp src 10.8.8.11 metric 100
default via 10.8.50.1 dev vlan150 proto dhcp src 10.8.50.5 metric 100
10.8.8.0/24 dev vlan18 proto kernel scope link src 10.8.8.11
10.8.8.1 dev vlan18 proto dhcp scope link src 10.8.8.11 metric 100
10.8.10.0/24 dev enp10s0 proto kernel scope link src 10.8.10.11
10.8.50.0/24 dev vlan150 proto kernel scope link src 10.8.50.5
10.8.50.1 dev vlan150 proto dhcp scope link src 10.8.50.5 metric 100
10.8.55.0/24 dev vlan155 proto kernel scope link src 10.8.55.5
Еще кое-что об iptables. Но когда я убираю все правила и меняю все политики на ACCEPT, у меня все еще остается та же проблема. Я уверен, что исключил правила iptables как виновника.
# iptables -vL
Chain INPUT (policy DROP 442K packets, 81M bytes)
pkts bytes target prot opt in out source destination
348M 494G ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
1692K 301M ACCEPT all -- lo any anywhere anywhere /* Loopback Interface */
327K 24M ACCEPT all -- vlan18 any anywhere anywhere
174K 14M ACCEPT all -- vlan155 any anywhere anywhere
0 0 ACCEPT tcp -- enp10s0 any anywhere anywhere tcp dpt:ssh state NEW,ESTABLISHED /* Ssh Passthrough */
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 190M packets, 17G bytes)
pkts bytes target prot opt in out source destination
# iptables --list --table raw
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# iptables --list --table mangle
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
# iptables --list --table nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source
Прежде чем пакет попадет в цепочку INPUT таблицы FILTER, он должен пройти через следующие таблицы / цепочки:
по умолчанию, т.е. если вы опускаете аргумент --table, то вы смотрите на таблицу FILTER. Кроме того, прежде чем он попадет в filter-INPUT, решение о маршрутизации принимается между nat-PREROUTING и mangle-INPUT (т.е. если решение о маршрутизации заключает, что пакет не для вашего локального хоста, то он никогда не достигнет цепочки filter-INPUT, но лучше перейти к цепочке mangle-FORWARD / filter-FORWARD). Вы можете попробовать следующее:
1.) добавьте записи в журнал, как и выше, для вышеупомянутых таблиц и цепочек. Вы видите записи? Где они останавливаются?
2.) проверьте таблицы и правила, выполнив
iptables --list --table xxx
iptables --list-rules --table xxx
команды (где xxx необработанный, mangle, nat)
3.) дважды проверьте правила переадресации на вашем маршрутизаторе 10.8.10.1 => они действительно достигают вашего хоста?
Надеюсь, это поможет.
(редактировать)
еще одна вещь, которая приходит мне на ум, - это то, что единственный маршрут, который у вас есть на вашем интерфейсе, - это локальная сеть, другими словами, если маршрутизатор не МАСШТАБИРУЕТ пакеты, приходящие на хост из внешнего мира, тогда пакеты будут считается немаршрутизируемым и, следовательно, отбрасывается фильтрацией обратного пути - вы можете проверить rp_filter и безопасность Linux LPIC-3
Существует несколько причин, по которым система отбрасывает пакет без уведомления, но этот случай действительно прост: что вы видите в результате ip r g 34.73.148.195? Поскольку у вас нет маршрута через enp10s0, кроме 10.8.10.0/24, вы можете отключить rp_filter ... или добавить некоторые/право маршрут по умолчанию:
ip r a default via 10.8.10.1 dev enp10s0 metric 50
После всего, этот это роутер, а не местный сети на vlan18 или vlan150, не так ли? Почему вы хотите выходить во внешний мир через vlan18 или vlan150?
Поскольку enp10s0 также настроен для DHCP, проблема в том, что ваш маршрутизатор не настроил маршрут по умолчанию на вашем сервере. Это объясняет отсутствие согласованности: если маршрут появляется, значит, вы подключены, если пропадает - нет.
Для справки: использовать DHCP на таких серверах - это действительно плохая идея. Даже если маршрут по умолчанию настроен как статический с более низкой метрикой, как указано выше, один мошеннический DHCP-сервер может легко вставить более конкретную сеть; рассмотрите 10.8.10.0/31 (или на самом деле что-нибудь до / 25), предоставленное на vlan18 / 150 - такой адрес наверняка вырежет вас из правильный (?) маршрут по умолчанию через enp10s0. Если роутер ваш и вы хотите использовать его как в маршрут по умолчанию и сохраните конфигурацию DHCP на других (локальных) интерфейсах, рассмотрите возможность использования адреса подключения / 31 (или, по крайней мере, «классический» / 30).
В любом случае, должен ли ваш сервер быть доступен из внешнего мира через vlan18 или vlan150 по каким-то другим правилам переадресации на соответствующих маршрутизаторах? Если это так, вам придется справиться с маршрутизацией на основе политик, поскольку ответные пакеты должны отправляться через интерфейсы, через которые были доставлены входящие. В конце концов, у вас здесь нет общедоступного IP, поэтому он не будет работать с асимметричной маршрутизацией (что в целом не запрещено).
На самом деле, поскольку вы не можете выполнять асимметричную маршрутизацию (без общедоступного IP-адреса) и не использовать маршрутизацию на основе политик, вам не следует отключать rp_filter - это только скроет реальные проблемы, лежащие в основе. В любом случае это не сработает - пакеты, пересылаемые вашим маршрутизатором (вероятно, DNAT-ed), будут доставлены на ваш сервер, но ответы будут отправляться либо на vlan18, либо на vlan150, а не на маршрутизатор, который имеет соответствующую запись conntrack и владеет адресом соединение было инициировано в.
Что касается этого вопроса - вы можете скрыть все, что связано с iptables. Каждый раз, когда вы видите «тихое» падение, то есть не видимое в счетчиках iptables, даже не беспокойтесь о дальнейшем исследовании проблемы на уровне netfilter. Это может быть потеря сетевого адаптера (проблемы с буфером, нехватка ЦП) - легко проверяется с помощью tcpdump, истечения срока действия TTL (при пересылке, для пакетов с нелокальным адресатом) или некоторой внутренней фильтрации, как здесь (обратный путь).