Enderezo peer PPP ou extremo VPN: cal vai en via

Unha soa liña nunha interface PPP resolve a maior parte da discusión de encamiñamento nunha caixa VPN: o enderezo interno e o peer impreso ao seu carón. Le ese par como unha subrede minúscula e irás buscar unha pasarela que non existe. Léoo como os dous extremos dun único enlace e o seguinte salto tórnase obvio. A comparación aquí é entre esas dúas lecturas, porque cada táboa que constrúas despois herda a que escollas. Nada sobre o extremo VPN exterior o decide ningunha delas.

Dúas lecturas dunha mesma liña de interface

Toma unha sesión na que a interface informa inet 10.64.3.9 peer 10.64.3.1/32. A lectura de subrede trata 10.64.3.9 como un host solitario nunha illa /32 e despois busca un router para alcanzar calquera cousa máis aló. Como o único outro enderezo no enlace é o peer, esa lectura acaba propoñendo 10.64.3.9 como pasarela, o que é circular.

A lectura de extremo é a documentada. Nunha interface punto a punto, peer nomea o extremo remoto dese único enlace, así que 10.64.3.1 é o seguinte salto utilizábel e 10.64.3.9 é só un enderezo de orixe.

Esa diferenza goberna o que pode aparecer en via. Escribir alí o enderezo local produce unha ruta que o núcleo non pode resolver contra un veciño, así que a entrada falla a validación ou traga tráfico mentres se ve perfectamente san nunha listaxe. O peer funciona porque é un destino real no enlace. As dúas lecturas coinciden sobre o extremo VPN exterior, que é unha identidade completamente á parte: alcanzase polo underlay, non polo túnel que remata.

O que xa instalou a sesión

Antes de escribir calquera táboa propia, imprime o que veu co enlace. Unha integración PPP compatíbel adoita instalar unha ruta de dispositivo e unha ruta de peer durante a montaxe da sesión, e esas dúas entradas xa codifican a lectura correcta.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Unha ruta de dispositivo como 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 non leva pasarela porque a propia interface é o camiño. Unha ruta que nomea o peer con via é outro obxecto con outra vida útil, e desaparece cando cae a sesión. Copiar calquera das dúas formas nunha táboa persistente sen comprobar como se reinstala é o motivo habitual polo que un túnel que funcionaba perde a ruta tras unha reconexión.

Compara as dúas listaxes en lugar de confiar na memoria. Se a ruta do peer existe en main pero a túa táboa adicional está baleira, aprendiches algo que a liña de enderezo nunca che dixo.

Unha regra e unha táboa son decisións separadas

Seleccionar unha táboa e enchedala son pasos independentes, e a comparación importa aquí porque ambos se confunden a miúdo ao depurar. Unha regra que envía tráfico marcado á táboa 100 non fai nada se a táboa 100 non ten unha ruta coincidente, e unha táboa ben poboada é inalcanzábel se ningunha regra apunta a ela.

Media ruta por defecto non é unha ruta por defecto. Unha soa 0.0.0.0/1 cobre a metade inferior do espazo IPv4, así que unha política que pretende capturalo todo necesita tamén a 128.0.0.0/1 correspondente, ou unha default auténtica. Ler unha configuración que funciona e copiar unha das dúas metades é como a xente acaba cun lazo de encamiñamento que só se rompe en certos destinos.

Deixa excepcións deliberadas para os enderezos que deben ficar na LAN, e decide que ocorre cando a busca non atopa nada na táboa seleccionada. Unha ruta de reserva explícita é máis doada de razoar ca unha táboa baleira, que devolve un resultado inalcanzábel e fai que a aplicación pareza rota en vez de mal encamiñada.

Fai á busca a pregunta que fai a túa aplicación

ip route get resolve un camiño; ip route show lista as entradas almacenadas, e as dúas poden discordar sen que ningunha estea mal. Inclúe o contexto de orixe, porque as regras baseadas en orixe só coinciden cando a busca leva unha orixe.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

O primeiro comando fai a pregunta desde o host. O segundo engade unha interface de entrada, que está máis preto do que experimenta o tráfico reenviado, e a resposta adoita apuntar a outra táboa. Ningún dos destinos é un servizo de proba en vivo; 198.51.100.23 é un enderezo de documentación, así que substitúeo por un host que teñas permiso de sondar.

Incluso unha busca correcta só demostra que se escolleu un camiño. Non di nada sobre se o outro lado acepta o tráfico ou sobre se a resposta pode volver polo mesmo razoamento.

Onde se invirte a comparación

O tráfico do host e o tráfico reenviado non só toman buscas distintas; atópanse con filtros distintos á volta. Linux aplica a validación de ruta inversa usando o máis estrito dos axustes de todas as interfaces e da interface receptora, así que cambiar o valor dunha interface pode non ter efecto visíbel. O encamiñamento baseado en marcas engade a relación src_valid_mark, na que a marca debe coincidir para que unha orixe se considere válida.

Se as respostas desaparecen mentres o encamiñamento de saída parece correcto, le os valores efectivos antes de tocalos, e cámbiaos só cunha razón de política declarada.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Escolle entre os dous deseños con evidencia: se a aplicación se liga ao enderezo PPP, abonda unha regra de orixe máis unha táboa que conteña a ruta do peer. Se a caixa reenvía para unha LAN detrás, tamén necesitas que o contexto de entrada e o camiño de volta coincidan. Cando non coinciden, corrixe a propiedade da ruta en lugar de afrouxar a validación para toda a máquina.