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 recordExample entryReview stops if
Ports and VLAN membershipports 1-4 untagged on VLAN 10, port 5 trunk with VLAN 10 and 20the datasheet offers only a socket count
Routed interfacesbr-lan 192.168.88.1/24, vlan20 192.168.99.1/24two subnets cannot hold separate policies
WAN method and failoverDHCP on wan, PPPoE on wan2, policy route to wan2 on lossonly one uplink is configurable
Tunnel role and scopeWireGuard peer on the router, only 192.168.88.0/24 routed insidethe 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.

Artigos relacionados