Statische routes of een routingprotocol over een site-to-site-VPN?

Beide opties dragen pakketten tussen locaties, dus de beslissing gaat niet over welk protocol nieuwer is, en de grootte van de tunnel beslecht het ook niet. Drie voorwaarden doen dat: hoeveel prefixen veranderen en hoe vaak, of het ontwerp automatische failover tussen paden nodig heeft, en hoeveel beheervlak-machinerie het team om drie uur 's nachts kan draaien. Beantwoord dat eerlijk en de keuze maakt zich meestal zelf. De rest van dit stuk is wat elk antwoord kost.

Drie voorwaarden beslissen het

De eerste voorwaarde is verloop. Een handvol stabiele subnetten met duidelijk eigenaarschap is jarenlang met de hand te onderhouden, en elke route blijft een regel die iemand kan lezen en controleren. Tientallen prefixen die verschuiven wanneer projecten komen en gaan zijn een ander probleem, want elke verhuizing moet elk apparaat bereiken dat het oude pad nog kent.

De tweede is faalgedrag. Wanneer een reservepad actief moet worden zonder dat een mens het merkt, moet iets de storing detecteren en de route intrekken. Statische routing kan dat alleen via tracking of voorwaardelijke installatie, en alleen voor de storingen die je vooraf hebt bedacht.

De derde is zin in een tweede beheervlak. Een routingprotocol voegt sessies, authenticatie, filters en selectiebeleid toe, en elk daarvan vraagt monitoring plus een wijzigingsproces. Dat is een permanente operationele kostenpost, geen eenmalige configuratietaak.

De tabel onder de derde alinea is de korte versie, en de drie secties erna leggen uit waarom elke rij staat waar hij staat. Lees de rijen tegen je eigen aantal locaties voordat je kiest, want een beslissing die de operationele kosten negeert is maar een halve beslissing.

Wat statische routing werkelijk kost

Een statische route moet aan beide kanten van de tunnel kloppen. Een subnet toevoegen betekent de externe gateway, de lokale gateway en meestal het retourpad aanpassen, en een van die vergeten levert een eenrichtingsstoring op die op een applicatiefout lijkt. Het applicatieteam ziet time-outs terwijl het netwerkteam een route ziet die aanwezig is en ogenschijnlijk gezond. Geen van beide teams heeft ongelijk, en daarom duurt het zo lang om deze storing te plaatsen.

Een statische vermelding blijft ook geïnstalleerd nadat het pad eronder verdwijnt. Tenzij het platform tracking levert, blijft de route wijzen naar een volgende hop die niet meer doorstuurt, en het verkeer verdwijnt in plaats van over te schakelen. Die stilte is de kostenpost die je accepteert als je de eenvoudige optie kiest.

Schrijf de trackingmethode naast elke route, noteer welke storingen hij dekt, en houd de lijst bij de tunnelconfiguratie. Anders ontdekt een gebruiker de volgende storing in plaats van het netwerk, wat altijd de duurdere ontdekking is.

Wat dynamische routing werkelijk kost

Een protocol adverteert nieuwe prefixen, trekt onbereikbare in en drukt voorkeur uit tussen paden. Dat is echt nuttig wanneer meerdere locaties of redundante tunnels anders bij elke wijziging gecoördineerde aanpassingen zouden vragen. Het is ook de reden dat het protocol je op het slechtste moment kan verrassen. Elk van die acties is een toestandswijziging die je niet zelf hebt gedaan.

Het creëert twee toestanden die het oneens kunnen zijn. De tunnel kan omhoog zijn terwijl de routingsessie omlaag is, en de sessie kan omhoog zijn terwijl zijn aankondigingen het subnet weglaten dat de applicatie nodig heeft. Beide zien eruit als een netwerk dat half werkt, en geen van beide is zichtbaar vanaf een tunnelstatuspagina.

Filters en beleid worden daardoor deel van het ontwerp in plaats van een nagedachte. Een protocol dat alles adverteert, adverteert uiteindelijk iets verkeerd, en het verkeerde prefix reist sneller dan de persoon die het kan corrigeren. Schrijf de filters voordat de eerste sessie wordt aangezet, zodat de eerste aankondiging al bewust is.

Beheer wat de routingsessie mag zeggen

Bepaal de toegestane prefixlijst per peer en handhaaf die bij inkomend verkeer, want een uitgaand filter kan niet voorkomen dat een peer je een standaardroute stuurt. Standaardroutes en aggregaten zijn hier de dure fouten: ze kunnen ongerelateerde paden stil vervangen door één geleerde vermelding die er legitiem uitziet. Wijs ze expliciet af, tenzij het ontwerp ze echt wil.

Schrijf de eigenende locatie naast elk netwerk voordat de eerste sessie omhoog komt, want die mapping is de bron van de filterlijst en geen documentatieversiering. Zonder die mapping moet degene die een filter aanpast raden welke locatie het prefix zou moeten aankondigen.

Herverdeling tussen twee protocollen is waar lussen beginnen, en waar hetzelfde prefix twee keer aankomt met attributen die niet schoon te vergelijken zijn. Houd herverdeling buiten het ontwerp tot een specifieke eis het afdwingt, en als het moet bestaan, markeer en filter dan de routes aan de grens.

Op routes gebaseerde tunnelinterfaces maken dynamische routing makkelijker voor te stellen, omdat de tunnel een interface met routes wordt in plaats van een beleid dat selectors matcht. Dat neemt de vraag naar de peer-scope niet weg: de IPsec-selectors moeten het verkeer dat je wilt routeren nog steeds toestaan.

Test het faalpad, niet het gelukkige pad

Wat je ook kiest, haal één uplink neer en bevestig dat het verkeer beweegt, of dat het faalt zoals je hebt gedocumenteerd. Een ontwerp dat alleen is getest met beide paden gezond, is een ontwerp dat helemaal niet is getest. Meet de detectie terwijl je er bent, want het getal dat je hebt gemeten is het getal dat gebruikers zullen ervaren.

Bevestig daarna het retourpad onafhankelijk, want asymmetrische routing over een VPN is gebruikelijk en onzichtbaar tot een stateful apparaat de antwoorden laat vallen. Een stroom die één kant op werkt, bewijst maar de helft van het pad.

Werkvolgorde: tel de prefixen, beslis hoe storingen moeten worden gedetecteerd, controleer wie het protocol kan draaien, beheer wat er wordt aangekondigd, en test dan één onderbreking van begin tot eind. Elke stap levert een feit dat de volgende stap nodig heeft.