Varför ett jokertecken i ett OpenVPN-route-direktiv inte kan fungera

rutten installerar adressprefix, så ett värdnamnsmönster har ingenting att matcha. Använd ett prefix för nätverk och en proxy eller PAC-fil när domäner ska avgöra.

Avsikten är rimlig: skicka allt för en företagsdomän genom tunneln och lämna resten i fred. Direktivet som redigeras installerar rutter, och en rutt har inget begrepp om ett värdnamn att matcha mot. Varje försök att skriva ett jokertecken i den ger antingen ett tolkningsfel eller, värre, en rutt som av en slump fungerar i dag eftersom namnet löstes till en enda adress. Två olika mekanismer ombeds göra varandras arbete.

Vad en rutt installerar, och vad den aldrig läser

En ruttpost säger att ett destinationsprefix kan nås via ett gränssnitt. Kärnan matchar paket mot dessa prefix, så de enda identifierarna som är inblandade är adresser och masker. Ett värdnamn förekommer aldrig i vidarebefordringsbeslutet, och därför kan ett mönster inte matchas där.

OpenVPN kan acceptera ett upplösbart namn i vissa ruttparametrar, och den toleransen är en källa till förvirring. Namnet löses medan konfigurationen tillämpas, vilket ger en eller flera adresser som blir vanliga rutter. Efter det är namnet helt borta från bilden.

Så en rutt byggd från ett namn är en ögonblicksbild, inte en regel. Den täcker vad det namnet löstes till i det ögonblick tunneln startade, och det är precis det beteende du inte vill ha för en familj värdar som ändras. En post som flyttar i morgon lämnar rutten pekande på i går.

När destinationen verkligen är ett prefix

Om målet är ett känt privat nätverk, skriv prefixet. För ett exempel från dokumentationsutrymmet ser en enda värd och ett subnät ut så här:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Båda posterna namnger adresser och masker, och båda överlever DNS-ändringar eftersom ingenting i dem beror av ett namn. Det är hela fördelen: rutten är ett påstående om topologi snarare än om en sökning som skedde en gång.

Härled inte ett stort prefix från ett enda DNS-svar. Ett värdnamn som löses till en adress säger dig ingenting om storleken på nätverket bakom, och ett gissat prefix är sättet en tunnel till slut fångar trafik som ingen avsåg att skicka genom den. Fråga nätverksägaren om det faktiska prefixet i stället för att härleda det från en sökning.

När arbetsenheten är ett värdnamn

Att välja efter domän kräver något som läser domänen, det vill säga en komponent på applikationslagret. Det vanliga svaret är en HTTP-proxy som bor på andra sidan tunneln, där klienten väljer vilka förfrågningar som ska skickas till den.

En proxykonfigurationsfil kan uttrycka det valet. De illustrativa reglerna nedan skickar en domän och dess subdomäner till en proxy och allt annat 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";
}

Jämförelsen av det exakta namnet täcker domänen själv, och suffixjämförelsen täcker dess barn utan att matcha ett namn som bara slutar med liknande tecken. Båda behövs, och utelämnas en får man en regel som ser rätt ut och hoppar över toppen eller en bedragare.

Dessa regler väljer en proxy; de skapar ingen och de ändrar ingen operativsystemrutt. Proxyadressen behöver fortfarande sin egen väg genom tunneln, och förfrågningar markerade som direkta följer fortfarande den routingpolicy som maskinen redan har.

Vad proxyalternativet inte täcker

Program som ignorerar webbläsarens proxykonfiguration påverkas inte av något av detta. Kommandoradsverktyg, uppdaterare och applikationer med egen nätverksstack tar rutttabellen, inte PAC-filen, så dessa fall behöver en stödd mekanism per applikation eller en annan design. Inventera klienterna som spelar roll innan du lovar att webbläsarregeln täcker arbetsflödet.

Att gå direkt tillbaka är inte heller en nödutgång. Om maskinens routingpolicy redan skickar allt in i tunneln, stannar en förfrågan markerad som direkt kvar inuti den, eftersom proxyvalet och rutttabellen är olika beslut fattade på olika lager.

Namnupplösning är en tredje separat fråga. Att välja vilka förfrågningar som går till en proxy säger ingenting om vilken resolver som svarar dem, och att behandla de två som en enda inställning ger läckor som är osynliga tills någon testar utifrån. Bestäm var varje fråga besvaras och skriv ned det beslutet bredvid proxyregeln. En resolver som ändras eftersom tunneln kom upp kommer tyst att flytta svaret.

Testa båda vägarna, inte bara den lyckliga

Testa ett värdnamn som borde matcha, ett värdnamn som inte borde det, och domänens topp, eftersom toppen är det fall som oftast missas av en regel med bara suffix. Bekräfta sedan vilken väg varje förfrågan faktiskt tog i stället för att härleda det från om sidan laddades.

Testa slutligen felgrenen. En proxy som inte går att nå bör misslyckas på ett sätt du bestämt i förväg, i stället för att tyst falla tillbaka på en direkt anslutning. Referensen för nätverksalternativ dokumenterar ruttparametrarna exakt; domänhalvan av denna design lever helt utanför den.

Relaterade artiklar