Router VPN: LAN e WAN, o que registar antes de comprar
Um rótulo VPN não diz nada sobre VLAN, comutação por falha de WAN ou papéis de túnel. Registe as capacidades exatas do modelo e do firmware que pretende implementar.
Trate o rótulo de pronto para VPN como uma função entre outras de um equipamento que também tem de encaminhar, segmentar e comutar em caso de falha, porque o rótulo não diz nada sobre quantas redes separadas o aparelho pode alojar. Comece por escrever um registo de capacidades para o modelo e o firmware exatos e depois compare esse registo com os fluxos de que o local precisa. As páginas de marketing enumeram tomadas; raramente enumeram pertença a VLAN, política de comutação por falha ou âmbito do túnel. O registo leva cerca de vinte minutos e resolve a maioria das discussões de compra antes de o hardware chegar.
Fixe o equipamento exato antes de tudo o resto
Os nomes de modelo viajam entre gerações de firmware, e a mesma caixa pode ser fornecida com um controlador de comutador diferente conforme a versão. Leia a identidade da placa no próprio aparelho e não na caixa, para que cada afirmação posterior fique ligada a algo que pode reproduzir. Um só comando cobre modelo, nome da placa e versão de firmware no OpenWrt, e os ecrãs equivalentes existem na maioria dos firmwares empresariais.
ssh [email protected] 'ubus call system board'
cat /etc/openwrt_release
Escreva essas cadeias no registo, nunca abreviadas. Depois separe a tarefa de encaminhamento comum da tarefa do túnel. Um aparelho que reencaminha bem os pacotes pode ainda recusar terminar um túnel, e um aparelho que termina um túnel pode não ter forma de manter duas redes locais separadas. Tratar ambos como um único requisito esconde o desajuste até a unidade já estar montada no rack, configurada e meio confiável.
Registe a estrutura da LAN, não o número de portas
Quatro tomadas costumam significar um só comutador, e um comutador significa um só domínio de difusão a menos que sejam configuradas VLAN. Isso serve para uma rede doméstica plana e é errado para um local que quer um segmento de convidados, um segmento de gestão e um segmento de câmaras isolado no mesmo equipamento. Registe que portas pertencem a que VLAN, que VLAN chegam à CPU e que interfaces transportam endereços.
Onde o firmware oferece VLAN, a lista de interfaces decide quantas políticas distintas pode escrever. Uma VLAN definida no comutador mas nunca atribuída como interface não tem endereço nem zona de firewall, por isso não consegue impor nada sozinha.
| Field to record | Example entry | Review stops if |
|---|---|---|
| Ports and VLAN membership | ports 1-4 untagged on VLAN 10, port 5 trunk with VLAN 10 and 20 | the datasheet offers only a socket count |
| Routed interfaces | br-lan 192.168.88.1/24, vlan20 192.168.99.1/24 | two subnets cannot hold separate policies |
| WAN method and failover | DHCP on wan, PPPoE on wan2, policy route to wan2 on loss | only one uplink is configurable |
| Tunnel role and scope | WireGuard peer on the router, only 192.168.88.0/24 routed inside | the router can only pass another tunnel through |
Leia o estado do comutador em vez de confiar no menu. Em alvos OpenWrt mais antigos a ferramenta de comutador imprime os dispositivos configurados, e em alvos DSA as ferramentas de ponte relatam os mesmos factos por porta, e por isso a versão de firmware pertence ao registo.
Registe o comportamento da WAN e da comutação por falha
Método de acesso, propriedade do endereço e ordem de comutação por falha pertencem a uma linha por ligação ascendente, porque um túnel que sobrevive a uma mudança de WAN depende das três. Uma sessão PPPoE volta a ligar-se com um endereço novo e derruba o túnel com ele, enquanto uma ligação ascendente DHCP que mantém a concessão pode não o fazer.
A comutação por falha também exige uma decisão de política. Enviar todo o tráfego para a ligação de reserva é fácil; manter o túnel na principal enquanto o tráfego web comum usa a de reserva exige encaminhamento por políticas, e não todos os firmwares o expõem. Registe se o túnel está preso a uma única ligação ascendente e o que o aparelho faz às sessões estabelecidas quando essa ligação desaparece. Guarde a tabela de encaminhamento como prova, não a caixa de comutação por falha.
Teste um fluxo permitido e um fluxo negado
O registo só vale a pena se o aparelho puder ser aceite contra ele. Escolha um fluxo que tem de funcionar, um que não pode, e execute ambos a partir de um cliente no segmento em questão. Um túnel que transporta todas as sub-redes é uma falha quando o requisito era uma só sub-rede.
Depois confirme a negação, pois um padrão permissivo é a surpresa habitual. O segmento de convidados não deve alcançar o endereço de gestão, e a verificação deve mostrar um tempo limite ou recusa em vez de uma página de início de sessão.
curl -sS --max-time 8 https://api.ipify.org
ping -c 2 192.168.99.1
ip -4 route get 192.168.99.1
Se o fluxo permitido funcionar e o negado também, falta a segmentação ainda que os menus sugerissem o contrário. Se ambos falharem, o âmbito do túnel ou o caminho de retorno estão errados, e o registo da WAN costuma explicar qual. Guarde os dois resultados com o registo de capacidades para que o próximo revisor veja o que foi aceite, em que firmware e em que data.