Por que unha regra de porto de orixe rompe unha das túas rutas SSH

Dúas entradas de xestión nun mesmo host, un só porto de servizo e unha regra de política que debía axudar a ambas. A regra coincide co porto de orixe 22, envía a busca a unha táboa que só coñece o valor predeterminado de WAN, e a entrada VPN deixa de responder a novos inicios de sesión mentres a entrada directa segue funcionando. Nada diso é misterioso unha vez que o selector se le correctamente. Un porto de orixe identifica un servizo, non a ruta pola que chegou unha conexión.

Dúas entradas, un só porto de servizo

O host ten un enderezo do lado da LAN e un enderezo VPN, e sshd escoita en ambos. Por tanto, unha sesión directa e unha sesión tunelizada comparten o porto de servizo e só difiren en que enderezo local recibe a conexión.

Esa diferenza abonda para elixir unha ruta de resposta, e é exactamente a diferenza que unha regra baseada no porto descarta. Ambas as sesións producen respostas cuxo porto de orixe é 22, así que unha regra que coincida con ese porto non pode separalas. Envía ambas as buscas á mesma táboa, e unha delas recibe unha resposta que non encaixa. A solución é facer coincidir o atributo que realmente difire.

Dar a cada entrada o seu propio porto tamén funcionaría, e tratar iso como un requisito é unha decisión de deseño, non unha propiedade de SSH.

Le a regra e despois a táboa

Unha regra de política é un selector ordenado, e a primeira que devolve unha resposta utilizábel remata a busca. Le a lista en orde e fíxate en que regra pode gañar.

Despois le a táboa á que apunta esa regra, porque unha regra que se resolve con éxito non é unha regra que se resolva de forma útil. Unha táboa que só contén unha ruta predeterminada envía a resposta con orixe VPN pola interface WAN. Unha ruta máis específica nunha táboa posterior nunca se consulta, e por iso engadir unha segunda táboa tantas veces non cambia nada. A táboa seleccionada é o que hai que inspeccionar.

ip -4 rule show
ip route show table 100
ip route show table main

Esas dúas saídas xuntas explican o resultado; calquera delas por si soa invita a unha conclusión errónea.

Limita a regra ao fluxo que queres dicir

O atributo que separa as dúas entradas é o enderezo de orixe local. Unha regra que coincide con ese enderezo envía só as sesións tunelizadas á táboa privada e deixa as sesións directas na táboa principal.

Esa regra debe emparellarse cunha táboa que conteña a ruta privada e o camiño de retorno para esa subrede. Limita ambas ao tráfico de xestión en lugar de a cada servizo do host. Unha regra que captura todo o tráfico dese enderezo tamén redirixirá calquera outra cousa que o host envíe desde alí. O estreito vence o enxeñoso aquí, porque a seguinte persoa ten que lelo.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Se ambas as entradas se traducen a un só enderezo local, esa distinción desaparece e o deseño necesita estado consciente da conexión no seu lugar.

Mantén separados o receptor, o permiso e a selección de resposta

Tres cousas separadas deben ser certas antes de que unha sesión funcione: o enderezo existe, o servizo escoita nel e a resposta atopa o camiño de volta. Un cambio de ruta só arranxa a terceira.

A configuración do receptor é o seu propio ficheiro e a súa propia recarga, e varias direccións de escoita son normais. A autenticación é outra terceira decisión, e unha excepción de encamiñamento non dá acceso a ninguén. Mantén a verificación da chave do host, a autenticación da conta e as restricións de orixe en ambas as entradas, e resiste o impulso de debilitar os demais controis do túnel para que funcione un só camiño de xestión.

Mantén unha canle de recuperación que non dependa da ruta que estás a cambiar, porque un erro aquí bloquea a propia solución.

Demostrao cunha sesión nova, non cunha antiga

Un terminal establecido non demostra nada, xa que foi admitido antes do cambio. Abre unha sesión nova a través de cada entrada prevista.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Despois repite a reconexión de VPN e téntao de novo, porque unha ruta que sobrevive a unha reconexión non é o mesmo ca unha engadida a unha táboa que a reconexión baleira. Observa as fontes denegadas por separado das permitidas, para que un intento bloqueado non se esconda detrás dunha sesión que funciona. Garda o enderezo local, a regra e a táboa xunto ao resultado. Se en cambio divides os portos, rexístrao como unha decisión operativa e non como un límite de SSH.