Wat beleidsroutering verandert aan VPN-verkeer, en wat niet

Beleidsroutering beantwoordt een andere vraag dan de vraag die de meeste probleemoplossingsnotities stellen. De hoofdtabel zegt waar een bestemming heen gaat; beleidsregels zeggen welke tabel überhaupt wordt geraadpleegd, en ze kunnen dat beslissen op basis van het bronadres, een pakketmarkering, of de interface waarop een pakket aankwam. Wanneer een tunnel zich inconsistent gedraagt, is de regelset vaak de oorzaak en de routingtabel vaak niet.

Regels kiezen de tabel, dan kiest de tabel de route

Elke regel draagt een prioriteit, een overeenkomstvoorwaarde en een doeltabel. De kernel doorloopt de regels in prioriteitsvolgorde en stopt bij de eerste overeenkomst, en voert dan een gewone zoekactie naar de langste prefix in die tabel uit. Een regel die naar een lege tabel wijst, valt door naar wat de volgende regel kiest, en zo kan een zorgvuldig geschreven regel lijken niets te doen.

Daarom verklaart het dumpen van de hoofdtabel zelden een werkende VPN-client. Clients voegen regels meestal in bij lage prioriteitsnummers, lang voor de standaardregel van de hoofdtabel, zodat het pakket nooit de route bereikt waar u naar staarde. Een metriek in de hoofdtabel verlagen verandert niets voor verkeer dat al was omgeleid.

Een regel kan ook met opzet een prefix zwart gat of onbereikbaar maken. Sommige clients voegen zo'n regel toe als kill switch, en dan lijkt de drop een kapotte tunnel in plaats van een geconfigureerde.

Lees de regelset als een reeks, niet als een lijst

Druk de regels af met hun prioriteiten en de tabellen waarnaar ze verwijzen, en druk dan elke tabel af die een standaard- of tunnelroute draagt. De volgorde is het deel dat ertoe doet, en dat is het deel dat een schermafbeelding meestal weglaat:

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 laatste twee opdrachten zijn degene die een theorie in een waarneming veranderen, omdat ze vragen wat de kernel voor die bron en die markering zou doen. Als het antwoord verandert wanneer de markering verandert, is een op markering gebaseerde regel in het spel en test elke test die de markering weglaat een ander pakket. De buitenste verbinding verdient een eigen regel. Een tunnel die al het verkeer door zichzelf routeert, moet het eindpuntadres uitsluiten waarmee hij verbinding maakt, anders worden de versleutelde pakketten terug in de tunnel gestuurd die ze net hebben verlaten. De meeste clients voegen die uitsluiting automatisch in, en een met de hand bewerkte regelset is de plek waar die ontbreekt.

Markeringen en sockets: twee manieren waarop clients verkeer splitsen

Sommige clients markeren pakketten in de firewall en voegen een regel toe die bij de markering past. Anderen gebruiken routering op socketniveau en zetten een route op de socket voordat die verbinding maakt. Het eerste is zichtbaar in ip rule; het tweede niet, en het zal niet in een generieke zoekopdracht verschijnen.

Als een testprogramma zich anders gedraagt dan de applicatie die het moet vertegenwoordigen, controleer dan of de applicatie een markering zet of zich aan een apparaat bindt. Dat verschil is geen raadsel zodra het mechanisme is benoemd, en het verklaart waarom een curl uit een shell en een browsertab op dezelfde machine verschillende paden kunnen nemen. Beide technieken zijn beleidsroutering in brede zin: ze kiezen een pad met iets anders dan de bestemming. Geen van beide autoriseert het verkeer, en geen van beide vervangt de firewallregels of de inloggegevens die de peer verwacht.

Traceer eigenaarschap voordat u nog een regel toevoegt

Regels worden door iets geïnstalleerd. Een VPN-client, een netwerkbeheerder en een handgeschreven script kunnen elk bij het opstarten regels toevoegen, en herverbindingslogica kan de vorige set achterlaten. Twee verouderde regels uit een eerder profiel blijven verkeer sturen lang nadat het profiel is verwijderd.

Zoek uit welk proces de regel bezit op basis van de prioriteit en de vorm, en controleer of die eigenaar de set bij elke verbinding herschrijft. Als dat zo is, verdwijnt een vandaag toegevoegde handmatige regel morgen, en de oplossing hoort in de configuratie van de client en niet in een shell-geschiedenisbestand. De hele regelset leegmaken om te testen is een verleidelijke snelkoppeling met voorspelbare kosten: het verwijdert ook de regels die de client nodig heeft om zijn eigen tunnel te laten werken. Verwijder telkens één regel, of test op een machine die u kunt herstarten.

Bewijs de omvang met twee stromen, niet met één

Een correctie wordt alleen geverifieerd door een stroom die moet worden getroffen en een stroom die dat niet moet. Kies een bestemming die het beleid de tunnel in routeert, en een die buiten moet blijven, en vergelijk dan de opzoekingen en de opnamen voor beide:

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

Wanneer de twee opzoekingen verschillende interfaces teruggeven, doet de regel iets. Wanneer ze dezelfde interface teruggeven, past de regel breder dan bedoeld, en dat is de fout die stilletjes een heel subnet door een tunnel stuurt die voor één applicatie bedoeld was.

Noteer de prioriteiten van de regels en de eigenaar-dienst in de ticket, samen met de twee testadressen. De volgende persoon heeft dan een reproduceerbaar paar in plaats van een beschrijving van een symptoom, en kan binnen een minuut zeggen of beleidsroutering nog in het spel is.