WireGuard imbricat: el salt intermedi no pot respondre al seu propi port
Quan el salt intermedi ho envia tot per un sol túnel, les respostes al seu servei d’entrada surten pel camí equivocat. Una regla de port d’origen a la interfície ho arregla.
Tres salts de WireGuard arriben a una xarxa que no té cap adreça pública, i aleshores la màquina intermèdia deixa de respondre al port on havia d’escoltar. El túnel cap endavant encara funciona, l’amfitrió llunyà encara respon, i només el servidor intermedi s’ha quedat callat des de fora. Aquesta combinació és confusa precisament perquè és autoinfligida: el salt intermedi obeeix la seva pròpia taula d’encaminament, i la taula envia les seves respostes pel camí equivocat.
Una cadena que funciona fins que parles amb la caixa intermèdia
Preneu una cadena il·lustrativa: el client A arriba al servidor B per UDP 500, i B arriba més enllà al servidor C per UDP 500. C només accepta trànsit de l’adreça del seu únic parell, cosa que el converteix en una fulla i manté el seu comportament simple. B no és una fulla, i tot el que té interès d’aquesta fallada passa allà.
La distinció és important perquè els papers de fulla i d’intermedi estiren en direccions oposades. Una fulla pot enviar-ho tot per un sol túnel sense conseqüències, ja que res més no en depèn. Un salt intermedi és alhora un punt final per als clients i un client cap al costat llunyà, i aquestes dues feines volen un encaminament diferent.
Per què la resposta surt pel túnel
A B, la interfície que mira cap a C porta AllowedIPs = 0.0.0.0/0 juntament amb la ruta per defecte corresponent. Per tant, cada paquet que B origina entra en aquest túnel, tret que alguna cosa més específica hi tingui prioritat.
Un paquet d’A adreçat a B arriba i s’accepta, perquè B és la destinació i el lliurament local passa primer. La resposta és un paquet nou de trinca generat localment i adreçat a l’adreça pública d’A, i aquesta destinació coincideix amb la ruta per defecte cap al túnel. C el rep, no posseeix aquesta adreça i el descarta.
El símptoma es llegeix com un problema de tallafoc o un desajust de claus, i aquí no és cert cap dels dos. Una captura al túnel cap a C mostra que les respostes van en la direcció equivocada. Aquesta única observació estalvia més temps que qualsevol quantitat de lectura de configuració, així que apunteu-la abans de començar a canviar claus. Qui no hagi vist la captura assumirà que el túnel mateix està trencat.
La reparació estreta: regles de política que coincideixen amb un port d’origen
Les respostes del sòcol d’escolta de B surten amb el port d’origen 500. Una regla de política pot coincidir-hi i tornar aquests paquets a la taula ordinària:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Les regles de política es consulten per ordre de prioritat, i la taula principal és a 32766, així que una regla a 100 es pregunta abans que la ruta per defecte del túnel tingui res a dir. Afegiu una entrada per cada port que hagi de romandre accessible des de fora i res més, perquè el trànsit reenviat segueixi fent servir el túnel per al qual es va construir.
Conèixer el límit d’aquest truc. El selector sport coincideix amb paquets generats localment, cosa que cobreix exactament el cas de la resposta i deliberadament no cobreix el trànsit que B només reenvia per a algú altre. Un servei allotjat darrere de B encara necessita la seva pròpia resposta, i fingir el contrari produeix una solució que funciona per al primer servei i falla per al segon.
Doneu un propietari a la regla
Una regla escrita en un indicador desapareix el proper cop que es reconstrueix la interfície. En una instal·lació de WireGuard, poseu-la on es crea i s’elimina la interfície:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Si NetworkManager, un ganxo de la distribució o un punt d’entrada de contenidor és el propietari de la interfície, la parella pertany a aquest propietari i no a un fitxer editat a mà. Comproveu les regles efectives després d’una reconnexió, no només després del primer inici, perquè el primer inici és el cas que sempre funciona.
Compareu les alternatives amb honestedat
La regla de port d’origen és una de quatre sortides, i és la més estreta de totes. Té l’avantatge de no tocar gens la política del túnel, i per això sol sobreviure als canvis posteriors. Les reparacions estretes també fallen sorollosament quan deixen d’aplicar-se, mentre que una excepció àmplia continua funcionant en silenci molt després que la raó hagi desaparegut. Aquesta diferència importa més que l’elegància quan algú altre posseeix la caixa d’aquí a dos anys.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
Verifiqueu des de tots dos extrems un cop hàgiu triat. Des d’A, inicieu una connexió al port de B i manteniu-la ocupada una estona. A B, feu que el nucli justifiqui el camí de la resposta amb una cosa com ip route get <address-of-A> sport 500, i confirmeu que anomena la interfície WAN i no el túnel. Després, comproveu que alguna cosa darrere de C encara respon a través de la cadena, cosa que demostra que l’excepció es va mantenir estreta en lloc de convertir-se en un desviament. Finalment, anoteu els ports a les notes de disseny, o el següent operador ho redescobrirà en un servei diferent.