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

Hensigten er rimelig: send alt for ét firmadomæne gennem tunnelen og lad resten være. Den direktiv, der redigeres, installerer ruter, og en rute har ikke noget begreb om et værtsnavn at matche imod. Ethvert forsøg på at skrive et jokertegn ind i den giver enten en parsefejl eller, værre, en rute, der tilfældigvis virker i dag, fordi navnet blev opløst til én adresse. To forskellige mekanismer bliver bedt om at gøre hinandens arbejde.

Hvad en rute installerer, og hvad den aldrig læser

En ruteangivelse siger, at et destinationspræfiks kan nås gennem en grænseflade. Kernen matcher pakker mod disse præfikser, så de eneste involverede identifikatorer er adresser og masker. Et værtsnavn optræder aldrig i videresendelsesbeslutningen, og derfor kan et mønster ikke matches der.

OpenVPN kan acceptere et navn, der kan opløses, i nogle ruteparametre, og den tolerance er en kilde til forvirring. Navnet opløses, mens konfigurationen anvendes, hvilket giver en eller flere adresser, der bliver almindelige ruter. Derefter er navnet helt væk fra billedet.

Så en rute bygget ud fra et navn er et øjebliksbillede, ikke en regel. Den dækker, hvad det navn blev opløst til i det øjeblik, tunnelen startede, og det er præcis den adfærd, du ikke ønsker for en familie af værter, der ændrer sig. En post, der flytter sig i morgen, efterlader ruten pegende på i går.

Når destinationen virkelig er et præfiks

Hvis målet er et kendt privat netværk, så skriv præfikset. For et eksempel fra dokumentationsrummet ser en enkelt vært og et undernet sådan ud:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Begge poster angiver adresser og masker, og begge overlever DNS-ændringer, fordi intet ved dem afhænger af et navn. Det er hele fordelen: ruten er en udtalelse om topologi snarere end om et opslag, der skete én gang.

Udled ikke et stort præfiks fra et enkelt DNS-svar. Ét værtsnavn, der opløses til én adresse, siger intet om størrelsen på netværket bagved, og et gættet præfiks er måden, hvorpå en tunnel ender med at opfange trafik, som ingen havde til hensigt at sende gennem den. Spørg netværksejeren om det faktiske præfiks i stedet for at udlede det af et opslag.

Når arbejdsenheden er et værtsnavn

At vælge efter domæne kræver noget, der læser domænet, hvilket betyder en komponent på applikationslaget. Det sædvanlige svar er en HTTP-proxy, der bor på den anden side af tunnelen, hvor klienten vælger, hvilke anmodninger der skal sendes til den.

En proxykonfigurationsfil kan udtrykke det valg. De illustrerende regler nedenfor sender ét domæne og dets underdomæner til en proxy og alt andet 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 med det nøjagtige navn dækker selve domænet, og suffikssammenligningen dækker dets børn uden at matche et navn, der blot slutter med lignende tegn. Begge er nødvendige, og hvis man udelader den ene, får man en regel, der ser rigtig ud og springer toppen eller en bedrager over.

Disse regler vælger en proxy; de opretter ikke en, og de ændrer ikke nogen rute i operativsystemet. Proxyadressen skal stadig have sin egen vej gennem tunnelen, og anmodninger markeret som direkte følger stadig den routingpolitik, maskinen allerede har.

Hvad proxyindstillingen ikke dækker

Programmer, der ignorerer browserens proxykonfiguration, bliver ikke påvirket af noget af dette. Kommandolinjeværktøjer, opdateringsprogrammer og applikationer med deres egen netværksstak tager rutetabellen, ikke PAC-filen, så de tilfælde kræver en understøttet mekanisme for hver applikation eller et andet design. Lav en fortegnelse over de klienter, der betyder noget, før du lover, at browserreglen dækker arbejdsgangen.

At returnere direkte er heller ikke en nødudgang. Hvis maskinens routingpolitik allerede sender alt ind i tunnelen, forbliver en anmodning markeret som direkte indeni, fordi proxyvalget og rutetabellen er forskellige beslutninger truffet på forskellige lag.

Navneopløsning er et tredje separat spørgsmål. At vælge, hvilke anmodninger der går til en proxy, siger intet om, hvilken resolver der svarer dem, og at behandle de to som én indstilling giver lækager, som er usynlige, indtil nogen tester udefra. Beslut, hvor hver forespørgsel besvares, og skriv den beslutning ned ved siden af proxyreglen. En resolver, der ændrer sig, fordi tunnelen kom op, vil lydløst flytte svaret.

Test begge veje, ikke kun den lykkelige

Test et værtsnavn, der bør matche, et værtsnavn, der ikke bør, og domænets top, da toppen er det tilfælde, der oftest overses af en regel med kun suffiks. Bekræft derefter, hvilken vej hver anmodning faktisk tog, i stedet for at udlede det af, om siden blev indlæst.

Test til sidst fejlgreningen. En proxy, der ikke kan nås, bør fejle på en måde, du har besluttet på forhånd, i stedet for lydløst at falde tilbage til en direkte forbindelse. Referencen for netværksindstillinger dokumenterer ruteparametrene præcist; domænehalvdelen af dette design ligger helt uden for den.