La resposta surt per la LAN, no pel túnel: per què i com
Una sol·licitud que arriba pel túnel no fa que la resposta surti pel mateix camí. Linux busca la destinació i la subxarxa local sol guanyar.
Un servei publicat a través d'una passarel·la funciona des de la major part d'internet i falla des d'una oficina. Algú revisa el túnel, veu arribar la sol·licitud i conclou que la resposta deu seguir el mateix camí de tornada. Linux no funciona així, i cap inspecció del túnel no canviarà la resposta. La resposta s'encamina per destinació, i aquell únic sol·licitant que falla és en una subxarxa a la qual l'amfitrió ja arriba directament.
Què decideix realment un paquet de sortida
El nucli busca una ruta per a la destinació del paquet, consultant les regles de política per ordre de prioritat i després la taula que selecciona una regla coincident. La interfície per la qual va arribar un paquet no hi té cap paper tret que s'hagi escrit una regla o una marca per fer-la rellevant. És un fet d'encaminament d'aquest amfitrió, no una fallada del túnel.
Per tant, una sol·licitud rebuda pel túnel pot produir una resposta que surti per la interfície física, i el flux es torna unidireccional sense que cap dispositiu informi d'un error. Comproveu les dues direccions abans de treure conclusions sobre el túnel. Una resposta que surt pel costat equivocat desapareix dels comptadors del túnel, i per això els dos extrems no coincideixen sobre si s'ha enviat res. Fixeu-vos en quin comptador s'ha mogut abans de tocar cap regla.
Per què guanya la subxarxa local
Un amfitrió amb una adreça en una xarxa local té una ruta connectada per a aquest prefix a la taula principal, i una ruta connectada és una coincidència directa. Quan el sol·licitant ve d'aquesta mateixa subxarxa, la consulta troba l'enllaç local abans que el túnel es consideri.
L'asimetria és el que fa que el diagnòstic sigui confús. Els sol·licitants de la resta d'internet funcionen perquè no coincideixen amb cap ruta local, mentre que l'únic sol·licitant que comparteix el prefix de l'oficina falla, que és exactament el sol·licitant amb què algú prova.
La cobertura d'iguales no és el mateix que les rutes instal·lades
Pel costat del túnel, els rangs permesos d'un igual descriuen què es pot enviar al túnel i quines fonts s'accepten d'ell. No diuen res sobre on enviarà un paquet la taula d'encaminament local.
Si l'eina del túnel instal·la una ruta per defecte a l'amfitrió, pot arrossegar trànsit no relacionat cap al túnel com a dany col·lateral. On hauria de ser una regla de política qui prengués la decisió, l'opció d'instal·lació de rutes de l'eina existeix justament per evitar-ho, i les adreces, les claus i la configuració del punt final queden exactament com eren. Una ruta per defecte afegida per comoditat és una manera habitual que un amfitrió perdi la seva pròpia xarxa local.
Seleccioneu la taula per l'adreça d'origen
Una regla basada en l'origen envia les respostes de l'adreça del servei a una taula privada el valor per defecte de la qual és el túnel, mentre que tota la resta continua fent servir la taula principal. Trieu números de taula i de prioritat que no s'utilitzin localment, i llegiu les regles existents abans d'inserir res. Llegiu les regles actives en lloc d'un fitxer desat, perquè els dos poden diferir després d'un reinici.
ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachableL'última línia fa que una ruta absent falli visiblement en lloc de recórrer a l'enllaç local. L'origen ha d'estar realment assignat a l'amfitrió, i les consultes ordinàries local i principal han de romandre a les seves posicions anteriors. La regla tria una taula per origen; no compara longituds de prefix entre taules.
Confirmeu el camí, després el servei
Pregunteu al nucli què faria en lloc d'inferir-ho d'una captura, fent servir l'adreça del servei com a selector d'origen. Una resposta equivocada aquí estalvia tot un rastreig de paquets.
ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20La sortida hauria de nomenar el túnel. Després proveu un origen que no hàgiu tocat i confirmeu que encara agafa l'enllaç local, de manera que el canvi hagi quedat limitat a una adreça. Un selector més ampli no demostraria res sobre la queixa original.
Què no arregla això
Deixeu el reenviament, les regles de tallafoc i el comportament d'ICMPv6 a la passarel·la tal com eren, perquè una ruta d'origen no substitueix cap d'aquests elements. Un missatge Packet Too Big absent encara trenca les respostes grans, guanyi quina guanyi la consulta. Arregleu-ho abans d'afegir regles d'encaminament, o el símptoma sobreviurà al canvi.
Confirmeu el model de publicació abans d'aplicar res d'això. Un proxy invers que obre la seva pròpia connexió de backend presenta el seu propi origen i no conserva el sol·licitant, així que aquesta fallada no pot passar en aquest disseny. Aplicar-hi la regla afegiria una excepció d'encaminament que no resol res i amaga la causa real.
Finalment, escriviu els números de regla i la taula a la gestió de configuració de l'amfitrió. Una regla de política afegida a mà desapareix a la propera reconstrucció, i el sol·licitant de l'oficina torna amb la mateixa queixa.