1

Я использую OPENWRT Chaos Calmer на Raspberry pi 2. Я успешно настроил клиент OPENVPN, и клиент направляет мой трафик через VPN-туннель. Но когда я перезагружаю интерфейс pi LAN, подключайтесь напрямую к интерфейсу WAN в течение небольшого времени и направляйте трафик за пределы VPN-туннеля. Это произойдет только в течение очень малого времени. (Время, которое нужно VPN-клиенту для запуска). Но мне нужно это остановить. Мне нужно постоянно маршрутизировать практически весь трафик через VPN-клиент, и если VPN-клиент не подключен, он не должен иметь доступ к Интернету. Я настроил прокси-клиент под названием TINYPROXY с этой настройкой, и, возможно, это вызовет проблему. Но я не знаю, как это остановить

Это мои конфиги

/ И т.д. / конфигурации / сети

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config interface 'lan'
    option ifname 'eth0'
    option proto 'static'
    option netmask '255.255.255.0'
    option ipaddr '192.168.2.1'
    option dns '8.8.8.8 8.8.4.4'

config interface 'wan'
    option ifname 'eth1'
    option proto 'dhcp'
    option peerdns '0'
    option dns '8.8.8.8 8.8.4.4'

config globals 'globals'
    option ula_prefix 'fd14:b495:5965::/48'

config interface 'vpn0'
    option ifname 'tun0'
    option proto 'none'
    option auto '1'
    option delegate '0'

/ И т.д. / конфигурации / брандмауэр

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option network 'lan'

config zone
    option name 'wan'
    option output 'ACCEPT'
    option masq '1'
    option mtu_fix '1'
    option input 'ACCEPT'
    option forward 'ACCEPT'
    option network 'wan wan6 vpn0'

config rule
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'

config rule
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-IGMP'
    option src 'wan'
    option proto 'igmp'
    option family 'ipv4'
    option target 'ACCEPT'

config include
    option path '/etc/firewall.user'

config redirect
#   option target 'DNAT'
#   option dest 'vpn'
    option name 'Transparent Proxy Redirect'
    option src 'lan'
    option proto 'tcp'
    option dest_port '8888'
    option src_dport '80'
    option src_dip '!192.168.2.1'
    option dest_ip '192.168.2.1'

config zone
    option name 'vpn'
    option masq '1'
    option input 'ACCEPT'
    option forward 'ACCEPT'
    option output 'ACCEPT'
    option network 'vpn0'

config forwarding
    option src 'vpn'
    option dest 'lan'

/ И т.д. / конфигурации / tinyproxy

config tinyproxy
    option enabled '1'
    option User 'nobody'
    option Group 'nogroup'
    option Port '8888'
    option Timeout '600'
    option DefaultErrorFile '/usr/share/tinyproxy/default.html'
    option StatFile '/usr/share/tinyproxy/stats.html'
    option LogFile '/var/log/tinyproxy.log'
    option LogLevel 'Info'
    option MaxClients '100'
    option MinSpareServers '5'
    option MaxSpareServers '20'
    option StartServers '10'
    option MaxRequestsPerChild '0'
    option ViaProxyName 'tinyproxy'
    list Allow '127.0.0.1'
    list Allow '192.168.2.1/24'
    list ConnectPort '443'
    list ConnectPort '563'
    list ConnectPort '80'
    option Filter '/www/textui/tinyproxy/blocked.txt'

Я хочу именно этого добиться

ПОЛЬЗОВАТЕЛЬ -> LAN -> TINYPROXY -> VPN -> WAN

Моя TINYPROXY работает отлично. Все остальные конфиги работают нормально. Проблема существует только в течение небольшого времени при перезагрузке PI

Может ли кто-нибудь помочь мне в этом?

|источник

2 ответа2

0

Это для меня!) сложный вопрос. Я могу предложить частичное решение и идею проверить полное решение.

ЕСЛИ это обычный Linux, например Debian, можно вставить в файл /etc/network/interfaces в раздел для внешнего интерфейса (назовем его wan) следующую строку:

  pre-up iptables -A OUTPUT -s 192.168.0.0/24 -o wan -j DROP

где я предположил, что ваша локальная сеть 192.168.0.0/24. Тот факт, что мы используем pre-up дает уверенность в том, что правило брандмауэра действует при запуске интерфейса wan . Вместе с правилом:

 iptables -t nat -A POSTROUTING -o wan -j MASQUERADE

мы можем быть уверены, что пакеты из локальной сети проходят только через tun0 , хотя некоторые из них будут отброшены, пока мы ждем, пока OpenVPN установит соединение с его сервером.

Однако мне не удалось найти на веб-страницах OpenWRT замену вышеприведенному условию pre-up . Таким образом, если вы настроите свой брандмауэр с двумя приведенными выше правилами, вы будете уверены, что ни один пакет из вашей локальной сети не покинет ваш маршрутизатор за пределами OpenVPN, но вы не уверены, что брандмауэр iptables будет работать до создания сети.

На этой странице OpenWRT Wiki объясняется порядок выполнения различных сервисов:

rcS выполняет символические ссылки на фактические сценарии запуска, расположенные в /etc/rc.d/S##xxxxxx с опцией "start":

.....

S40network запустить сетевую подсистему (запустить /sbin /netifd, up интерфейсы и Wi-Fi

S45firewall создает и внедряет правила брандмауэра из /etc /config /firewall

Вы видите, что две службы запускаются одна за другой, что оставляет мало времени для прохождения пакетов; это, безусловно, лучше, чем ждать появления OpenVPN. Это моё частичное решение: оно частичное, потому что я сократил время, в течение которого пакеты LAN могут проходить, но я не сделал это время .=0

Вы можете попробовать инвертировать две службы, то есть переименовать их: 

      S40firewall
      S45network

и посмотрим, работает ли это. Я не уверен в том, что делает iptables/netfilter , когда интерфейс, который он пытается защитить, даже не существует. На моем Debian это работало нормально, но, поскольку у меня нет OpenWRT, чтобы попробовать это, я не могу быть уверен, что это будет работать и для вас. Это мое предложение для полного решения. Приветствия.

|источник
0

Проблема в том, что ваши пакеты не приходят из lan , они приходят от маршрутизатора, на котором работает ваш прокси. В брандмауэре нет правила принудительного исходящего трафика через VPN на маршрутизаторе.

Я не пробовал это, но ...

Установите option output REJECT в вашем интерфейсе wan , затем добавьте определенные правила, чтобы разрешить исходящий трафик через интерфейс wan серверам и портам, которые нужны маршрутизатору (dhcp, OpenVPN) до появления vpn. В этих правилах вы будете иметь option output ALLOW и option dest wan но не будете устанавливать src .

Либо продолжайте разрешать исходящий трафик в зоне и создавайте правила, которые блокируют HTTP-трафик в wan. Опять же, не устанавливайте src .

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .