Waarom een wildcard in een OpenVPN-route-instructie niet kan werken

de route installeert adresprefixen, dus een hostnamepatroon heeft niets om mee te vergelijken. Gebruik een prefix voor netwerken en een proxy of PAC-bestand wanneer domeinen moeten beslissen.

De bedoeling is redelijk: alles voor één bedrijfsdomein door de tunnel sturen en de rest met rust laten. De instructie die wordt bewerkt installeert routes, en een route kent geen hostnaam om mee te vergelijken. Elke poging om er een wildcard in te schrijven levert ofwel een parseerfout op of, erger, een route die vandaag toevallig werkt omdat de naam naar één adres is omgezet. Twee verschillende mechanismen wordt gevraagd elkaars werk te doen.

Wat een route installeert, en wat hij nooit leest

Een route-item zegt dat een bestemmingsprefix via een interface bereikbaar is. De kernel vergelijkt pakketten met die prefixen, dus de enige betrokken identificaties zijn adressen en maskers. Een hostnaam komt nooit voor in de beslissing over doorsturen, en daarom kan daar geen patroon worden vergeleken.

OpenVPN kan in sommige route-parameters een oplosbare naam accepteren, en die tolerantie is een bron van verwarring. De naam wordt omgezet terwijl de configuratie wordt toegepast, wat één of meer adressen oplevert die gewone routes worden. Daarna is de naam volledig uit beeld verdwenen.

Een route die uit een naam is opgebouwd is dus een momentopname, geen regel. Hij dekt wat die naam omzette op het moment dat de tunnel startte, en dat is precies het gedrag dat u niet wilt voor een familie hosts die verandert. Een record dat morgen verhuist, laat de route naar gisteren wijzen.

Wanneer de bestemming echt een prefix is

Als het doel een bekend particulier netwerk is, schrijf dan het prefix. Voor een voorbeeld uit de documentatieruimte zien een enkele host en een subnet er zo uit:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Beide items noemen adressen en maskers, en beide overleven DNS-wijzigingen omdat niets eraan van een naam afhangt. Dat is het hele voordeel: de route is een uitspraak over topologie en niet over een opzoeking die één keer plaatsvond.

Leid geen groot prefix af uit één DNS-antwoord. Eén hostnaam die naar één adres wordt omgezet, zegt u niets over de grootte van het netwerk erachter, en een geraden prefix is de manier waarop een tunnel uiteindelijk verkeer onderschept dat niemand van plan was erdoorheen te sturen. Vraag de netwerkeigenaar naar het werkelijke prefix in plaats van het uit een opzoeking af te leiden.

Wanneer de werkeenheid een hostnaam is

Selecteren op domein vereist iets dat het domein leest, dat wil zeggen een component op applicatieniveau. Het gebruikelijke antwoord is een HTTP-proxy aan de andere kant van de tunnel, waarbij de client kiest welke verzoeken ernaar worden gestuurd.

Een proxyconfiguratiebestand kan die keuze uitdrukken. De illustratieve regels hieronder sturen één domein en zijn subdomeinen naar een proxy en al het overige rechtstreeks:

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";
}

De vergelijking van de exacte naam dekt het domein zelf, en de suffixvergelijking dekt de kinderen zonder een naam te matchen die alleen op vergelijkbare tekens eindigt. Beide zijn nodig, en één weglaten levert een regel op die er goed uitziet en de top of een bedrieger overslaat.

Deze regels kiezen een proxy; ze maken er geen en ze wijzigen geen enkele route van het besturingssysteem. Het proxyadres heeft nog steeds zijn eigen pad door de tunnel nodig, en verzoeken die als rechtstreeks zijn gemarkeerd volgen nog steeds het routeringsbeleid dat de machine al heeft.

Wat de proxyoptie niet dekt

Programma's die de proxyconfiguratie van de browser negeren, ondervinden hier niets van. Opdrachtregelprogramma's, updaters en toepassingen met hun eigen netwerkstack nemen de routetabel, niet het PAC-bestand, dus die gevallen hebben een ondersteund mechanisme per toepassing of een ander ontwerp nodig. Inventariseer de clients die ertoe doen voordat u belooft dat de browserregel de werkstroom dekt.

Rechtstreeks terugkeren is ook geen ontsnappingsroute. Als het routeringsbeleid van de machine al alles de tunnel in stuurt, blijft een verzoek dat als rechtstreeks is gemarkeerd daarbinnen, omdat de proxykeuze en de routetabel verschillende beslissingen zijn die op verschillende lagen worden genomen.

Naamresolutie is een derde, aparte vraag. Kiezen welke verzoeken naar een proxy gaan, zegt niets over welke resolver ze beantwoordt, en de twee als één instelling behandelen levert lekken op die onzichtbaar zijn tot iemand van buitenaf test. Bepaal waar elke query wordt beantwoord en schrijf die beslissing naast de proxyregel. Een resolver die verandert omdat de tunnel omhoogkwam, zal het antwoord stil verplaatsen.

Beide paden testen, niet alleen het gelukkige

Test een hostnaam die zou moeten overeenkomen, een hostnaam die dat niet zou moeten, en de top van het domein, omdat de top het geval is dat het vaakst wordt gemist door een regel met alleen een suffix. Bevestig daarna welk pad elk verzoek werkelijk nam in plaats van het af te leiden uit of de pagina laadde.

Test ten slotte de foutvertakking. Een proxy die onbereikbaar is, hoort te falen op een manier die u vooraf hebt bepaald, in plaats van stil terug te vallen op een directe verbinding. De referentie voor netwerkopties documenteert de route-parameters nauwkeurig; de domeinhelft van dit ontwerp leeft er volledig buiten.

Gerelateerde artikelen