Удаленный вход SSH не работает

У меня есть компьютер за маршрутизатором с настройкой перенаправления портов Port 22 для SSH, который отлично работает – я могу войти и все. То, что я пытаюсь сделать, – это подключить этот ПК к VPN и разрешить трафик в локальной сети или через VPN-соединение (для доступа в Интернет). Это также отлично работает. Как только VPN-соединение нарушено, ПК не имеет подключения к Интернету. Теперь я делаю это с помощью IPTABLES, проблема в том, что я не могу заставить входящий SSH работать из внешних источников через перенаправление портов маршрутизатора. Я могу использовать SSH для ПК из локальной сети.

Вот что я пробовал:

# Allow traffic to VPN SERVER sudo iptables -A INPUT -s $REMOTE_IP -j ACCEPT # Allow ssh traffic iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT # Allow local traffic. sudo iptables -A INPUT -s 10.0.0.0/8 -j ACCEPT sudo iptables -A INPUT -s 172.16.0.0/12 -j ACCEPT sudo iptables -A INPUT -s 192.168.0.0/16 -j ACCEPT # Disallow everything else. sudo iptables -A INPUT ! -i tun+ -j DROP # Allow traffic from VPN SERVER. sudo iptables -A OUTPUT -d $REMOTE_IP -j ACCEPT # Allow local traffic. sudo iptables -A OUTPUT -d 10.0.0.0/8 -j ACCEPT sudo iptables -A OUTPUT -d 172.16.0.0/12 -j ACCEPT sudo iptables -A OUTPUT -d 192.168.0.0/16 -j ACCEPT # Disallow everything else. sudo iptables -A OUTPUT ! -o tun+ -j DROP sudo openvpn --config client.cfg --auth-user-pass client.cred --daemon 

Вот мой iptables -vL -n вывод: (Заменил сервер vpn на XX.XX.XX.XX)

 Chain INPUT (policy ACCEPT 25674 packets, 4792K bytes) pkts bytes target prot opt in out source destination 78848 11M ACCEPT all -- * * XXX.XXX.XXX.XXX 0.0.0.0/0 3176 318K ACCEPT tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW,ESTABLISHED 0 0 ACCEPT all -- * * 10.0.0.0/8 0.0.0.0/0 0 0 ACCEPT all -- * * 172.16.0.0/12 0.0.0.0/0 2517 231K ACCEPT all -- * * 192.168.0.0/16 0.0.0.0/0 35 12374 DROP all -- !tun+ * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 32187 packets, 4374K bytes) pkts bytes target prot opt in out source destination 3681 2443K ACCEPT tcp -- * eth1 0.0.0.0/0 0.0.0.0/0 tcp spt:22 state ESTABLISHED 70697 10M ACCEPT all -- * * 0.0.0.0/0 XXX.XXX.XXX.XXX 0 0 ACCEPT all -- * * 0.0.0.0/0 10.0.0.0/8 0 0 ACCEPT all -- * * 0.0.0.0/0 172.16.0.0/12 27 5787 ACCEPT all -- * * 0.0.0.0/0 192.168.0.0/16 2265 150K DROP all -- * !tun+ 0.0.0.0/0 0.0.0.0/0 

И да, если я делаю ifconfig, у меня есть только eth1, а не eth0, так что это не так.

Здесь также вывод netstat -rn

 Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 XX.XXX.242.128 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1 XX.XXX.193.107 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1 XX.XXX.242.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 128.0.0.0 XX.XXX.242.128 128.0.0.0 UG 0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 

  • «Bind: Address уже используется» при создании моста в Linux для Windows
  • Что черт переопределяет мой путь в SSH?
  • перенаправить звук (микрофон) через ssh, как позвонить через ssh?
  • Проверьте, какие ключи ssh приняты на сервере
  • Что произойдет с сеансом сеанса по ssh, когда соединение потеряно?
  • Получение пользовательского ввода из сценария, используемого как stdin для сеанса SSH
  • Конкретный пользовательский SSH-RSA с корневым доступом (через AWS EC2)
  • Определить пользователей ближайшего компьютера из CLI
  • 2 Solutions collect form web for “Удаленный вход SSH не работает”

    Как правильно сказал penguin359, проблема в том, что обратные пакеты будут маршрутизироваться через VPN вместо вашего локального маршрутизатора, откуда и поступало входящее соединение. SNAT на маршрутизаторе – это одно решение, но если это невозможно, вы можете использовать расширенную маршрутизацию на своем ПК.

    Вам необходимо добавить эти расширенные правила маршрутизации в дополнение к существующим правилам iptables:

     ip rule add from 192.168.1.X table 128 ip route add table 128 to 192.168.1.0/24 dev eth1 ip route add table 128 default via 192.168.1.1 

    Замените 192.168.1.X IP-адресом локальной сети вашего ПК. 192.168.1.1 – это маршрутизатор вашей локальной сети, а 192.168.1.0/24 – подсеть вашей локальной сети.

    Первая команда создает правило, которое вызывает любой пакет с адресом источника 192.168.1.X для использования специальной таблицы маршрутизации, которая имеет номер 128. Следующие две команды создают таблицу маршрутизации 128, в которой шлюз по умолчанию является вашим маршрутизатором (и не ваш VPN-сервер, как в основной таблице маршрутизации).

    Единственными пакетами, которые будут иметь исходный адрес 192.168.1.X, будут пакеты, отвечающие на входящие соединения с вашего маршрутизатора (например, перенаправленные через порт соединения SSH) и пакеты, предназначенные для вашей локальной сети. Это именно те пакеты, которые вы не хотите использовать VPN. Все остальные исходящие пакеты будут иметь другой адрес источника и будут использовать основную таблицу маршрутизации, которая маршрутизирует их по VPN.

    Чтобы уточнить, в то время как VPN работает, SSH из внешних источников не работает, но до запуска VPN, SSH из всех источников работал. Проблема сводится к таблице маршрутизации. Как вы видите выше, маршрут по умолчанию ( 0.0.0.0 ) подходит к tun0 . Я не понимаю, что со смешной 128.0.0.0 , но это вызовет любой внешний адрес, начинающийся с 1-126, для использования tun0 . Не имеет значения, откуда поступают входящие пакеты для SSH, исходящие пакеты будут выходить только там, где они совпадают в таблице маршрутизации. Я сам это сделал. Стандартное решение, которое я использую для этой проблемы, заключается в использовании входящих правил SNAT, которые меняют адрес источника входящего пакета на внутренний IPv4-адрес маршрутизатора. Это приведет к тому, что он появится как внутреннее соединение с ПК, и он будет счастливо перенаправить его обратно на маршрутизатор, поскольку он находится в локальном месте назначения в таблице маршрутизации выше. Затем маршрутизатор обратит SNAT и отправит его обратно в дикую природу, чтобы его понюхали и подталкивали все гнусные хакеры. Это SNAT должен существовать как правило iptables на маршрутизаторе, а не на ПК внутри сети. Если вы используете что-то вроде шлейфа Linksys WRT, вам может потребоваться установить OpenWRT или подобное на него, чтобы получить такой контроль над брандмауэром / NAT-правилом.

    Interesting Posts

    Kernel Panic – не синхронизация: VFS: невозможно установить root fs на неизвестный блок (0,0)

    Как я могу сделать операционную систему как можно меньше, но все же обеспечить основные функции?

    bash $ (printf "% s \ n") не создает многострочный

    изменение оболочки по умолчанию в / bin / bash в планировщике заданий, например, в CRON

    Удаленный запуск и доступ к рабочему столу Debian KDE

    Как загрузить каталог в кеш файловой системы?

    Debian – X11 не отображается до переключения VT

    Разница между lib, lib32, lib64, libx32 и libexec

    Почему проблема безопасности связана с / usr / sbin, принадлежащей bin?

    Каково состояние стандартного потока ввода-вывода при выдаче команды?

    Можно проверить способность sudo до sudo'ing?

    Предотвращение спуфинга почтового сервера

    Сценарий Bash для извлечения ключевых слов из текущего каталога

    Grep файл в определенном поле

    Как активировать swap после добавления дополнительной памяти?

    Linux и Unix - лучшая ОС в мире.