App-Routing
Eine einzelne Anwendung durch eine andere Tür schicken. Jedes Match — Anwendung, Kategorie, SNI, Domain, Nutzer oder Geografie — kann über einen beliebigen Ausgang hinausgehen: ein zweites WAN, einen verschlüsselten Tunnel oder eine einfache Schnittstelle.
Ein einzelner Flow im Durchlauf
- 1Eine Richtlinie trägt eine Egress-Anweisung mit einem Routen-Ziel. Das Ziel ist jede Schnittstelle der Appliance — eine WAN-Verbindung, ein WireGuard-, OpenVPN-, IPsec- oder GRE-Tunnel oder eine gewöhnliche Netzwerkkarte.
- 2Die Klassifizierung läuft zuerst: Anwendung, Kategorie, SNI, Nutzer und Geografie hängen bereits am Flow, bevor die Routing-Entscheidung fällt.
- 3Eine strategie-basierte Übertragungsschicht löst den physischen Egress auf — direkte Schnittstelle, Kernel-Routing-Tabelle oder mit Adressumsetzung — und die Tunnel-Adapter binden den Socket an den benannten Tunnel.
- 4Health-Probes bewerten jedes Kandidaten-Ziel mit Sub-Sekunden-Kadenz. Das Failover erfolgt atomar und hysteresebewusst, sodass eine grenzwertige Verbindung keinen Flap auslöst.
Technische Hinweise
Routen-Ziele sind vollständig generisch: Schnittstelle plus Typ plus optionaler Protokoll-Adapter. Ein VPN-Tunnel ist ein vollwertiges Ziel und kein Sonderfall, der an eine Multi-WAN-Auswahl angeflanscht wurde.
Gesteuerte Flows behalten die echte Adresse des Clients durchgängig bei, sodass identitätsbewusste Richtlinien und Protokolle am anderen Ende weiterhin sehen, wer den Verkehr ausgelöst hat.
Health-Daten werden in einem maschinenlesbaren Format für Dashboards und externe Observability-Systeme bereitgestellt. Nichts bleibt verborgen, alles ist einsehbar.