Chegar á páxina de administración do router por VPN, non pola WAN

A páxina de administración do router ábrese en dous segundos desde o sofá e caduca desde unha habitación de hotel, mentres o cliente VPN informa de que está conectado todo o tempo. O que tes é unha vía de saída, non unha vía de volta: o túnel leva o teu tráfico a internet e detense aí. Para chegar a un dispositivo dentro da túa propia LAN cómpre unha sesión que remate en algo cunha ruta cara a ela. Iso é unha decisión de deseño, non un axuste, e determina se o resto do traballo é posible sequera.

A distinción pérdese facilmente porque un só produto pode facer ambas as tarefas. Un cliente de saída comercial e un servidor de acceso remoto poden falar o mesmo protocolo no mesmo porto, e a diferenza é que lado posúe o espazo de enderezos detrás do extremo.

Que lado do túnel posúe a LAN

Para administrar, o extremo ten que estar dentro da rede á que queres chegar, ou ter unha ruta autorizada cara a ela. Un router que executa o seu propio servidor VPN cumpre o requisito; tamén un equipo pequeno sempre aceso con enderezo fixo e unha ruta cara á LAN. Un servizo de saída operado por un terceiro non o cumpre, porque o seu extremo non ten interface na túa LAN nin regra algunha que permitise que aparecese unha. Esa é a comprobación que hai que rematar antes de tocar calquera outra cousa.

O firmware raramente etiqueta esa diferenza, así que le o que fai a función e non que protocolo nomea. WireGuard, OpenVPN e IKEv2 aparecen en ambos os lados do mercado: unha compilación envía o tráfico doméstico cara a fóra, outra acepta o teu dispositivo remoto. Unha compilación só de cliente non se pode converter en servidor por configuración, por moito que se reformule o menú.

Facer que exista a ruta de volta

Un servidor WireGuard no router ten un enderezo de interface como 10.8.0.1/24 e unha entrada de par para o portátil. O cliente decide que destinos enviará ao túnel, e unha lista que só contén a subrede do túnel deixa a LAN invisible, estea como estea configurado o servidor. Ambos os extremos teñen que poñerse de acordo, e normalmente só se edita un deles.

wg show wg0 allowed-ips
ip route get 192.168.1.1

O primeiro comando informa do que cada par pode enviar desde o punto de vista do servidor; o segundo informa de onde iría realmente un enderezo da LAN no cliente. Un destino da LAN que se resolve cara á interface do túnel é encamiñamento que funciona, e o que sae pola pasarela física nunca chegará, diga o que diga a devasa. Engade o prefixo da LAN á lista permitida do cliente e os mesmos dous comandos convértense nun paso de verificación en lugar dun diagnóstico.

O mesmo salto para as pasarelas IPsec descríbeo a documentación de reenvío de strongSwan, onde o reenvío e unha regra de NAT de orixe son o que conecta un cliente de túnel cun equipo interno. O direccionamento cambia; o requisito non.

Quen pode abrir a páxina de administración

O control de acceso pertence ao router, non á intención de ser coidadoso. Permite só a identidade de túnel autenticada ou o rango de orixe que necesita a páxina, e le a propia cadea de entrada do router así como calquera política de LAN reenviada. Unha regra que deixa que a LAN con cable chegue á páxina de administración non di nada sobre un cliente que chega pola interface do túnel. Escribe a excepción para unha identidade concreta e despois mantén unha segunda identidade que deba rexeitarse.

O oínte é a outra metade e é invisible na saída da devasa. ss -ltnp mostra o enderezo ao que está ligado o servidor web, e un servizo ligado só ao enderezo da LAN non responderá no enderezo do túnel, por permisivas que sexan as regras. Volver ligalo ou engadir un enderezo é un cambio de configuración no router, non un cambio de devasa.

Mantén a autenticación e a validación do transporte activadas na mesma pasada. Chegar non é confiar, e cada dispositivo dentro dun túnel non se converte por iso en administrador. A credencial do túnel e a conta do router son privilexios separados con ciclos de vida separados, así que a clave dun portátil perdido pode revogarse sen restablecer o contrasinal de cada administrador.

Probar desde fóra, non desde o sofá

Proba desde unha rede que non controles. Conéctate polo túnel aprobado, abre unha sesión de administración nova e cambia algo inofensivo que vexas reflectido na páxina. Desde o sofá demostras que a LAN funciona, algo que nunca estivo en dúbida.

Despois proba os rexeitamentos co mesmo coidado. Tenta abrir a páxina sen o túnel e confirma que falla, e confirma que o servizo de administración non escoita en absoluto no enderezo WAN. Unha páxina que só non está ligada non é control de acceso, e un oínte na WAN que mostra un formulario de acceso segue a ser un oínte na WAN. Se un contrasinal é o único entre internet e a consola do router, o deseño é un contrasinal.

Os servizos da casa merecen unha ollada mentres estás alí. Endurecer as regras de xestión a miúdo rompe a rede de convidados ou o resolutor que usan os dispositivos da familia, e iso aparece días despois como unha queixa non relacionada.

Manter unha vía de volta mentres cambias cousas

Antes de cambiar rutas ou axustes do túnel en remoto, prepara unha vía de volta independente. Unha sesión existente pode sobrevivir ao cambio que xa bloquea conexións novas, e é exactamente así como a xente se deixa fóra mentres mira unha sesión que aínda funciona. As opcións son concretas: un reinicio programado a unha configuración coñecida, acceso por consola ou físico, un segundo túnel que non dependa do axuste que se está editando, ou xestión fóra de banda onde o hardware a ofreza. Escolle unha e demóstraa antes da xanela de mantemento, non durante.

Mantén o rexistro curto e actual: que equipo termina o túnel, que identidades poden chegar á páxina, a que enderezo se liga o servizo e como se revoga un dispositivo perdido. Esa lista fai tamén de plan de recuperación, porque di onde vive cada dependencia. Unha ruta de volta ausente é un problema de encamiñamento que hai que reparar, e nunca é motivo para publicar a administración na WAN.