Hvad policy routing ændrer for VPN-trafik, og hvad det ikke ændrer

Policy routing besvarer et andet spørgsmål end det, de fleste fejlfindingsnoter stiller. Hovedtabellen siger, hvor en destination går hen; policyregler siger, hvilken tabel der overhovedet slås op, og de kan afgøre det ud fra kildeadressen, et pakkemærke, eller det interface, en pakke ankom på. Når en tunnel opfører sig inkonsekvent, er regelsættet ofte årsagen, og routingtabellen ofte ikke.

Regler vælger tabellen, så vælger tabellen ruten

Hver regel har en prioritet, en matchbetingelse og en måltabel. Kernen gennemgår reglerne i prioritetsrækkefølge og stopper ved det første match og udfører derefter et almindeligt længste-præfiks-opslag i den tabel. En regel, der peger på en tom tabel, falder igennem til det, den næste regel vælger, og det er sådan en omhyggeligt skrevet regel kan se ud, som om den ikke gør noget.

Det er derfor, at en dump af hovedtabellen sjældent forklarer en fungerende VPN-klient. Klienter indsætter normalt regler ved lave prioritetsnumre, længe før hovedtabellens standardregel, så pakken når aldrig den rute, du stirrede på. At sænke en metrik i hovedtabellen ændrer intet for trafik, der allerede er omdirigeret.

En regel kan også med vilje gøre et præfiks til et sort hul eller utilgængeligt. Nogle klienter tilføjer en sådan regel som en kill switch, og så ligner afvisningen en brudt tunnel snarere end en konfigureret.

Læs regelsættet som en sekvens, ikke som en liste

Udskriv reglerne med deres prioriteter og de tabeller, de henviser til, og udskriv derefter hver tabel, der bærer en standardrute eller en tunnelrute. Rækkefølgen er den del, der betyder noget, og det er den del, et skærmbillede normalt udelader:

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 sidste to kommandoer er dem, der gør en teori til en observation, fordi de spørger hvad kernen ville gøre for den kilde og det mærke. Hvis svaret ændrer sig, når mærket ændrer sig, er en mærkebaseret regel i spil, og enhver test, der udelader mærket, tester en anden pakke. Den ydre forbindelse fortjener sin egen regel. En tunnel, der router al trafik gennem sig selv, skal udelukke den slutpunktsadresse, den forbinder til, ellers sendes de krypterede pakker tilbage i den tunnel, de netop har forladt. De fleste klienter indsætter den udelukkelse automatisk, og et håndredigeret regelsæt er stedet, hvor den mangler.

Mærker og sockets: to måder klienter deler trafik på

Nogle klienter mærker pakker i firewallen og tilføjer en regel, der matcher mærket. Andre bruger routing på socketniveau og sætter en rute på socketten, før den forbinder. Det første er synligt i ip rule; det andet er ikke, og det vises ikke i et generisk opslag.

Hvis et testprogram opfører sig anderledes end det program, det skal repræsentere, så kontroller, om programmet sætter et mærke eller binder til en enhed. Den forskel er ikke en gåde, når mekanismen er navngivet, og den forklarer, hvorfor en curl fra en shell og en browservifte kan tage forskellige veje på samme maskine. Begge teknikker er policy routing i bred forstand: de vælger en vej ved hjælp af noget andet end destinationen. Ingen af dem autoriserer trafikken, og ingen af dem erstatter firewallreglerne eller de legitimationsoplysninger, peer forventer.

Spor ejerskabet, før du tilføjer endnu en regel

Regler installeres af noget. En VPN-klient, en netværksmanager og et håndskrevet script kan hver tilføje regler ved opstart, og genopkoblingslogik kan efterlade det foregående sæt. To forældede regler fra en tidligere profil vil blive ved med at styre trafik længe efter, at profilen er slettet.

Find ud af, hvilken proces der ejer reglen ud fra dens prioritet og form, og kontroller, om ejeren omskriver sættet ved hver forbindelse. Hvis den gør, forsvinder en manuel regel, der blev tilføjet i dag, i morgen, og rettelsen hører i klientens konfiguration snarere end i en shell-historikfil. At rydde hele regelsættet for at teste er en fristende genvej med en forudsigelig pris: det fjerner også de regler, klienten har brug for for at holde sin egen tunnel kørende. Slet én regel ad gangen, eller test på en maskine, du kan genstarte.

Bevis omfanget med to flows, ikke ét

En rettelse verificeres kun af et flow, der bør påvirkes, og et flow, der ikke bør. Vælg en destination, som politikken router ind i tunnelen, og en, den skal forlade udenfor, og sammenlign derefter opslagene og optagelserne for begge:

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 to opslag returnerer forskellige interfaces, gør reglen noget. Når de returnerer det samme interface, matcher reglen bredere end tilsigtet, og det er den fejl, der stille sender et helt subnet gennem en tunnel, der var beregnet til én applikation.

Notér reglernes prioriteter og den ejende tjeneste i billetten sammen med de to testadresser. Den næste person har så et reproducerbart par i stedet for en beskrivelse af et symptom og kan på et minut afgøre, om policy routing stadig er i spil.