DD-WRT - Redirecionando o tráfego da Internet com base na sub-rede de origem

0

A pergunta a seguir tem uma descrição longa. Espero que alguém em posição semelhante ache útil. Por favor, seja paciente. Meu problema é no final.

Primeiro de tudo, tenho a seguinte configuração em casa:

--MODEM (ADSL) - ISP INTERNET : 192.168.0.1
  |
  -- WIRELESS ROUTER (DDWRT) : 192.168.1.1

Eu tenho um serviço VPN L2TP que eu preciso usar o tempo necessário para acessar a internet. Como o DD-WRT não suporta L2TP como um cliente VPN, acabei configurando-o como a conexão WAN principal. Funciona como esperado e meu tráfego passa pela conexão VPN de todos os clientes sem fio e portas Ethernet. Exatamente o que eu quero.

Agora,emalgunscasosraros,nãoquerousaraconexãoVPN.Talcomoquandocai.AtéagoraeutinhaqueiraopaineldecontroledoroteadoredefinirasconfiguraçõesdeWANpara"DHCP" para obter acesso direto à Internet. Então, novamente, quando a VPN se tornar on-line, reverta as configurações de volta.

Eu achei isso difícil (especialmente porque ninguém mais sabe como fazer isso) e então eu decidi criar uma interface Virtual Wireless que usa o endereço IP do modem como gateway e como resultado qualquer dispositivo conectado a ele obtém o link direto à internet. Então, criei uma interface sem fio virtual e a adicionei a uma nova ponte, depois configurei o DHCP para atribuir a qualquer cliente conectado a ele um IP no espaço IP 192.168.3.x. As capturas de tela a seguir ajudam você a entender a configuração:

Atéagoratudofuncionacomoesperado.Agoraeutivequeencontrarumamaneiradeenviarotráfegodestasub-rede(192.168.3.x)para192.168.0.1queéomodemADSLecomoresultadoignoraraconexãoPPPdoroteador.

UsandomeuconhecimentolimitadodetabelasdeIPealgumaajudadaInternet,euescrevioseguintescript:

ipruleaddfrom192.168.3.0/24table200iprouteadddefaultvia192.168.0.1devvlan2table200iprouteflushcache

IPTablecontémasseguintesregrasantesdaexecuçãodoscomandosacima:

root@router:~#iproutedefaultvia192.168.100.198devppp0scopelink50.105.xxx.xxxvia192.168.0.1devvlan2127.0.0.0/8devloscopelink169.254.0.0/16devbr0protokernelscopelinksrc169.254.255.1192.168.0.0/24devvlan2protokernelscopelinksrc192.168.0.100192.168.1.0/24devbr0protokernelscopelinksrc192.168.1.1192.168.1.1via192.168.0.1devvlan2192.168.3.0/24devbr1protokernelscopelinksrc192.168.3.1192.168.100.198devppp0scopelink

Apósaexecuçãonatabela200:

root@router:~#iproutelisttable200defaultvia192.168.0.1devvlan2

Comovocêpodever,oscomandosacimafuncionambem,maseutenhodoisproblemas:

  1. Nãoconsigoencontrarumamaneiraconfiáveldeexecutá-loacadareinicialização

  2. AconexãoVPNnãoseconectaránovamenteapósumadesconexão.Naverdade,depoisdeumdesconexão,qualquercliente,excetoaquelescomoendereçoIP192.168.3.x,perderamoacessoàInternet.

VejaasregrasdatabelaIPdepoisdedesconectar:

root@router:~#iproutelisttable200defaultvia192.168.0.1devvlan2root@router:~#iproute127.0.0.0/8devloscopelink169.254.0.0/16devbr0protokernelscopelinksrc169.254.255.1192.168.0.0/24devvlan2protokernelscopelinksrc192.168.0.100192.168.1.0/24devbr0protokernelscopelinksrc192.168.1.1192.168.1.1via192.168.0.1devvlan2192.168.3.0/24devbr1protokernelscopelinksrc192.168.3.1

combasenoresultadoacimaeuachoqueéporcausadenãoterumaregrapadrão,masporqueecomopossoresolvê-lo?Éimportantesaberque,semexecutarmeuscomandospersonalizados,tudofuncionarianormalmente.

Oqueeujátentei:

  1. Scriptdeinicialização:

Euuseiocomandoabaixoparacriarumscriptparaserexecutadonowanseconecta.nãotevenenhumsucesso.

mkdir-p'/tmp/etc/config/'echo"ip rule add from 192.168.3.0/24 table 200
ip route add default via 192.168.0.1 dev vlan2 table 200
ip route flush cache" > '/tmp/etc/config/direct.wanup'
chmod +x '/tmp/etc/config/direct.wanup'

Alguém pode ajudar?

    
por Soroush Falahati 27.06.2016 / 03:05

1 resposta

0

A adição das seguintes regras ao script Firewall solucionou completamente o meu problema:

ip route add default via 192.168.0.1 dev vlan2
ip route delete 8.8.8.8 via 192.168.0.1 dev vlan2
ip rule add from 192.168.3.0/24 table 200
ip route add default via 192.168.0.1 dev vlan2 table 200
ip route flush cache

    
por 27.06.2016 / 14:40