Заранее извиняюсь за следующую новеллу.
У меня есть USB-накопитель, подключенный к Raspberry Pi под управлением Raspbian; К сожалению, crashplan больше не работает с Raspbian, поэтому я не могу выполнить его резервное копирование на мой сервер Crashplan (творчески названный "backup"). Вместо этого я пытаюсь сделать так, чтобы NFS разделяла файловую систему с моим сервером Crashplan и позволяла ей синхронизировать ее с локальной файловой системой, но я не могу смонтировать ее на сервере резервного копирования.
"backup" - это виртуальная машина CentOS 6, работающая на ESXi и находящаяся в другой подсети, чем Pi; Я использую VyOS в качестве маршрутизатора. Пока что в целом все работает отлично, но я подозреваю, что что-то в VyOS может испортить работу. VyOS настроен для маршрутизации между моими 10.47.6.0/24 (где находится пи) и 10.47.7.0/24 (где сидит большинство моих виртуальных машин). Когда я делаю rpcinfo от pi (или от другого сервера в той же подсети), это успешно; когда я делаю это из другой подсети, я получаю:
rpcinfo: can't contact portmapper: RPC: Unable to receive; errno = Connection reset by peer
Он также работает с VyOS VM.
Пи - это путь в мою сеть (мой маршрутизатор Verizon перенаправляет на него определенные порты для внешнего доступа), поэтому iptables настроен на блокирование большинства вещей. Тем не менее, он широко открыт для всех портов в двух моих подсетях:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 165.160.2.0/24 anywhere tcp dpt:https
ACCEPT all -- localhost anywhere
ACCEPT all -- 10.47.6.0/23 anywhere
ACCEPT tcp -- 165.160.32.0/24 anywhere tcp dpt:ssh
ACCEPT tcp -- 165.160.2.0/24 anywhere tcp dpt:ssh
ACCEPT all -- 10.8.0.0/24 anywhere
ACCEPT udp -- anywhere anywhere udp dpt:http-alt
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOGGING all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain LOGGING (1 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 2/min burst 5 LOG level warning prefix "IPTables-logged: "
DROP all -- anywhere anywhere
Сам VyOS не имеет настроенных межсетевых экранов между двумя подсетями:
vyos@vyos:~$ show firewall
-----------------------------
Rulesets Information
-----------------------------
vyos@vyos:~$
У этого есть самая основная возможная конфигурация маршрутизации:
vyos@vyos:~$ show configuration
interfaces {
ethernet eth0 {
address 10.47.6.11/24
duplex auto
hw-id 00:0c:29:de:e1:e1
smp_affinity auto
speed auto
}
ethernet eth1 {
address 10.47.7.1/24
duplex auto
hw-id 00:0c:29:de:e1:eb
smp_affinity auto
speed auto
}
loopback lo {
}
}
nat {
source {
rule 10 {
outbound-interface eth0
protocol all
source {
address 10.47.7.0/24
}
translation {
address 10.47.7.0/24
}
}
}
}
protocols {
static {
route 0.0.0.0/0 {
next-hop 10.47.6.1 {
distance 1
}
}
}
}
<snippety snip snip>
Я могу пинговать повсюду, я могу ssh, я могу получить доступ к сети и другим сервисам, работающим в 10.47.7.0/24 VLAN на различных портах, поэтому я не думаю, что у меня проблема с брандмауэром. Что еще более важно, когда я подключаю strace к демону rpcbind на моем pi, он видит, что соединение установлено, а затем сбрасывает его по какой-то причине, что я недостаточно умен для перевода из данных трассировки. Это уже в 5 раз длиннее, так что я избавлю вас от полного вывода стриса, потому что до определенного момента он идентичен.
Когда я успешно соединяюсь с VyOS, пи говорит:
write(12, "\200\0\2t\16z\37\322\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1"..., 632) = 632
poll([{fd=5, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=6, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=7, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=8, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=9, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=10, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=11, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=12, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 8, 30000) = 1 ([{fd=12, revents=POLLIN|POLLRDNORM}])
read(12, "", 4) = 0
close(12) = 0
... тогда он открывает опрос, чтобы ждать другого соединения. Когда я делаю это с моего резервного сервера:
write(12, "\200\0\2t\314\315\372\355\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1"..., 632) = -1 ECONNRESET (Connection reset by peer)
close(12) = 0
Я полагаю, это может быть проблема с брандмауэром, но VyOS вообще не имеет брандмауэра и сервера резервного копирования; другие устройства в той же подсети, что и сервер резервного копирования, могут нормально выполнять резервное копирование rpcinfo -p, и ни одно из них не может выполнять rpcinfo my pi. Как ни странно: серверы в сети 10.47.7 могут rpcinfo серверы в сети 10.47.6, кроме пи. Но пи позволяет подключать по любому протоколу и любой порт от всего , что видит в 10.47.6.0/23 (он же, обе подсети), и Трассирование на RPCbind указывает , что он действительно видит входящее соединение. Единственное, о чем я могу думать, это то, что он блокирует свои собственные исходящие соединения на 10.47.7.0/24, но у меня нет каких-либо правил исходящих событий и политики ACCEPT по умолчанию, и когда я сбрасываю всю таблицу для быстрого теста, я все еще есть неудачи. Что здесь происходит? Пи прослушивает все обычные порты:
root@splunk:~> rpcinfo -p pi
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 60044 status
100024 1 tcp 55702 status
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049
100227 3 tcp 2049
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 38666 nlockmgr
100021 3 udp 38666 nlockmgr
100021 4 udp 38666 nlockmgr
100021 1 tcp 44067 nlockmgr
100021 3 tcp 44067 nlockmgr
100021 4 tcp 44067 nlockmgr
100005 1 udp 51123 mountd
100005 1 tcp 57740 mountd
100005 2 udp 39024 mountd
100005 2 tcp 53219 mountd
100005 3 udp 40590 mountd
100005 3 tcp 47949 mountd
Argh !!!