Per què una regla de port d'origen trenca un dels teus camins SSH

Dues entrades de gestió en un sol amfitrió, un sol port de servei i una regla de política que havia d'ajudar totes dues. La regla coincideix amb el port d'origen 22, envia la consulta a una taula que només coneix el valor per defecte de WAN, i l'entrada VPN deixa de respondre a inicis de sessió nous mentre l'entrada directa continua funcionant. Res d'això no és misteriós un cop el selector es llegeix correctament. Un port d'origen identifica un servei, no el camí pel qual va arribar una connexió.

Dues entrades, un sol port de servei

L'amfitrió té una adreça de la banda LAN i una adreça VPN, i sshd escolta a totes dues. Per tant, una sessió directa i una sessió tunelitzada comparteixen el port de servei i només difereixen en quina adreça local rep la connexió.

Aquesta diferència n'hi ha prou per triar un camí de resposta, i és exactament la diferència que una regla basada en el port descarta. Totes dues sessions produeixen respostes amb port d'origen 22, així que una regla que coincideixi amb aquest port no les pot separar. Envia totes dues consultes a la mateixa taula, i una d'elles rep una resposta que no encaixa. La solució és fer coincidir l'atribut que realment difereix.

Donar a cada entrada el seu propi port també funcionaria, i tractar-ho com un requisit és una decisió de disseny, no una propietat d'SSH.

Llegeix la regla, després la taula

Una regla de política és un selector ordenat, i la primera que retorna una resposta utilitzable acaba la consulta. Llegeix la llista en ordre i fixa't en quina regla pot guanyar.

Després llegeix la taula a què apunta aquesta regla, perquè una regla que es resol correctament no és una regla que es resolgui de manera útil. Una taula que només conté una ruta per defecte envia la resposta amb origen VPN per la interfície WAN. Una ruta més específica en una taula posterior no es consulta mai, i per això afegir una segona taula sovint no canvia res. La taula seleccionada és el que cal inspeccionar.

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

Aquestes dues sortides juntes expliquen el resultat; qualsevol d'elles sola convida a una conclusió errònia.

Limita la regla al flux que vols dir

L'atribut que separa les dues entrades és l'adreça d'origen local. Una regla que coincideix amb aquesta adreça envia només les sessions tunelitzades a la taula privada i deixa les sessions directes a la taula principal.

Aquesta regla s'ha d'emparellar amb una taula que contingui la ruta privada i el camí de retorn per a aquesta subxarxa. Limita totes dues al trànsit de gestió en lloc de a cada servei de l'amfitrió. Una regla que atrapa tot el trànsit d'aquella adreça també redirigirà qualsevol altra cosa que l'amfitrió hi enviï. L'estret guanya a l'intel·ligent aquí, perquè la propera persona l'ha de llegir.

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

Si les dues entrades es tradueixen a una sola adreça local, aquesta distinció desapareix i el disseny necessita estat conscient de la connexió en lloc d'això.

Mantén separats el receptor, el permís i la selecció de resposta

Tres coses separades han de ser certes abans que una sessió funcioni: l'adreça existeix, el servei hi escolta i la resposta troba el camí de tornada. Un canvi de ruta només arregla la tercera.

La configuració del receptor és el seu propi fitxer i la seva pròpia recàrrega, i diverses adreces d'escolta són normals. L'autenticació és una tercera decisió una altra vegada, i una excepció d'encaminament no dona accés a ningú. Mantén la verificació de la clau de l'amfitrió, l'autenticació del compte i les restriccions d'origen a les dues entrades, i resisteix l'impuls d'afeblir els altres controls del túnel perquè un sol camí de gestió funcioni.

Mantén un canal de recuperació que no depengui del camí que estàs canviant, perquè un error aquí bloqueja la mateixa solució.

Demostra-ho amb una sessió nova, no amb una d'antiga

Un terminal establert no demostra res, perquè va ser admès abans del canvi. Obre una sessió 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

Després repeteix la reconnexió de VPN i torna-ho a provar, perquè una ruta que sobreviu a una reconnexió no és el mateix que una d'afegida a una taula que la reconnexió buida. Observa les fonts denegades per separat de les permeses, perquè un intent bloquejat no s'amagui darrere d'una sessió que funciona. Desa l'adreça local, la regla i la taula al costat del resultat. Si en canvi divideixes els ports, registra-ho com una decisió operativa i no com un límit d'SSH.