Adreça peer PPP o extrem VPN: quina va a via

Una sola línia en una interfície PPP resol la major part del debat d’encaminament en una caixa VPN: l’adreça interna i el peer imprès al seu costat. Llegeix aquest parell com una subxarxa minúscula i buscaràs una porta d’enllaç que no existeix. Llegeix-lo com els dos extrems d’un únic enllaç i el següent salt es torna obvi. La comparació aquí és entre aquestes dues lectures, perquè cada taula que construeixis després hereta la que hagis triat. Res de l’extrem VPN exterior ho decideix cap de les dues.

Dues lectures d’una mateixa línia d’interfície

Pren una sessió en què la interfície informa inet 10.64.3.9 peer 10.64.3.1/32. La lectura de subxarxa tracta 10.64.3.9 com un amfitrió solitari en una illa /32 i després busca un encaminador per assolir qualsevol cosa més enllà. Com que l’única altra adreça de l’enllaç és el peer, aquesta lectura acaba proposant 10.64.3.9 com a porta d’enllaç, cosa que és circular.

La lectura d’extrem és la documentada. En una interfície punt a punt, peer anomena l’extrem remot d’aquest únic enllaç, així que 10.64.3.1 és el següent salt utilitzable i 10.64.3.9 només és una adreça d’origen.

Aquesta diferència governa què pot aparèixer a via. Escriure-hi l’adreça local produeix una ruta que el nucli no pot resoldre contra un veí, així que l’entrada falla la validació o empassa trànsit mentre es veu perfectament sana en un llistat. El peer funciona perquè és una destinació real a l’enllaç. Totes dues lectures coincideixen sobre l’extrem VPN exterior, que és una identitat completament a part: s’assoleix per l’underlay, no pel túnel que acaba.

Què ja ha instal·lat la sessió

Abans d’escriure cap taula pròpia, imprimeix què va venir amb l’enllaç. Una integració PPP compatible sol instal·lar una ruta de dispositiu i una ruta de peer durant el muntatge de la sessió, i aquestes dues entrades ja codifiquen la lectura correcta.

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

Una ruta de dispositiu com 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 no porta porta d’enllaç perquè la interfície mateixa és el camí. Una ruta que anomena el peer amb via és un altre objecte amb una altra vida útil, i desapareix quan cau la sessió. Copiar qualsevol de les dues formes en una taula persistent sense comprovar com es reinstal·la és la raó habitual per la qual un túnel que funcionava perd la ruta després d’una reconnexió.

Compara els dos llistats en lloc de refiar-te de la memòria. Si la ruta del peer existeix a main però la teva taula addicional és buida, has après una cosa que la línia d’adreça mai no et va dir.

Una regla i una taula són decisions separades

Seleccionar una taula i omplir-la són passos independents, i la comparació importa aquí perquè tots dos es confonen sovint en depurar. Una regla que envia trànsit marcat a la taula 100 no fa res si la taula 100 no té una ruta coincident, i una taula ben poblada és inabastable si cap regla no hi apunta.

Mitja ruta per defecte no és una ruta per defecte. Una sola 0.0.0.0/1 cobreix la meitat inferior de l’espai IPv4, així que una política que pretén capturar-ho tot necessita també la 128.0.0.0/1 corresponent, o una default autèntica. Llegir una configuració que funciona i copiar una de les dues meitats és com la gent acaba amb un bucle d’encaminament que només es trenca en certes destinacions.

Deixa excepcions deliberades per a les adreces que han de quedar-se a la LAN, i decideix què passa quan la cerca no troba res a la taula seleccionada. Una ruta de reserva explícita és més fàcil de raonar que una taula buida, que retorna un resultat inabastable i fa que l’aplicació sembli espatllada en lloc de mal encaminada.

Fes a la cerca la pregunta que fa la teva aplicació

ip route get resol un camí; ip route show llista les entrades emmagatzemades, i tots dos poden discrepar sense que cap estigui malament. Inclou el context d’origen, perquè les regles basades en origen només coincideixen quan la cerca porta un origen.

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

La primera ordre planteja la pregunta des de l’amfitrió. La segona afegeix una interfície d’entrada, que s’acosta més al que experimenta el trànsit reenviat, i la resposta sovint apunta a una altra taula. Cap de les destinacions no és un servei de prova en viu; 198.51.100.23 és una adreça de documentació, així que substitueix-la per un amfitrió que tinguis permès de sondar.

Fins i tot una cerca correcta només demostra que es va triar un camí. No diu res sobre si l’altre extrem accepta el trànsit ni sobre si la resposta pot tornar pel mateix raonament.

On es capgira la comparació

El trànsit de l’amfitrió i el trànsit reenviat no només prenen cerques diferents; es troben amb filtres diferents a la tornada. Linux aplica la validació de ruta inversa fent servir el més estricte dels ajustos de totes les interfícies i de la interfície receptora, així que canviar el valor d’una interfície pot no tenir cap efecte visible. L’encaminament basat en marques afegeix la relació src_valid_mark, en què la marca ha de coincidir perquè un origen es consideri vàlid.

Si les respostes desapareixen mentre l’encaminament de sortida sembla correcte, llegeix els valors efectius abans de tocar-los, i canvia’ls només amb una raó 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

Tria entre els dos dissenys amb evidència: si l’aplicació s’enllaça a l’adreça PPP, n’hi ha prou amb una regla d’origen més una taula que contingui la ruta del peer. Si la caixa reenvia per a una LAN al darrere, també necessites que el context d’entrada i el camí de tornada coincideixin. Quan no coincideixen, corregeix la propietat de la ruta en lloc d’afluixar la validació per a tota la màquina.