O interruptor de corte de UFW bloquea a túa VPN? Permitir o par

Seguiches a lista de comprobación: denegar a saída, permitir o túnel, activar ufw. Logo o cliente espera no handshake e nunca conecta, ou conecta e non se carga ningunha páxina. Ambos fallos veñen do mesmo oco. Falta a regra que deixa existir o túnel, porque o túnel non é unha interface pola que saian os teus paquetes.

Por que un permiso en tun0 non coincide con nada ao principio

tun0 críao o cliente unha vez que existe unha sesión. Os datagramas que constrúen esa sesión son paquetes UDP correntes dirixidos ao provedor no porto 1194, e saen por wlan0 ou eth0 co enderezo de orixe física. allow out on tun0 só coincide co tráfico cuxa interface de saída é tun0, así que durante o handshake non coincide con nada.

Pon default deny outgoing encima e os paquetes exteriores descártanse antes de que a interface apareza sequera. O cliente reintenta, esgota o tempo de espera e informa dun fallo de TLS ou de handshake, o que manda a xente a buscar entre certificados e MTU mentres o cortafuegos come a conexión en silencio. A regra que debía conter o teu tráfico impide que ese tráfico se conteña.

O arranxo reflexo fai permanente a fuga. sudo ufw allow out on wlan0, ou devolver o valor por defecto a permitir, levanta o túnel e deixa a máquina sen interruptor de corte: a próxima vez que caia o túnel, todo retómase polo adaptador físico. Perdín unha tarde exactamente con ese par de edicións antes de descubrir que paquete estaba filtrando en realidade.

Que necesitan os dous conxuntos de paquetes

O teu tráfico cruza o cortafuegos dúas veces, en dúas formas. O paquete interior vai do enderezo do túnel cara a fóra por tun0. O paquete exterior vai do enderezo físico ao par, e é o único visible no cable. Unha regra por forma:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Substitúe o enderezo e o porto polos do teu propio perfil. Os pares de WireGuard adoitan responder en 51820/udp; os perfís de OpenVPN que van por TCP 443 necesitan ese porto no seu lugar. Os detalles cambian, a forma non: ambas regras son estreitas e xuntas definen os únicos destinos que a máquina pode alcanzar mentres o túnel está caído.

A orde é o segundo mito. Con iptables en bruto les a cadea de arriba a abaixo e razoas que regra gaña. ufw non é un envoltorio fino da lista que escribiches; compila as túas regras nas súas propias cadeas e escolle os puntos de inserción. ufw status imprímeas na orde de ufw, non na túa. Cando unha regra parece ignorada, compara ufw show added co conxunto compilado de iptables -S | grep ufw antes de reescribir nada.

A excepción ten que quedarse ancha dunha soa dirección

Unha regra de par só é correcta mentres nomea o enderezo ao que marca o cliente. Os provedores rotan puntos de conexión, e un perfil que resolve un nome de host seguirá un cambio de DNS cara a un enderezo novo mentres a regra segue apuntando ao vello. Cando un túnel que funcionou durante meses deixa de levantarse, compara o enderezo da regra co que busca o cliente antes de ampliar nada.

Ampliar a toda unha subrede, ou a cada destino no porto 1194, volve converter a política nun cortafuegos cun burato. A excepción é o interruptor de corte; unha vez que é amplo, non queda nada que cortar. Mantena nunha soa dirección e deixa un comentario que nomee o perfil e o provedor ao que pertence, porque dentro de seis meses o enderezo parecerá arbitrario.

A resolución de nomes merece a súa propia liña. A consulta ocorre antes de que exista o túnel, pola interface física, así que unha política estrita de denegación de saída pode deixar o cliente incapaz de atopar o seu propio servidor. Permite o porto 53 cara ao enderezo do teu resolvedor, ou resolve unha vez e fixa o enderezo no perfil. Permitir DNS en todas as interfaces é unha decisión, non un valor por defecto.

Constrúe a política antes de que faga falta o túnel

ufw enable aplica toda a política de golpe e recarga as súas cadeas, e cambiar unha política por defecto nun cortafuegos en marcha tamén as recarga. O manual de ufw advirte de que iso pode tirar conexións existentes como SSH. Por iso os comandos van nesta orde, coa regra SSH antes da activación e unha sesión de consola aberta:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset déixase fóra dese bloque a propósito. Borra todas as regras e desactiva o cortafuegos, e nun host remoto a activación seguinte é o que tira a túa sesión. Se fas o reset, engade a regra SSH e confirma unha segunda vía de volta por consola antes de seguir.

A secuencia non é cosmética. As regras engadidas mentres ufw corre non baleiran nada, pero no momento en que xiras unha política por defecto as cadeas recárganse, e unha sesión que a política antiga permitía vaise con elas. Fai os valores por defecto, os permisos e a activación nunha soa pasada, mentres aínda tes unha vía de entrada que non depende da máquina.

Proba o estado bloqueado e conserva a marcha atrás

Un interruptor de corte sen probar é unha suposición. Desconecta o cliente a propósito e intenta cargar unha páxina: debe fallar. Volve conectar e debe recuperarse sen tocar ningunha regra. sudo ufw status verbose confirma os valores por defecto e o estado do rexistro, e ufw status numbered mostra que regra de proba borrar cando sobreviva ao seu propósito.

Mantén o script inverso xunto ao directo. Unha máquina con denegación de saída e un túnel morto non pode descargar a súa propia reparación, así que a marcha atrás ten que estar no disco e ser lexible desde unha consola:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Execútao cando o túnel xa está caído e hai que quitar as regras, non como un paso rutineiro. Antes de pechar o terminal, catro cousas deben cumprirse: a regra do par nomea exactamente un enderezo, o DNS ten unha excepción nomeada, a activación chegou despois dos permisos, e tirar do túnel mata o tráfico normal sen matar o cliente para sempre.