Chegar a un servizo de cliente VPN: túnel inverso ou DNAT

Incluso un portátil detrás do NAT do operador pode atender un compañeiro, sempre que o servidor VPN faga de punto de encontro. Dous mecanismos chegan alí: o cliente marca cara a fóra e pide ao servidor que manteña un porto de escoita, ou o servidor publica un porto e tradúceo dentro do túnel. Ambos resolven o mesmo problema de accesibilidade e compórtanse de forma distinta ante fallos, supervisión e rexistro. Tres condicións deciden cal encaixa na súa instalación.

Dúas formas, un punto de encontro

Na primeira forma o cliente abre unha sesión SSH cara a fóra e pide ao servidor que escoite nun porto escollido, reenviando cada conexión por esa sesión. No servidor non se reenvía nada e non ocorre ningunha tradución de paquetes, así que os únicos requisitos son unha conta SSH, un reenvío permitido e unha regra de cortalumes para o porto. O servizo queda ligado a loopback no cliente, que adoita ser o que se desexa.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

Na segunda forma o servidor é dono do porto público e reescribe cada conexión cara ao enderezo do túnel do cliente. Iso esixe o reenvío IP activado, unha tradución de destino á entrada e unha tradución de orixe á saída, e segue funcionando cando non existe ningunha sesión SSH. O porto pertence ao servidor e non a unha sesión, e esa é a propiedade que decide a maioría dos casos reais.

Ningunha das dúas formas é máis segura por construción. Ambas acaban expoñendo un porto de servizo a quen poida alcanzar o enderezo público do servidor, e ambas seguen dependendo da autenticación propia do servizo.

Condición un: debe o porto sobrevivir á sesión

Un reenvío inverso vive exactamente o que vive a sesión SSH que o creou. Cando cae a ligazón, o oínte desaparece e o compañeiro ve unha conexión rexeitada en lugar dun camiño lento. Supervisar o comando cunha unidade de systemd e unha política de reinicio arranxa iso, e ExitOnForwardFailure=yes fai visible de inmediato unha vinculación fallida en vez de deixar unha sesión que funciona sen reenvío.

Un porto traducido sobrevive aos reinicios se as regras se conservan, pero depende de que o cliente manteña o mesmo enderezo de túnel. Un grupo dinámico que dá ao portátil outro enderezo tras reconectar apunta a regra en silencio á nada. Reserve primeiro o enderezo do túnel, logo escriba a regra e trate ambas as cousas como un só cambio.

Se o servizo ten que responder ás tres da madrugada sen ninguén mirando, a forma co porto publicado polo servidor ten menos pezas móbiles, porque o único proceso que debe seguir en pé é o túnel mesmo.

Condición dous: quen é dono da cortalumes e dos rexistros

A forma inversa mantén toda a política en dous lugares. sshd decide se os reenvíos remotos están permitidos en absoluto mediante AllowTcpForwarding, e GatewayPorts decide se o oínte se liga a loopback ou a todos os enderezos. Co valor predeterminado no un compañeiro fóra do servidor non pode alcanzar o porto aínda que o reenvío tivese éxito, e iso parece un túnel roto cando en realidade é un enderezo de vinculación.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

A forma traducida necesita o reenvío activado e dúas regras, e a segunda regra é onde fallan a maioría das receitas. Limitar a tradución de orixe ao estado de conntrack DNAT significa que só se reescriben as conexións que creou a regra de destino, en lugar de cada paquete que o servidor envía ao túnel.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

Esa reescritura tamén destrúe a atribución. Despois, o cliente ve a cada chamante como o enderezo do túnel do servidor, o que colapsa calquera límite de taxa por enderezo nun só cubo e oculta quen enviou que. Se a atribución importa, termine a conexión no servidor ou manteña alí a decisión de permiso e pase unha identidade nunha cabeceira na que o servizo confíe. Escoller entre esas dúas correccións depende de se o servizo le algunha cabeceira de proxy.

Condición tres: un porto ou moitos, e quen é dono do nome

Un só servizo nun só porto é o caso no que o reenvío inverso gaña en esforzo. Necesita un comando, unha conta e unha regra de cortalumes, e a limpeza é matar a sesión. Varios servizos no mesmo enderezo público empúxano cara á forma publicada polo servidor, porque cada reenvío inverso necesita o seu propio porto de servidor e o conxunto medra con cada servizo.

Os nomes complícao máis. Un reenvío inverso pode estar detrás dun proxy TCP que encamiña por SNI, mentres que un porto traducido adoita ser un porto por servizo. Se o servizo termina TLS por si mesmo e necesita o nome de host orixinal, o enfoque de proxy consérvao e o enfoque DNAT só o conserva se o servizo acepta ese nome nese porto.

Anote cal das tres condicións decidiu a forma. Se non, a seguinte persoa que engada un segundo servizo reabrirá a mesma comparación con menos contexto.

Decida e despois probe desde fóra

Probe a ruta desde unha rede que non teña ningunha ruta cara ao portátil e observe os contadores do servidor mentres se executa a petición. Probar desde o servidor cara ao seu propio enderezo público non demostra nada aquí, porque o paquete créase localmente e nunca chega ao gancho de tradución de entrada, así que a proba pode pasar mentres a ruta real está rota.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Os contadores que quedan planos significan que o paquete nunca chegou á regra, o que apunta ao provedor ou á cortalumes do host. Os contadores que se moven mentres o servizo rexeita apuntan á cortalumes propia do cliente ou ao enderezo no que escoita o servizo. Un túnel que transporta o paquete pero non devolve nada é un problema de ruta ou de camiño inverso, e ningún destes tres resultados debería depurarse editando o adaptador do cliente. Anote que contador se moveu antes de cambiar nada, porque a seguinte proba necesita esa liña base.

Cando a forma funcione, anote o porto, o propietario e o método de supervisión xunto á configuración do túnel. Unha corrección de accesibilidade que só existe no historial de shell de alguén está a un reinicio dun incidente repetido.