Twee actieve IPsec-tunnels hebben nog steeds een terugwegplan nodig

Open een terminal op een werkstation op de ene locatie en verbind met een server op de andere. Dat ene TCP-gesprek moet nu vier gateways passeren in plaats van twee, en het interessante deel is niet of het op een goede dag werkt. Het interessante deel is welk paar gateways de heenweg koos, welk paar het antwoord kiest, en wie de status van de flow vasthoudt terwijl dat gebeurt. Niets in de routetabel beslist dat voor je.

Teken vier gateways voordat je een route tekent

Een dubbelactief ontwerp met twee onafhankelijke VPN-firewalls per locatie, één paar per provider, geeft je twee bruikbare paden en drie manieren om ze te breken. Schrijf de adressen op voordat je iets configureert: de client zoals gezien voor en na elke gateway, de server evenzo, de volgende hop heen en de volgende hop terug.

Die tabel is het ontwerp. Alles daarna is de vraag of de apparaten het met de tabel eens zijn.

Hoe de heenweg wordt gekozen

Een multipath-routelaag met gelijke kosten verdeelt flows over de volgende hops door headervelden te hashen, wat RFC 2992 in detail beschrijft. Die selectie kan volledig stateloos zijn: hij heeft geen verbindingsregistratie nodig, alleen een stabiele hash over onveranderde velden. Houd de padverzameling en de hash-invoer constant en elk pakket van de flow kiest dezelfde volgende hop.

Selectie per flow vermijdt de herordening die pakket-voor-pakket-balancering op links met verschillende vertragingen zou veroorzaken. Het belooft niet dat gelijke routingkosten gelijke gemeten latentie betekenen, want dat doen ze niet. En wanneer de padsamenstelling verandert, worden flows opnieuw gemapt, dus het overleven van verbindingen tijdens een storing is een aparte eis van padselectie.

Wat de terugweg echt nodig heeft

Hier houdt de rondgang op symmetrisch te zijn. Een stabiele forward-hash vertelt je niets over wat de verre locatie met het antwoord doet. Als een onafhankelijke firewall beide richtingen van de verbinding moet zien om bruikbare status te houden, laat een terugroute die hem omzeilt verkeer achter dat nergens op past. Twee boxen met vergelijkbare regelsets zijn geen gedeelde status.

Bevestig het geïmplementeerde tweerichtingsgedrag, of schrijf expliciet beleid dat de vereiste grenzen coherent houdt. Een gok hier wordt tijdens een storing ontdekt, door mensen die er niet van genieten.

Waar vertaling voor je beslist

NAT is de andere hefboom, en die is optioneel in plaats van verplicht. Padspecifieke vertaalde identiteiten kunnen antwoorden terugsturen naar de gateway die de status vasthoudt, wat een legitiem ontwerp is. Ze voegen ook mappings, terugroutes en een eigenaar van die status toe, dus accepteer de last alleen voor een eis die je hardop kunt noemen.

Als de eis simpelweg is dat beide paden verkeer dragen en een van beide een providerverlies overleeft, is gewone multipath per flow met coherente terugroutering meestal het kleinere ontwerp.

Loop de acceptatie in volgorde door

Test in deze volgorde en noteer de adressen bij elke stap: een nieuwe verbinding op pad A en zijn antwoordpad, hetzelfde op pad B, dan verlies van een provider, dan herstel. Noteer per resultaat welke bestaande flows zijn verplaatst, welke opnieuw moesten verbinden en waar nieuwe flows daarna naartoe gingen. Schrijf eerst de verwachte waarde op en vergelijk die dan met de capture. Twee bestaande tunnels bewijzen daar niets van.

Het ontwerp is klaar wanneer de tabel die je schreef overeenkomt met wat de capture laat zien, niet wanneer beide tunnels omhoog zijn.