marfo4ka

В случае shadowsocks мы можем попытаться, если Вам не лень поэкспериментировать. Но задайте себе вопрос — Вы точно хотите весь трафик всех служб подвергать проверкам на вхождение в whitelist? Финальные правила для SS выглядят: если обращение к IP из списка КВАСа, то трафик отправляется в порт SS клиента: iptables -A PREROUTING -w -t nat -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-ports 1181 iptables -A PREROUTING -w -t nat -i br0 -p udp -m set --match-set unblock dst -j REDIRECT --to-ports 1181 Здесь есть фильтр -i br0 — в домашней сети. Если добавите через kvas vpn net add обход для гостевой, то появятся ещё правила с -i br1. Если хотите прокидку для SSTP-сервера, то нужны -i sstp+. Для WireGuard аналогично. Если добавите через kvas vpn net add обход для IKEv2/IPSec, то у IPSec своего отдельного интерфейса нет, там фильтр по IP клиентов и WAN-порту -s 192.168.2.0/24 -i eth3 (интерфейс может быть eth2.2). Дык вот, по аналогии с IKEv2/IPSec можете навеситься на весь WAN-порт без ограничения по IP. Это, скорее всего, отфильтрует весь трафик. И даже можете сделать эти правила самовосстанавливаемыми.

Вы уверены в корректности своего высказывания? У меня: Применён `opkg dns-override`. Один системный профиль DNS с DoT серверами. В котором разрешён транзит запросов. Контентный фильтр выключен. Компоненты «NextDNS» и «SkyDNS» отключены. Как только я создаю тестовую политику доступа, закидываю туда одного клиента, то в `iptables-save | grep " 53 "` появляется: -A _NDM_HOTSPOT_DNSREDIR -i br0 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br0 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 53 -j REDIRECT --to-ports 41100 `dns-proxy no intercept enable` сообщает `disable intercept for system profile`, при этом в `show dns-proxy` кроме системного виден ещё один профиль Policy0, у которого: dns_tcp_port = 41100 dns_udp_port = 41100 Навскидку, есть такой костыль (постоянно портит отбирающие правила), но хотелось бы адекватного поведения из коробки.

`opkg dns-override` позволяет КВАС установить другой DNS. Но при использовании политик начинает работать безусловный перехват днс-запросов прошивкой Кинетика (что выглядит ошибкой, если честно). Можете увидеть их `iptables-save | grep " 53 "`, на 41100 порт улетает отобранный у AdGuardHome/Dnsmasq dns-трафик. Навскидку, есть такой костыль (постоянно портит отбирающие правила).

В файле `/opt/etc/init.d/S10cron` заменить строку `ARGS="-s"` на `ARGS=""` `/opt/etc/init.d/S10cron restart`

Можно попробовать сделать это руками, и если будет работать у нескольких людей — только тогда можно задуматься о такой функции (но и то маловероятно). Выдать нужному устройству фиксированный IP. «Мои сети и Wi-Fi» → «Список клиентов», клик на нужном, «Зарегистрировать», клик на нём ещё раз, «Постоянный IP-адрес», «Сохранить». Допустим, выдан 192.168.1.35. Понять, в какой он сети. WiFi br0, гостевой WiFi br1, локальный eth2.1 или eth2, клиент IKEv2 eth3 или eth2.2, VPN-клиенты в своих именованных. Допустим, у вас br0. Добавить правила. Тут случай, если хотите пустить трафик с одного устройства с учётом списка разблокировки iptables -A PREROUTING -w -t nat -s 192.168.1.35 -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1181 iptables -A PREROUTING -w -t nat -s 192.168.1.35 -i br0 -p udp -m set --match-set unblock dst -j REDIRECT --to-port 1181 Прям весь трафик без учёта списка разблокировки — надо тестировать. Что-то типа ipset create localprivate hash:net -exist ipset add localprivate 127.0.0.0/8 ipset add localprivate 10.0.0.0/8 ipset add localprivate 100.64.0.0/10 ipset add localprivate 172.16.0.0/12 ipset add localprivate 192.168.0.0/16 iptables -A PREROUTING -w -t nat -s 192.168.1.35 -i br0 -p tcp -m set ! --match-set localprivate dst -j REDIRECT --to-port 1181 iptables -A PREROUTING -w -t nat -s 192.168.1.35 -i br0 -p udp -m set ! --match-set localprivate dst -j REDIRECT --to-port 1181 Наверняка какие-то из локальных служебных адресов ещё забыты. Если всё работает, то сообщить об этом. Можете сделать это правило автоматически добавляемым (при смене настроек, ребуте роутера). P.S. Админы/модераторы, удалите это моё сообщение, в 2 случаях из 3 там недостаточно правил.

Эта часть совета выглядит немного "вредной". Почему не использовать нормальный DoH или DoT для всего, зачем выборочный DNS для отдельных сервисов? В целом, рекомендую: Включить шифрование DNS через _kvas crypt_. В «Управление» → «Параметры системы» → «Изменить набор компонентов» добавить «Прокси-сервер DNS-over-TLS» и/или «Прокси-сервер DNS-over-HTTPS». В «Сетевые правила» → «Интернет-фильтры» → «Настройка DNS» оставить только с поддержкой DoT или DoH. Никаких провайдерных DNS! Общие, например, 1.1.1.1, 1.0.0.1 (cloudflare-dns.com); 8.8.8.8, 8.8.4.4 (dns.google); 9.9.9.9 (dns.quad9.net).

Сказанное далее не проверялось! 1. Если нужно направить весь трафик всех устройств, то для команды kvas add сказано Предположу, что закинуть 0.0.0.0/0 (что будет легко удалить обратно) поможет. 2. Если речь о конкретном устройстве (хотите только его, но не его подсеть), то в случае Shadowsocks и домашнего WiFi (подсеть br0 в правилах) надо выдать ему в правилах DHCP фиксированный IP и попробовать iptables -A PREROUTING -w -t nat -s 192.168.1.25 -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1181 iptables -A PREROUTING -w -t nat -s 192.168.1.25 -i br0 -p udp -m set --match-set unblock dst -j REDIRECT --to-port 1181 3. Если это конкретное устройство должно ходить без учёта списка обхода (всем трафиком), то в случае Shadowsocks попробовать без правил вхождения в список обхода iptables -A PREROUTING -w -t nat -s 192.168.1.25 -i br0 -p tcp -j REDIRECT --to-port 1181 iptables -A PREROUTING -w -t nat -s 192.168.1.25 -i br0 -p udp -j REDIRECT --to-port 1181

Попробуйте перебором, на моём устройстве это не воспроизвести. Трафик в присланном логе есть в eth2, eth2.1, eth2.2. Один из них точно WAN, и там роутером навешаны политики обработки IKEv2/IPsec (IPsec не создаёт свои интерфейсы, как другие подключения, оттого с ним такие и проблемы — ищем вот его)). Раз eth2 (с Ваших слов) не подошёл, то предполагаю, что у Кинетиков на базе одного сетевого интерфейса eth2.2 — WAN, eth2.1 — LAN. У двуинтерфейсных WAN в eth3. Сразу же накидана задача на будущее. Туда осталось вписать тот интерфейс из 3ёх, с которым у Вас всё заработает.

Ох, ну вот и виновник. Попробуйте эти 2 правила для себя указывать с eth2. Как сделать красиво выбор в коде КВАСа — ума не приложу. В API Кинетика все интерфейсы названы виртуально, указаний на подпись интерфейса в entware нет. Чтобы Вы поняли, вот как выглядят lan'ы на Гиге

@x-tropic Добавьте ещё вывод ifconfig. У вас Hopper, может изменили чего и там WAN-порт на другом интерфейсе, не eth3. Заранее вопрос: каких-то хитрых манипуляций с портами (типа переназначение WAN) не делали? Когда устройства подключены к роутеру через IKEv2, в блоке «VPN-сервер IKEv2/IPsec» появляется «Статистика подключений». Там в таблице будут присвоенные IP. Выдаёт правильные из 192.168.2.0/24?

Можем попробовать. Для начала перейдите на последнюю версию (или хотя бы этого года, фиксы зашли в декабре). Возможно, лучшей стратегией будет полная переустановка (в свете того, что манипуляции разные Вы пытались повторить). kvas export /opt/tmp/hosts.backup kvas rm full cd /opt/tmp curl -sOfL http://kvas.zeleza.ru/upgrade sh ./upgrade После переустановки или хотя бы апгрейда с kvas vpn net del сети IKEv2 снять логи и прислать сюда. iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|^\*|^\:' &> /opt/tmp/kvas_iptables_before.txt kvas vpn net add # в команде выше выберите сеть IKEv2 iptables-save | grep -E 'PREROUTING|nat' | grep -vE '_NDM|^\*|^\:' &> /opt/tmp/kvas_iptables_after.txt kvas debug &> /opt/tmp/kvas_debug.txt И скрин настроек IKEv2 после этого всего («Управление» → «Приложения» → «VPN-сервер IKEv2/IPsec»). А то вспоминается, что на одной из первых версий 4ки была проблема с DNS именно у прошивки.

Не совсем понятно, почему Вы уверены, что для использования IKEv2 необходим белый IP. Со смартфона вне дома нормально подключаюсь к роутеру, используя DDNS (в админке роутера «Сетевые правила» → «Доменное имя» → «KeenDNS»). Прелесть IKEv2 как раз в том, что он из коробки есть в Android, Windows и на яблоках. Или у Вашего провайдера какой-то хитрый NAT? Ровно так это и работает из коробки. У меня IKEv2 до роутера + Shadowsocks соединение к серверу. Как раз сегодня были обновлены прошивка роутера и КВАС, полёт нормальный.

У Инсты глубокая интеграция с ФБ (один владелец же), так что сложно отделить одно от другого. У меня работает с: *cdnfacebook.com *cdninstagram.com *facebook.com *fbcdn.net *fbsbx.com *fburl.com *instagram.com Под вопросом ещё *fb.com и *ig.me

Это было пофикшено в #57 очень давно. С 33 релиза связка Shadowsocks + гостевая IKEv2 отлажена идеально. Было бы хорошо, если кто-нибудь проверил бы связку VPN + гостевая IKEv2 по такому списку. Единственный нюанс обновления, лучше перед kvas upgrade full почистить обход гостевых через kvas vpn net del, а после обновления перезагрузить роутер, и только тогда делать kvas vpn net add. Потому что правила iptables немного изменялись, новая версия может не до конца зачистить правила старой.

Или путь 4 — сделать всё самостоятельно. И снова здравствуйте) По сути, вся маршрутизация ssr держится на 4 правилах для br0 (интерфейса домашней сети): # DNS iptables -A PREROUTING -w -t nat -i br0 -p tcp --dport 53 -j DNAT --to 192.168.1.1 iptables -A PREROUTING -w -t nat -i br0 -p udp --dport 53 -j DNAT --to 192.168.1.1 # Выборочные IP в Shadowsocks iptables -A PREROUTING -w -t nat -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1181 iptables -A PREROUTING -w -t nat -i br0 -p udp -m set --match-set unblock dst -j REDIRECT --to-port 1181 При разворачивании VPN-сервера на роутере появляется соответствующий ему сетевой интерфейс, для которого эти правила нужно просто размножить. Был проведён эксперимент, связка SS и WireGuard-сервера на роутере прекрасно работают. В подтверждение моих слов — на Хабре поступали ровно также. У вас даже удобный механизм для расшаривания на новый интерфейс реализован (тот самый kvas vpn guest), имеет смысл добавить туда поддержку Shadowsocks вместо заглушки-отписки. Но мне-то требовался в связку VPN-сервер IKEv2/IPsec. IPSec, в отличии от привычных VPN-решений, не создаёт сетевые интерфейсы, только политики обработки. На него КВАС не может расшарить трафик даже в случае отказа от SS, как я понимаю. И просто так заменить br0 на нужное имя, как поступали выше, не получится. Но при создании IKEv2 сервера указываешь диапазон IP для DHCP. Можно фильтровать по нему с учётом знания, что сам трафик сервера обитает в интерфейсе WAN — eth3. -i br0 превращается в -s 172.20.8.0/24 -i eth3. IKEv2-сервер на Кинетике обязательно указывает клиенту DNS-сервер, поэтому в его настройках указываем IP роутера (192.168.1.1), дополнительный роутинг DNS (первые 2 правила) тогда не требуется. Сухое итого, как заставить работать на роутере обход у клиентов IKEv2 через Shadowsocks: nano /opt/etc/ndm/netfilter.d/100-shadowsocks-vpn-server #!/bin/sh if [ "${type}" = "iptables" ] && [ "${table}" = "nat" ] && [ -z "$(iptables-save 2>/dev/null | grep '192.168.2.0/24 -i eth3')" ] ; then iptables -A PREROUTING -w -t nat -s 192.168.2.0/24 -i eth3 -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1181 iptables -A PREROUTING -w -t nat -s 192.168.2.0/24 -i eth3 -p udp -m set --match-set unblock dst -j REDIRECT --to-port 1181 fi chmod +x /opt/etc/ndm/netfilter.d/100-shadowsocks-vpn-server reboot iptables -vL PREROUTING -t nat (для финальной проверки, что есть 4 правила от КВАСа и 2 ваших) В альтернативу моему подходу, некоторые добавляют в конце что-то типа iptables -A OUTPUT -t nat -p tcp -m set --match-set unblock dst -j REDIRECT --to-port 1181 Но мне кажется, проверка всего трафика немного кощунственна и не оптимальна. P.S. В настройках IKEv2-сервера на Keenetic не убирать чекбокс «Множественный вход». Без него на прошивке 3.9.8 прекращает отдаваться настройка «DNS-сервер». По крайней мере, встроенному в Android по умолчанию VPN-клиенту. P.P.S. КВАС периодически передобавляет правила iptables. Но т.к. сверка «есть ли это правило уже» не полная, то он принимает наши правила за свои, и обход в домашней сети не возвращает! Нужно в файле /opt/apps/kvas/etc/ndm/ndm в строчке 247 расширить проверку до prouting_rules=$(ip4save | grep PREROUTING | grep "${interface}" | grep "${table_name}" | grep REDIRECT | grep "${proxy_port}") и её же в /opt/etc/ndm/netfilter.d/100-proxy-redirect:25 proxy_port=$(get_config_value SSR_DNS_PORT) interface=$(get_local_inface) if ! ip4save | grep "${SSR_IPTABLES_CHAIN}" | grep -qv '\[0:0\]' && \ ! ip4save | grep PREROUTING | grep "${interface}" | grep "${table_name}" | grep REDIRECT | grep -q "${proxy_port}" ; then