Это интересно. Другие ответы, которые я вижу, говорят вам поменять экранированную кавычку и экранированное пространство на строку в кавычках. На самом деле они эквивалентны, поэтому вы не увидите никаких изменений(a\'\ b
для оболочки то же самое, что и"a' b"
).
Проблема здесь заключается в том, как scp
в удаленной системе интерпретируется переданная командная строка.
Например, это сработает:
scp John\'s\ folder/file localhost:/tmp/dst
Но это не удастся:
scp localhost:/tmp/src/John\'s\ folder/file /tmp/dst
(Для примера я использовал localhost
; вы должны использовать user@host
для вашей ситуации.)
Если вы включите флаг-v
(verbose)в scp
, вы сможете точно увидеть, что происходит, что приводит к сбою:
debug1: Sending command: scp -v -f /tmp/src/John's folder/file
bash: -c: line 0: unexpected EOF while looking for matching `''
bash: -c: line 1: syntax error: unexpected end of file
Неудачное решение здесь заключается в том, что вам нужно экранировать специальные символы (, включая пробелы )дважды -один раз для локальной оболочки и один раз для удаленной оболочки:
scp localhost:"/tmp/src/John\'s\ folder/file" /tmp/dst
Поскольку ответ привязан к конфигурации, я делаю некоторые предположения. Вам придется адаптировать ответ, чтобы он соответствовал фактической конфигурации.
wan1 LAN и шлюз для wan1 произвольно выбраны как 84.114.7.0/24 и 84.114.7.254.
правила брандмауэра не учитывались, но все это не должно с ними взаимодействовать.
В Linux всегда следует использовать ip link
,ip address
иip route
вместо устаревших ifconfig
и route
. route
вероятно, все равно не сможет обрабатывать дополнительные таблицы маршрутизации.
Напоминаем, что iptables или на самом деле netfilter не выполняет маршрутизацию, но своими действиями может изменять решения о маршрутизации, принимаемые стеком IP-маршрутизации. Эта схема показывает, где могут приниматься решения о маршрутизации. Для маршрутизируемого (, а не локального )трафика, который находится только в одном месте, и изменения должны произойти до:raw/PREROUTING , mangle/PREROUTING или nat/PREROUTING , с raw часто непрактичным, а nat только в ограниченных случаях, в основном оставляя mangle .
базовая многоканальная -домашняя система , для использования нескольких путей к Интернету,обычно требуется политика маршрутизации , где маршрут может меняться не только с пунктом назначения, как обычно, но также с источником или с другими селекторами (, как будет сделано здесь ), используемыми в правилах политики. В Linux дополнительные правила, созданные с помощью ip rule
, могут выбрать другую таблицу маршрутизации, чтобы выбрать, например, другой маршрут по умолчанию. (по-прежнему будет только один маршрут по умолчанию, но один для каждой таблицы маршрутизации).
Таким образом, здесь принцип, оставаясь активным Strict Reverse Path Forwarding(rp _filter ), заключается в том, чтобы принимать пакеты, поступающие из wan1 , и направлять их, как обычно, к eth0 с использованием альтернативной таблицы (, которая позволит пройти rp _фильтр). Эта дополнительная таблица маршрутизации должна дублировать основную таблицу маршрутизации, но использовать только маршруты, необходимые для альтернативного пути(wan1)и, таким образом, не включать обычные маршруты с «нормальным» путем(wan0). Если другие маршруты (, такие как VPN и т. д. ), должны быть задействованы в потоках, проходящих через wan1 , есть вероятность, что их маршрут также необходимо добавить, или должны быть добавлены другие дополнительные правила и таблицы. создан, чтобы справиться с этим.
Поскольку в Linux прекращено использование кэша маршрутизации в ядре 3.6, ничто в стеке маршрутизации не указывает отправлять ответные пакеты от host1 клиенту через wan1 , и они в конечном итоге выходит с использованием основного маршрута по умолчанию через wan0 , NAT с неправильным IP-адресом для этого интерфейса(netfilter не зависит от маршрута -и уже выбрал NAT для выполнения при получении первый пакет соединения )и, вероятно, отброшен следующим маршрутизатором интернет-провайдера, который также выполняет строгую фильтрацию обратного пути.Существует функция netfilter , позволяющая копировать метку пакета в метку conntrack и помещать ее обратно в пакет :, это будет действовать как память маршрута для соединения. Таким образом, iptables и netfilter 's conntrack будут использоваться для двух связанных функций :для маркировки пакета, чтобы изменить решение о маршрутизации, и для восстановления. эта метка на ответных пакетах, идентифицированных как часть одного и того же соединения.
Все это переводится в эти команды:
Использовать для помеченных пакетов (произвольное значение метки 101 )дополнительную таблицу маршрутизации (несвязанное произвольное значение также 101):
ip rule add fwmark 101 lookup 101
Заполнить таблицу записями, аналогичными основной таблице маршрутизации, за вычетом wan0 записей:
ip route add table 101 192.168.0.0/16 dev eth0
ip route add table 101 84.114.7.0/24 dev wan1
ip route add table 101 default via 84.114.7.254 dev wan1
В следующих командах возможны различные оптимизации. Вероятно, их можно улучшить.
Восстановить потенциальную предыдущую уже сохраненную метку, чтобы ответные пакеты получали ту же метку, что и исходные пакеты.:
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
Пометить пакеты, поступающие из wan1 , чтобы изменить решение о маршрутизации, указанное выше:
iptables -t mangle -A PREROUTING -i wan1 -j MARK --set-mark 101
Если есть пометка, сохраните ее в conntrack(можно было бы сделать в таблице nat , чтобы сделать это только один раз для потока подключения, а не для каждого пакета):
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j CONNMARK --save-mark
На самом деле это все равно не пройдет проверку Strict Reverse Path Forwarding , так как эта недокументированная функция была добавлена в 2010 году. Ее необходимо использовать здесь:
sysctl -w net.ipv4.conf.wan1.src_valid_mark=1