Hvorfor et jokertegn i en OpenVPN-route-direktiv ikke kan fungere

ruten installerer adresseprefikser, så et vertsnavnmønster har ingenting å matche. Bruk et prefiks for nettverk og en proxy eller PAC-fil når domener skal bestemme.

Hensikten er rimelig: send alt for ett firmadomene gjennom tunnelen og la resten være. Direktivet som redigeres installerer ruter, og en rute har ikke noe begrep om et vertsnavn å matche mot. Hvert forsøk på å skrive et jokertegn inn i den gir enten en parsefeil eller, verre, en rute som tilfeldigvis fungerer i dag fordi navnet ble løst til én adresse. To forskjellige mekanismer blir bedt om å gjøre hverandres arbeid.

Hva en rute installerer, og hva den aldri leser

En ruteoppføring sier at et destinasjonsprefiks kan nås gjennom et grensesnitt. Kjernen matcher pakker mot disse prefiksene, så de eneste involverte identifikatorene er adresser og masker. Et vertsnavn vises aldri i videresendingsbeslutningen, og derfor kan et mønster ikke matches der.

OpenVPN kan godta et navn som kan løses i noen ruteparametere, og den toleransen er en kilde til forvirring. Navnet løses mens konfigurasjonen brukes, og gir én eller flere adresser som blir vanlige ruter. Etter det er navnet helt borte fra bildet.

Så en rute bygget fra et navn er et øyeblikksbilde, ikke en regel. Den dekker det navnet ble løst til i det øyeblikket tunnelen startet, og det er nøyaktig oppførselen du ikke vil ha for en familie verter som endrer seg. En oppføring som flytter seg i morgen, lar ruten peke på i går.

Når destinasjonen virkelig er et prefiks

Hvis målet er et kjent privat nettverk, skriv prefikset. For et eksempel fra dokumentasjonsrommet ser en enkelt vert og et subnett slik ut:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Begge oppføringene navngir adresser og masker, og begge overlever DNS-endringer fordi ingenting ved dem avhenger av et navn. Det er hele fordelen: ruten er en uttalelse om topologi snarere enn om et oppslag som skjedde én gang.

Ikke utled et stort prefiks fra ett enkelt DNS-svar. Ett vertsnavn som løses til én adresse sier deg ingenting om størrelsen på nettverket bak, og et gjettet prefiks er måten en tunnel ender med å fange trafikk som ingen hadde til hensikt å sende gjennom den. Spør nettverkseieren om det faktiske prefikset i stedet for å utlede det fra et oppslag.

Når arbeidsenheten er et vertsnavn

Å velge etter domene krever noe som leser domenet, altså en komponent på applikasjonslaget. Det vanlige svaret er en HTTP-proxy som bor på den andre siden av tunnelen, der klienten velger hvilke forespørsler som skal sendes til den.

En proxykonfigurasjonsfil kan uttrykke det valget. De illustrerende reglene nedenfor sender ett domene og dets subdomener til en proxy og alt annet direkte:

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

Sammenligningen av det nøyaktige navnet dekker domenet selv, og suffikssammenligningen dekker barna uten å matche et navn som bare slutter med lignende tegn. Begge er nødvendige, og utelates én, gir det en regel som ser riktig ut og hopper over toppen eller en bedrager.

Disse reglene velger en proxy; de oppretter ikke en, og de endrer ingen operativsystemrute. Proxyadressen trenger fortsatt sin egen vei gjennom tunnelen, og forespørsler merket som direkte følger fortsatt den rutingpolitikken maskinen allerede har.

Hva proxyvalget ikke dekker

Programmer som ignorerer nettleserens proxykonfigurasjon blir ikke påvirket av noe av dette. Kommandolinjeverktøy, oppdaterere og applikasjoner med egen nettverksstakk tar rutetabellen, ikke PAC-filen, så disse tilfellene trenger en støttet mekanisme per applikasjon eller en annen utforming. Kartlegg klientene som betyr noe før du lover at nettleserregelen dekker arbeidsflyten.

Å gå direkte tilbake er heller ikke en nødutgang. Hvis maskinens rutingpolitikk allerede sender alt inn i tunnelen, blir en forespørsel merket som direkte værende inni den, fordi proxyvalget og rutetabellen er forskjellige beslutninger tatt på forskjellige lag.

Navneoppløsning er et tredje separat spørsmål. Å velge hvilke forespørsler som går til en proxy sier ingenting om hvilken resolver som svarer dem, og å behandle de to som én innstilling gir lekkasjer som er usynlige til noen tester utenfra. Bestem hvor hver spørring besvares, og skriv den beslutningen ved siden av proxyregelen. En resolver som endres fordi tunnelen kom opp, vil flytte svaret i stillhet.

Teste begge veier, ikke bare den heldige

Test et vertsnavn som skal matche, et vertsnavn som ikke skal, og domenets topp, siden toppen er tilfellet som oftest overses av en regel med bare suffiks. Bekreft deretter hvilken vei hver forespørsel faktisk tok i stedet for å utlede det fra om siden ble lastet.

Til slutt, test feilgrenen. En proxy som ikke kan nås, bør feile på en måte du har bestemt på forhånd, i stedet for stille å falle tilbake til en direkte forbindelse. Referansen for nettverksvalg dokumenterer ruteparameterne presist; domenehalvdelen av dette designet lever helt utenfor den.

Relaterte artikler