Vad policy routing ändrar för VPN-trafik, och vad det inte ändrar

Policy routing svarar på en annan fråga än den de flesta felsökningsanteckningar ställer. Huvudtabellen säger vart en destination tar vägen; policyregler säger vilken tabell som alls slås upp, och de kan avgöra det utifrån källadressen, en paketmarkering, eller det gränssnitt ett paket anlände på. När en tunnel beter sig inkonsekvent är regeluppsättningen ofta orsaken och routingtabellen ofta inte.

Regler väljer tabellen, sedan väljer tabellen vägen

Varje regel bär en prioritet, ett matchningsvillkor och en måltabell. Kärnan går igenom reglerna i prioritetsordning och stannar vid första matchning och gör sedan en vanlig sökning efter längsta prefix i den tabellen. En regel som pekar på en tom tabell faller igenom till det nästa regel väljer, och så kan en noggrant skriven regel se ut som om den inte gör något.

Därför förklarar en utskrift av huvudtabellen sällan en fungerande VPN-klient. Klienter lägger vanligtvis in regler på låga prioritetsnummer, långt före huvudtabellens standardregel, så paketet når aldrig vägen du stirrade på. Att sänka ett mått i huvudtabellen ändrar ingenting för trafik som redan har omdirigerats.

En regel kan också med avsikt göra ett prefix till ett svart hål eller otillgängligt. Vissa klienter lägger till en sådan regel som en kill switch, och då ser avvisningen ut som en trasig tunnel snarare än en konfigurerad.

Läs regeluppsättningen som en sekvens, inte som en lista

Skriv ut reglerna med deras prioriteter och tabellerna de refererar till, och skriv sedan ut varje tabell som bär en standardväg eller en tunnelväg. Ordningen är den del som spelar roll, och det är den del en skärmbild vanligtvis utelämnar:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

De två sista kommandona är de som gör en teori till en observation, eftersom de frågar vad kärnan skulle göra för den källan och den markeringen. Om svaret ändras när markeringen ändras är en markeringsbaserad regel i spel och varje test som utelämnar markeringen testar ett annat paket. Den yttre anslutningen förtjänar en egen regel. En tunnel som routar all trafik genom sig själv måste utesluta slutpunktsadressen den ansluter till, annars skickas de krypterade paketen tillbaka in i tunneln de just lämnade. De flesta klienter lägger in den uteslutningen automatiskt, och en handredigerad regeluppsättning är stället där den saknas.

Markeringar och sockets: två sätt som klienter delar trafik

Vissa klienter markerar paket i brandväggen och lägger till en regel som matchar markeringen. Andra använder routing på socketnivå och sätter en väg på socketen innan den ansluter. Det första syns i ip rule; det andra inte, och det dyker inte upp i en generisk sökning.

Om ett testprogram beter sig annorlunda än applikationen det ska representera, kontrollera om applikationen sätter en markering eller binder sig till en enhet. Den skillnaden är ingen gåta när mekanismen har namngetts, och den förklarar varför en curl från ett skal och en webbläsarflik kan ta olika vägar på samma maskin. Båda teknikerna är policy routing i vid mening: de väljer en väg med något annat än destinationen. Ingen av dem auktoriserar trafiken, och ingen av dem ersätter brandväggsreglerna eller de uppgifter som motparten förväntar sig.

Spåra ägarskapet innan du lägger till ännu en regel

Regler installeras av något. En VPN-klient, en nätverkshanterare och ett handskrivet skript kan var och en lägga till regler vid start, och återanslutningslogik kan lämna den föregående uppsättningen efter sig. Två föråldrade regler från en tidigare profil fortsätter styra trafiken långt efter att profilen har raderats.

Ta reda på vilken process som äger regeln utifrån dess prioritet och form, och kontrollera om ägaren skriver om uppsättningen vid varje anslutning. Om den gör det försvinner en manuell regel som lades till i dag i morgon, och rättelsen hör hemma i klientens konfiguration snarare än i en skalhistorikfil. Att rensa hela regeluppsättningen för att testa är en frestande genväg med ett förutsägbart pris: det tar också bort de regler klienten behöver för att hålla sin egen tunnel igång. Ta bort en regel i taget, eller testa på en maskin du kan starta om.

Bevisa omfånget med två flöden, inte ett

En rättelse verifieras bara av ett flöde som ska påverkas och ett flöde som inte ska det. Välj en destination som policyn routar in i tunneln, och en som måste stanna utanför, och jämför sedan uppslagningarna och avlyssningarna för båda:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

När de två uppslagningarna returnerar olika gränssnitt gör regeln något. När de returnerar samma gränssnitt matchar regeln bredare än avsett, och det är felet som stilla skickar ett helt subnät genom en tunnel avsedd för en enda applikation.

Anteckna reglernas prioriteter och den ägande tjänsten i biljetten, tillsammans med de två testadresserna. Nästa person har då ett reproducerbart par i stället för en beskrivning av ett symptom, och kan på en minut säga om policy routing fortfarande är i spel.