Prefixos públicos por OpenVPN: arranxar o camiño de volta

Observe como sobe o túnel e o cliente fai ping ao outro lado, e despois un enderezo público que pertence detrás da VPN responde desde outro lugar, ou non responde. Ese síntoma normalmente non ten nada que ver co cifrado nin cos certificados. Un prefixo encamiñado polo provedor entrégase como unha ruta IP, e levalo por OpenVPN significa reproducir esa ruta en dous niveis e preservar o enderezo de orixe no camiño de volta. Non fai falta facer ponte da WAN, e engadir o enderezo a unha interface non crea a ruta ascendente.

O prefixo primeiro ten que encamiñarse cara a vostede

Pregunte ao provedor como se entrega o bloque. Un prefixo encamiñado ao enderezo principal do seu servidor é algo distinto dos enderezos que o provedor espera alcanzar directamente nun segmento WAN. Só o primeiro modelo funciona co deseño de aquí.

Se o provedor encamiña 198.51.100.64/28 ao seu servidor de entrada, os paquetes dese rango chegan ao servidor e detéñense alí a menos que os reenvíe. Se o provedor, en cambio, fai ponte do rango cara á súa ligazón ascendente, o servidor debe responder ARP por el, que é outro problema.

Probe o modelo de entrega antes de tocar OpenVPN: desde fóra, faga ping a un enderezo do bloque e observe que interface o recibe. Se non chega nada, ningunha configuración do túnel axudará. Se o enderezo responde directamente na WAN, o provedor está a facer ponte en lugar de encamiñar, e o deseño de abaixo non se aplica.

Dous niveis de encamiñamento: ruta do núcleo e iroute

OpenVPN necesita o prefixo en dous sitios. O núcleo debe saber que o prefixo pertence ao dispositivo do túnel, para que os paquetes reenviados entren en OpenVPN en lugar da ruta por defecto. OpenVPN tamén debe saber que cliente autenticado posúe o prefixo, que é a entrada iroute no directorio específico do cliente.

A ruta do lado do servidor ten este aspecto, co prefixo e a máscara coincidindo coa asignación:

ip route add 198.51.100.64/28 dev tun0

A configuración específica do cliente asigna a propiedade. Póña no ficheiro CCD nomeado segundo o nome común do certificado do cliente, e confirme que ese directorio é o que o servidor le realmente:

iroute 198.51.100.64 255.255.255.240

A documentación de OpenVPN sobre redes encamiñadas describe ambos os niveis e por que están separados. Unha ruta do núcleo sen iroute envía paquetes ao túnel sen propietario, e OpenVPN descártaos. Un iroute sen a ruta do núcleo deixa os paquetes na ruta por defecto do servidor. Ambos os erros parecen un túnel roto desde o lado do cliente.

Onde vive o enderezo do servizo

O prefixo delegado non é o mesmo que os enderezos propios do túnel. Numere a ligazón desde o espazo privado se quere, e coloque o enderezo público do servizo onde o servizo se executa realmente.

Nun cliente Linux que termina o servizo localmente, abonda un enderezo de host individual:

ip address add 198.51.100.70/32 dev lo

Se o prefixo se encamiña cara a un host VM ou outra LAN, configure no seu lugar ese camiño descendente e a súa ruta de volta. Asignar cada enderezo do bloque ao cliente VPN non é necesario e crea conflitos despois.

Manteña a orixe pública no camiño de volta

Unha resposta do prefixo delegado debe saír polo túnel e chegar á ruta do provedor. Se o host remoto a envía polo seu propio ISP, o enderezo de orixe parece falsificado, e o provedor ou o destino descártaa. A solución é unha regra baseada na orixe ou unha táboa de encamiñamento dedicada, non un NAT máis amplo. Sen ela, o servizo funciona desde o par do túnel e falla desde calquera outro sitio.

No servidor de entrada, unha regra de masquerade ampla é o culpable habitual. Reescribe a orixe pública ao enderezo principal do servidor, e o cliente nunca ve a real:

iptables -t nat -S POSTROUTING

Limite o NAT aos clientes VPN privados que o necesitan e deixe o prefixo delegado sen traducir. Logo confirme que o servidor reenvía o prefixo, porque unha cadea de reenvío con denegación por defecto descártao en silencio.

Verifique as dúas direccións antes de confiar nel

A verificación son catro observacións, non unha. Confirme que chega a ruta do provedor, que o núcleo envía o prefixo ao túnel, que OpenVPN o atribúe ao cliente correcto e que a resposta volve coa orixe pública intacta. Cada observación ten o seu propio comando, así que un fallo apunta a unha capa e non a todo o deseño. Execúteas nesa orde despois de cada cambio de configuración.

Pregunte ao núcleo que camiño toma un enderezo delegado, e observe o túnel mentres se executa unha petición:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

O filtrado de ruta inversa pode desfacer unha ruta correcta. Comprobe o axuste efectivo no túnel e na ligazón ascendente, e lembre que o modo estrito rexeita o tráfico cuxa orixe non coincide coa interface pola que chegou:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Por último, probe o caso de fallo. Deteña o túnel e confirme que o prefixo público non se filtra pola ligazón ascendente ordinaria. Restaurar a VPN debería devolver o servizo sen ampliar que portos expón o host.