Os portátiles detrás dun router doméstico sen redirección de portos seguen aceptando conexións SSH que chegan pola VPN. Non é unha contradición, porque dous dispositivos distintos xulgan dous paquetes distintos. O router reenvía o transporte cifrado e o host decide que facer co paquete descifrado que chega á súa interface de túnel. Manter esas dúas decisións separadas é todo o exercicio.

O router reenvía o túnel, o host xulga o paquete

Debuxa o camiño desde a orixe remota ata o servizo antes de mirar unha soa regra. O tramo exterior é o transporte VPN, que manexan o router e a pasarela. O tramo interior comeza cando o extremo quita a capa do túnel e o host recibe un paquete dirixido ao seu enderezo VPN.

Xunta eses dous tramos e o router leva o mérito dunha decisión que toma o host. Unha páxina de redirección de portos ou un rexistro do router describen só conversas exteriores, e ningún di que tráfico descifrado aceptará o host. O host aplica a súa propia política de entrada ao paquete interior, igual que a calquera paquete que chegue a unha interface. Nesa política é onde se dirime realmente a cuestión da exposición.

Un escoitante comodín non é un servizo público

En Linux, vincularse a INADDR_ANY significa todo enderezo local, así que un servizo pode responder nunha interface de túnel que nunca nomeou. A referencia de sockets IP describe esa vinculación, e paga a pena lela antes de sacar conclusións dunha lista de escoitantes. Unha entrada comodín é un feito sobre o socket, non unha afirmación sobre a alcanzabilidade.

As dúas liñas de abaixo son o mesmo servizo en dúas vinculacións distintas, e a diferenza é toda a resposta a se a interface importa. Le en que enderezo se asenta o socket antes que nada.

ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))

Nomea a disposición que podería alcanzar o porto

Tres disposicións poñen un paquete nesa interface, e teñen donos distintos. Nomear a correcta decide quen debe cambiar unha política.

ArrangementWhat reaches the portWhere the decision lives
Another permitted VPN peerA packet from the same tunnel subnetGateway forwarding policy and host input rules
A deliberate public forwardTraffic the gateway publishes on purposeGateway service definition
A subnet routed behind the gatewayClient traffic from the far sideGateway route and host input rules

Un resultado do navegador que mostra un enderezo de saída público non di nada de ningunha das tres, porque describe como sae o tráfico de saída e non que se permite ao tráfico de entrada. Traballa cara atrás desde o escoitante e o enderezo de orixe no rexistro do servizo. Se a orixe é outro par do túnel, a política da pasarela é o documento interesante. Se é un enderezo traducido, atopa a tradución antes de cambiar unha regra.

Limita o servizo ao camiño que pretendías

Se SSH só se necesita desde un camiño de xestión, escribe ese camiño como un rango de orixe máis unha interface. Despois limita as regras de entrada do host por interface, destino e orixe en lugar de por nome de rede, xa que un nome que parece privado pode representar calquera enderezo. Deixa unha ruta para a persoa que arranxará o próximo problema.

nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input

Unha regra que nomea a interface do túnel e o rango de xestión declara a intención nun só lugar. Compáraa cunha regra escrita para a rede Wi-Fi, que non di nada do tráfico descifrado do túnel. Cando as dúas capas non coinciden, a política do host é a que atopa o paquete.

Deixa os inicios de sesión e os parches exactamente onde están; alcanzar un porto nunca foi o mesmo que ter permiso para usalo. Anota a familia de enderezos e a hora de calquera orixe descoñecida, e investiga antes de culpar unha función ou unha vulnerabilidade. Unha regra que admite cada par do túnel é un deseño distinto dunha que admite unha subrede de xestión, e ningunha liña de rexistro dirá cal se pretendía.

Acepta a corrección cun éxito e un rexeitamento

Proba as dúas metades: unha conexión aprobada ten éxito e un camiño excluído é rexeitado. O rexeitamento é a metade que a xente salta, e é a que mostra que a regra traballa en lugar de estar xunto a un valor por defecto permisivo. Proba desde o lado excluído en lugar de razoar sobre iso.

Repite o par tras unha reconexión, porque un túnel que volve cun nome de interface distinto pode saltar en silencio unha regra limitada ao antigo. A fronteira que importa é a que o host aplica aos paquetes que realmente recibe.

Artigos relacionados