Kvifor eit jokerteikn i ein OpenVPN-route-instruks ikkje kan fungere

Hensikta er rimeleg: send alt for eitt firmadomene gjennom tunnelen og lat resten vere. Instruksen som blir redigert, installerer ruter, og ei rute har ikkje noko omgrep om eit vertsnamn å matche mot. Kvart forsøk på å skrive eit jokerteikn inn i ho gjev anten ein parsefeil eller, verre, ei rute som tilfeldigvis fungerer i dag fordi namnet vart løyst til éin adresse. To ulike mekanismar blir bedne om å gjere kvarandre sitt arbeid.

Kva ei rute installerer, og kva ho aldri les

Ei ruteoppføring seier at eit destinasjonsprefiks kan nåast gjennom eit grensesnitt. Kjernen matchar pakkar mot desse prefiksa, så dei einaste involverte identifikatorane er adresser og masker. Eit vertsnamn viser seg aldri i videresendingsavgjerda, og difor kan eit mønster ikkje matchast der.

OpenVPN kan godta eit namn som kan løysast i nokre ruteparametrar, og den toleransen er ei kjelde til forvirring. Namnet blir løyst medan konfigurasjonen blir brukt, og gjev éin eller fleire adresser som blir vanlege ruter. Etter det er namnet heilt borte frå biletet.

Så ei rute bygd frå eit namn er eit augneblinksbilete, ikkje ei regel. Ho dekkjer det namnet vart løyst til i augneblinken tunnelen starta, og det er nøyaktig åtferda du ikkje vil ha for ein familie vertar som endrar seg. Ei oppføring som flyttar seg i morgon, lèt ruta peike på i går.

Når destinasjonen verkeleg er eit prefiks

Viss målet er eit kjent privat nettverk, skriv prefikset. For eit døme frå dokumentasjonsrommet ser ein ein einskild vert og eit subnett slik ut:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Begge oppføringane namngjev adresser og masker, og begge overlever DNS-endringar fordi ingenting ved dei er avhengig av eit namn. Det er heile fordelen: ruta er ei utsegn om topologi snarare enn om eit oppslag som skjedde éin gong.

Ikkje leid ut eit stort prefiks frå eitt einskilt DNS-svar. Eitt vertsnamn som blir løyst til éi adresse seier deg ingenting om storleiken på nettverket bak, og eit gjettet prefiks er måten ein tunnel endar med å fange trafikk som ingen hadde til hensikt å sende gjennom han. Spør nettverkseigaren om det faktiske prefikset i staden for å leie det ut frå eit oppslag.

Når arbeidseininga er eit vertsnamn

Å velje etter domene krev noko som les domenet, altså ein komponent på applikasjonslaget. Det vanlege svaret er ein HTTP-proxy som bur på den andre sida av tunnelen, der klienten vel kva førespurnader som skal sendast til han.

Ei proxykonfigurasjonsfil kan uttrykkje det valet. Dei illustrerande reglane nedanfor sender eitt domene og subdomena under det til ein proxy og alt anna 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";
}

Samanlikninga av det nøyaktige namnet dekkjer domenet sjølv, og suffikssamanlikninga dekkjer borna utan å matche eit namn som berre sluttar med liknande teikn. Begge er nødvendige, og blir éin utelaten, gjev det ei regel som ser riktig ut og hoppar over toppen eller ein bedragar.

Desse reglane vel ein proxy; dei opprettar ingen, og dei endrar inga operativsystemrute. Proxyadressa treng framleis sin eigen veg gjennom tunnelen, og førespurnader merkte som direkte følgjer framleis den rutingpolitikken maskinen allereie har.

Kva proxyvalet ikkje dekkjer

Program som ignorerer proxykonfigurasjonen til nettlesaren blir ikkje påverka av noko av dette. Kommandolinjeverktøy, oppdaterarar og applikasjonar med eigen nettverksstakk tek rutetabellen, ikkje PAC-fila, så desse tilfella treng ein støtta mekanisme per applikasjon eller ei anna utforming. Kartlegg klientane som betyr noko før du lovar at nettlesarregelen dekkjer arbeidsflyten.

Å gå direkte tilbake er heller ikkje ein naudutgang. Viss rutingpolitikken til maskinen allereie sender alt inn i tunnelen, blir ein førespurnad merkt som direkte verande inni han, fordi proxyvalet og rutetabellen er ulike avgjerder tekne på ulike lag.

Namneoppløysing er eit tredje separat spørsmål. Å velje kva førespurnader som går til ein proxy seier ingenting om kva resolver som svarar dei, og å handsame dei to som éin innstilling gjev lekkasjar som er usynlege til nokon testar utanfrå. Bestem kvar kvar spørjing blir svara, og skriv den avgjerda ved sida av proxyregelen. Ein resolver som endrar seg fordi tunnelen kom opp, vil flytte svaret i stillheit.

Teste begge vegar, ikkje berre den heldige

Test eit vertsnamn som skal matche, eit vertsnamn som ikkje skal, og toppen av domenet, sidan toppen er tilfellet som oftast blir oversett av ein regel med berre suffiks. Stadfest deretter kva veg kvar førespurnad faktisk tok i staden for å leie det ut frå om sida vart lasta.

Til slutt, test feilgreina. Ein proxy som ikkje kan nåast, bør feile på ein måte du har bestemt på førehand, i staden for stille å falle tilbake til ei direkte tilkopling. Referansen for nettverksval dokumenterer ruteparametrane presist; domenehalvdelen av dette designet lever heilt utanfor han.