Warum ein Wildcard in einer OpenVPN-Route-Direktive nicht funktionieren kann

die Route installiert Adresspräfixe, daher hat ein Hostnamenmuster nichts, womit es übereinstimmen könnte. Verwenden Sie ein Präfix für Netzwerke und einen Proxy oder eine PAC-Datei, wenn Domains entscheiden sollen.

Die Absicht ist vernünftig: alles für eine Firmendomain durch den Tunnel schicken und den Rest in Ruhe lassen. Die bearbeitete Direktive installiert Routen, und eine Route kennt kein Hostnamenkonzept, gegen das sie abgleichen könnte. Jeder Versuch, ein Wildcard hineinzuschreiben, erzeugt entweder einen Analysefehler oder, schlimmer, eine Route, die heute zufällig funktioniert, weil der Name sich zu einer Adresse aufgelöst hat. Zwei verschiedene Mechanismen werden gebeten, die Arbeit des jeweils anderen zu erledigen.

Was eine Route installiert und was sie nie liest

Ein Routeneintrag besagt, dass ein Zielpräfix über eine Schnittstelle erreichbar ist. Der Kernel gleicht Pakete gegen diese Präfixe ab, daher sind die einzigen beteiligten Bezeichner Adressen und Masken. Ein Hostname erscheint nie in der Weiterleitungsentscheidung, weshalb dort kein Muster abgeglichen werden kann.

OpenVPN kann in einigen Routenparametern einen auflösbaren Namen akzeptieren, und diese Toleranz ist eine Quelle der Verwirrung. Der Name wird aufgelöst, während die Konfiguration angewendet wird, wodurch eine oder mehrere Adressen entstehen, die zu gewöhnlichen Routen werden. Danach ist der Name völlig aus dem Bild verschwunden.

Eine aus einem Namen gebaute Route ist also eine Momentaufnahme, keine Regel. Sie deckt ab, wozu dieser Name in dem Moment aufgelöst wurde, als der Tunnel startete, und das ist genau das Verhalten, das Sie für eine sich ändernde Hostfamilie nicht wollen. Ein Eintrag, der sich morgen verschiebt, lässt die Route auf gestern zeigen.

Wenn das Ziel wirklich ein Präfix ist

Wenn das Ziel ein bekanntes privates Netzwerk ist, schreiben Sie das Präfix. Für ein Beispiel aus dem Dokumentationsraum sehen ein einzelner Host und ein Subnetz so aus:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Beide Einträge nennen Adressen und Masken, und beide überstehen DNS-Änderungen, weil nichts an ihnen von einem Namen abhängt. Das ist der ganze Vorteil: Die Route ist eine Aussage über die Topologie und nicht über eine Suche, die einmal stattgefunden hat.

Leiten Sie kein großes Präfix aus einer einzigen DNS-Antwort ab. Ein Hostname, der sich zu einer Adresse auflöst, sagt Ihnen nichts über die Größe des dahinterliegenden Netzwerks, und ein geratenes Präfix ist der Weg, auf dem ein Tunnel am Ende Datenverkehr abfängt, den niemand durch ihn senden wollte. Fragen Sie den Netzwerkeigentümer nach dem tatsächlichen Präfix, anstatt es aus einer Suche abzuleiten.

Wenn die Arbeitseinheit ein Hostname ist

Die Auswahl nach Domain erfordert etwas, das die Domain liest, also eine Komponente auf Anwendungsebene. Die übliche Antwort ist ein HTTP-Proxy auf der anderen Seite des Tunnels, wobei der Client auswählt, welche Anfragen er an ihn sendet.

Eine Proxy-Konfigurationsdatei kann diese Wahl ausdrücken. Die illustrativen Regeln unten senden eine Domain und ihre Subdomains an einen Proxy und alles andere direkt:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

Der Vergleich des exakten Namens erfasst die Domain selbst, und der Suffixvergleich erfasst ihre Kinder, ohne einen Namen abzugleichen, der lediglich mit ähnlichen Zeichen endet. Beide sind nötig, und lässt man eine weg, entsteht eine Regel, die richtig aussieht und die Spitze oder einen Betrüger überspringt.

Diese Regeln wählen einen Proxy; sie erzeugen keinen und ändern keine Betriebssystemroute. Die Proxy-Adresse braucht weiterhin ihren eigenen Weg durch den Tunnel, und als direkt markierte Anfragen folgen weiterhin der Routingrichtlinie, die die Maschine bereits hat.

Was die Proxy-Option nicht abdeckt

Programme, die die Proxy-Konfiguration des Browsers ignorieren, werden von alldem nicht betroffen. Kommandozeilenwerkzeuge, Updater und Anwendungen mit eigenem Netzwerkstack nehmen die Routentabelle, nicht die PAC-Datei, daher brauchen diese Fälle einen unterstützten Mechanismus pro Anwendung oder ein anderes Design. Erfassen Sie die Clients, die zählen, bevor Sie versprechen, dass die Browserregel den Arbeitsablauf abdeckt.

Direkt zurückzukehren ist auch kein Ausweg. Wenn die Routingrichtlinie der Maschine bereits alles in den Tunnel schickt, bleibt eine als direkt markierte Anfrage darin, weil die Proxy-Wahl und die Routentabelle unterschiedliche Entscheidungen sind, die auf unterschiedlichen Ebenen getroffen werden.

Die Namensauflösung ist eine dritte, getrennte Frage. Die Wahl, welche Anfragen an einen Proxy gehen, sagt nichts darüber, welcher Resolver sie beantwortet, und beide als eine Einstellung zu behandeln erzeugt Leckagen, die unsichtbar bleiben, bis jemand von außen testet. Entscheiden Sie, wo jede Abfrage beantwortet wird, und schreiben Sie diese Entscheidung neben die Proxy-Regel. Ein Resolver, der sich ändert, weil der Tunnel hochkam, verschiebt die Antwort stillschweigend.

Beide Wege testen, nicht nur den glücklichen

Testen Sie einen Hostnamen, der passen sollte, einen Hostnamen, der nicht passen sollte, und die Domänenspitze, denn die Spitze ist der Fall, der von einer reinen Suffixregel am häufigsten übersehen wird. Bestätigen Sie dann, welchen Weg jede Anfrage tatsächlich genommen hat, anstatt es daraus abzuleiten, ob die Seite geladen wurde.

Testen Sie schließlich den Fehlerzweig. Ein nicht erreichbarer Proxy sollte auf eine Weise fehlschlagen, die Sie vorher entschieden haben, anstatt stillschweigend auf eine direkte Verbindung zurückzufallen. Die Referenz zu den Netzwerkoptionen dokumentiert die Routenparameter präzise; die Domänenhälfte dieses Designs liegt völlig außerhalb davon.

Ähnliche Artikel