iptables/маршрут для возврата входящего трафика из исходного интерфейса (eth0)
Когда вы используете команду mv и на самом деле пытаетесь переместить ее в папку из корневого каталога. Ваша команда должна быть из текущего каталога.
mv *.${myarray[$index]}./${myarray[$index]}/
Обратите внимание на .перед каталогом, он говорит вам искать папку в текущем каталоге, в противном случае вы можете просто написать:
mv *.${myarray[$index]} ${myarray[$index]}/
Приведенная выше команда также будет искать папку в текущем каталоге.
Исправление распространенного заблуждения:iptables не выполняет маршрутизацию. Он просто контролирует, разрешено ли маршрутизируемым потокам продолжаться или нет, но не меняет их направление (, если только не используются такие вещи, как NAT, который может изменить судьбу маршрутизации , по-прежнему выполняемую стеком маршрутизации ).. Вот почему самое главное в вопросе должно быть предоставление маршрутов и таблиц маршрутизации (, и для этого случая, похоже, правила маршрутизации тоже должны были быть предоставлены ).
Как только интерфейс туннеля исчезнет, все маршруты, использующие его, также исчезнут. Вы получаете маршрутизацию маршрутизатора на его единственном интерфейсе :, его входной интерфейс также является выходным интерфейсом:eth0 .
Вам просто нужно включить поток с помощью iptables, так как его политика по умолчанию — отбрасывать переадресованные пакеты:
sudo iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT
и это все, что вам нужно. Обычно ваш RPi уже имеет маршрут по умолчанию, настроенный на использование маршрутизатора 192.168.0.1, поэтому больше нечего делать. Если маршруты не являются стандартными, их нужно будет добавить в вопрос и обновить этот ответ.
Ниже приведены мелкие шрифты:
Когда хост-узел отправляет пакеты через RPi, RPi обнаружит, что это не оптимальный маршрут, и отправит обратно несколько пакетов перенаправления ICMP , чтобы предупредить клиента о том, что доступен более прямой маршрут :. ] через 192.168.0.1 напрямую. Узел может кэшировать информацию и отправлять свои следующие пакеты непосредственно этому маршрутизатору или может продолжать использовать RPi, который в любом случае будет продолжать пересылать эти пакеты. Фактический маршрутизатор, скорее всего, будет отправлять ответы непосредственно на хост-узел, создавая асимметричный маршрут. Поскольку все это происходит в одной и той же локальной сети и, следовательно, с одним и тем же интерфейсом, это должно быть нормально и нигде не вызывать такие вещи, как Strict Reverse Path Forwarding .
По этой причиневы не должны использовать дополнительные правила conntrack в этом случае (те, что уже есть, в порядке ).
-m conntrack --ctstate NEW,ESTABLISHEDне эквивалентен всем пакетам, потому что с точки зрения conntrack будут TCP-пакеты вне окна, вызванные пакетами, минующими RPi, которые вместо этого будут помечены INVALID (, но должна быть разрешена пересылка ).
Я ненавижу такие ответы, но я продолжаю. Похоже, вы используете более «классическое» соединение NordVPN на основе openVPN -. Знаете ли вы, что возможен формат туннеля wireguard?
Ваше соединение является туннельным, а не ethertap, поэтому ваше соединение может быть хорошим кандидатом.
Преимущества:
- Я думаю, что туннельное устройство (wg0 здесь )не отключается, если ваш туннель не работает
- Решения о маршрутизации (и DNS )типа «сделай это или используй это» настраиваются тривиально как часть настройки wireguard.
Я не хочу быть «тем парнем», так что мне жаль, что я могу показаться таким. Я чувствовал, что если вы только начинаете использовать NordVPN в качестве нового подключения, это прекрасная возможность убедиться, что вы видели другой вариант и все же решили, что настройка openVPN — это то, что вам нужно. Только что начав играть с WG вместо VTun (родительский проект Джеймс покинул, потому что он не хотел реализовывать то, что он все равно реализовал в openVPN )Я обнаружил, что он настраивается по крайней мере так же легко, как OpenVPN, если не проще, и, кажется, дает мне быстрый и надежный набор туннелей.
Сказав это, я ДЕЙСТВИТЕЛЬНО настроил конфигурацию «отправлять обратные пакеты через тот же интерфейс, через который они пришли» для многодомного -прокси-дроида, что является проблемой в Linux, потому что, в отличие от Windows, которая делает это по умолчанию, само ядро linux не помнит, как пришел пакет, обычно --, и нам приходится обманывать его с помощью какой-то хитрости iproute. Я посмотрю, смогу ли я найти записи примерно 10-летней давности (раннего CentOS6 ), когда этот ящик был изначально установлен.