Bronrouting voor twee VPN-pools: wat je regel mist

Twee klantpools, één gateway en het plan lijkt triviaal: de ene regel stuurt de eerste pool over de snelle uplink naar buiten, de andere stuurt de tweede pool door een partnertunnel. Dan staan de regels er en de tweede pool verlaat het netwerk nog steeds via de standaardroute. De regel is niet stuk. De bron van het pakket is niet wat de auteur op het moment van de lookup verwachtte, omdat vertaling en lookup op verschillende punten in de reis van hetzelfde pakket gebeuren, en de volgorde is het omgekeerde van het mentale diagram dat de meeste mensen tekenen.

De lookup gebeurt voordat de bron wordt herschreven

Voor een pakket dat van een VPN-client wordt doorgestuurd, voert de kernel een vaste reeks uit. Het komt aan op de tunnelinterface, passeert prerouting waar conntrack en DNAT leven, dan wordt de routingbeslissing genomen, dan het doorsturen, dan postrouting waar SNAT als laatste wordt toegepast. Een regel van de vorm from wordt tijdens die routingbeslissing geraadpleegd, wat betekent dat hij het oorspronkelijke adres van de client ziet, niet het vertaalde.

Een masquerade-regel toevoegen verandert dus niet welke policy bij de uitgaande stroom past. Wat verandert is wat de verre kant ziet, en daarmee welke retourroute bestaat. Dat zijn twee verschillende gevolgen, en wijzigingsreviews halen ze constant door elkaar. Scheid ze en het ontwerp wordt meestal binnen een minuut duidelijk.

In de antwoordrichting duikt het vertaalde adres op in de regels. Een pakket dat naar de gateway terugkomt, is geadresseerd aan het vertaalde adres, en als je policyregels hebt op basis van de bestemming of de interface waar het binnenkwam, is dat de waarde die je matcht. Dezelfde verbinding, in elke richting een andere bron van waarheid.

Twee pools met verschillende bronnen hebben dus echt verschillende tabellen nodig, en het ontwerp is degelijk. Wat de tabel hierboven uitsluit, is de sluipweg om te debuggen door te kijken wat de verre site ontving en daaruit de regel af te leiden.

Een test vanaf de gateway is geen test van de pool

Verkeer dat de gateway zelf genereert, gaat nooit door prerouting, omdat het niet op een interface is aangekomen. Het wordt in het uitvoerpad gerouteerd, met het eigen adres van de gateway als bron, en een from-regel op basis van een klantbereik zal niet matchen. Elk ticket in dit gebied dat zegt dat het vanaf de doos werkt maar niet vanaf de client, is diezelfde constatering in andere woorden.

Simuleer de client in plaats van hem te benaderen. De routing-lookup kan direct worden gevraagd, met een bron en een ingangsinterface opgegeven:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Voer het één keer per pool uit. Als de twee commando's dezelfde interface teruggeven, scheiden de regels de pools niet, en de reden is ofwel een ontbrekende regel ofwel een regel met hogere prioriteit die op beide past. Als ze verschillende interfaces teruggeven maar de client faalt nog steeds, ligt de fout na de lookup en kun je stoppen met naar regels te kijken.

Prioriteit, niet positie in het bestand

Regels worden in oplopende prioriteitsvolgorde geëvalueerd, en het getal is wat telt, niet de volgorde waarin je ze hebt getypt. De local-tabel staat op prioriteit 0, de main-tabel op 32766 en de standaardregel op 32767, daarom belandt een regel die met de standaardprioriteit is toegevoegd bijna onderaan de lijst en verliest van bijna alles.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

Een expliciete prioriteit maakt de bedoelde volgorde zichtbaar in het bestand en in de review. Hij voorkomt ook dat een latere toevoeging stilletjes voor een bestaande regel springt, wat de meest voorkomende oorzaak is dat een werkend beleid na een ongerelateerde wijziging stopt met werken.

Een passende regel die naar een onvolledige tabel wijst, is de andere valkuil. Als tabel 201 een standaardroute bevat maar geen route naar de bestemming, wordt het pakket gedropt of naar de verkeerde plek gestuurd, en de regel lijkt los volkomen correct. Lees de tabel, niet alleen de regel. Een regel is een verwijzing, en een lege tabel is een verwijzing naar niets.

De retourroute moet er nog steeds zijn

Bronbeleid kiest een uitgang. Het creëert geen retourroute. Als de tweede pool via een partnertunnel naar buiten gaat, moet de partner weten hoe hij 172.31.8.0/24 bereikt, ofwel via een route terug naar de gateway, ofwel door vertaalde adressen te ontvangen die hij al kent.

Kiezen tussen die twee is een ontwerpbeslissing met zichtbare gevolgen. Het klantbereik terug routeren behoudt de identiteit van elke client bij de partner en vereist dat hij jouw prefix accepteert. Vertaling verbergt de pool achter één adres en vereist dat de partner alleen dat adres accepteert, ten koste van logs die het niet meer eens zijn over wie verbonden was.

Wat je ook kiest, schrijf het naast de pooldefinitie. Een retourroute die alleen in iemands geheugen bestaat, is precies het soort ding dat blijft bestaan tot de partner een firewall wijzigt, en dan een dag kost om te reconstrueren.

Vang de eigen tunnel van de gateway niet in het beleid

De regels die je voor clients schrijft, gelden ook voor verkeer dat de gateway genereert, tenzij je het uitsluit. Een brede regel op een mark of op de uitgangsinterface kan de eigen verbinding van de gateway met de partner vangen, en dan wordt de tunnel die het beleid draagt door het beleid gerouteerd. Dat levert een lus of een storing op die op een providerfout lijkt.

Beperk elke regel zo nauw als het ontwerp toestaat: bronprefix, ingangsinterface en, waar ondersteund, een mark die alleen klantpakketten dragen. Test daarna de eigen connectiviteit van de gateway na elke regelwijziging, want de fout is zelfreferentieel en verschijnt niet in een test vanaf de client.

De manpagina van ip-rule documenteert de semantiek van de selector en de prioriteit. Combineer die met een lookuptest per pool en het ontwerp wordt controleerbaar, wat het verschil is tussen policy-routing die een jaar meegaat en die waar iedereen bang is om aan te komen.