VPN-reguloj en la kurserĉilo: kongruigu la fonton kaj la celon

Aĉetpaĝoj pri kurserĉiloj prezentas VPN-enkursigon kiel unu markobutonon, kaj tiu frazo kaŝas tri malsamajn demandojn. Ĉu la regulo kongruas kun la aparato, kiu sendas la trafikon, kun la servilo, kiu ricevas ĝin, aŭ kun ambaŭ? Kio okazas al trafiko, kiu kongruas kun neniu? Kaj kiam du reguloj intersekciĝas, kiu venkas? Se vi skribas la respondon kiel paron de fonto kaj celo, malklara listo de funkcioj fariĝas testebla dezajno.

La nomo de la funkcio kaŝas du finojn

Aparato por raŭdado, kiu uzu la tunelon, estas fonta kongruo. Privata oficeja prefikso, kiu estu atingebla tra la tunelo, estas cela kongruo. Laborspaco, kiu uzu la tunelon nur por unu servo, estas ambaŭ, kaj tiu komunaĵo estas la kazo, kiun la plej multaj konsumantaj firmvaroj traktas malbone.

Skribu la postulon kiel paron antaŭ ol kompari produktojn. Tiu paro estas tio, kion vi testos poste.

Produkto, kiu proponas aparatan liston aŭ tutmondan celan liston, eble ne povas esprimi «nur ĉi tiu aparato, nur ĉi tiuj celoj». La manko ne estas kosmetika: tutmonda cela regulo sendas la trafikon de ĉiu aparato al tiu retejo tra la tunelo, kaj aparata regulo sendas la tutan trafikon de tiu aparato. Neniu el ili estas la postulo. Testu tiun kazon per du aparatoj antaŭ ol fidi la ekranon.

Konstruu la regulon kiel komunaĵon

Tabelo tenas la dezajnon honesta. Metu la scenaron maldekstre, poste nomu aparte la sendantan kongruon kaj la celan kongruon:

La tria vico estas la interesa, ĉar ĝi bezonas ambaŭ duonojn samtempe. Se la firmvaro povas esprimi nur unu akson, la postulo devas esti dividita en du regulojn aŭ transdonita al aparato, kiu povas tion.

Tenu la fontan identecon stabila. DHCP-rezervo, dediĉita segmento aŭ aparata identeca mekanismo ĉiuj funkcias, sed adreso, kiu ŝanĝiĝas post la fino de luo, ne funkcias. Inkluzivigu IPv6, ĉar unu IPv4-adreso ne identigas la tutan trafikon de aparato.

Prioritato decidas la intersekciĝon

Intersekciĝantaj reguloj estas normalaj. Larĝa aparata regulo kaj mallarĝa cela regulo povas ambaŭ priskribi unu fluon, kaj la dokumentita prioritata ordo decidas, kiu venkas. Alloga agorda ekrano ne diras tiun ordon al vi.

Legi la manlibron pri la ordo kaj pri la kazo sen kongruo, poste testu ambaŭ per trafiko, kiun vi povas observi:

ip rule show
ip route get 203.0.113.10

Se la dokumentaro ne indikas la ordon, supozu, ke la pli mallarĝa regulo eble ne venkos, kaj desegnu ĉirkaŭe. Du reguloj, kiuj ne povas konflikti, estas pli facile subteneblaj ol unu lerta regulo kun nedokumentita prioritato.

Nomoj bezonas refreŝigan politikon

Celo skribita kiel domajno aldonas prizorgan problemon. La kurserĉilo devas solvi ĝin, refreŝigi la mapadon, trakti plurajn adresojn kaj subdomajnojn, kaj elteni aplikaĵan DNS, kiu preterpasas la atendatan solvilon.

Kopii unu serĉrezulton en IP-regulon estas momenta bildo, ne domajna politiko.

Decida, kiom malnova respondo rajtas esti antaŭ ol la regulo malĝustas, kaj kion la kurserĉilo faras, kiam solvado malsukcesas. Regulo, kiu konservas la lastan konatan adreson, povas postvivi servan migradon; regulo, kiu forĵetas la eron, povas silente haltigi tuneladon. Ambaŭ kondutoj akcepteblas, se ili estas skribitaj apud la regulo.

Difinu la neatingeblan staton

Enkursiga prefero ne devigas nur-VPNan trafikon. Kiam la tunelo estas malaktiva, la kurserĉilo povas bloki la fluon, sendi ĝin rekte aŭ uzi alian tunelon, kaj ĉiu elekto havas malsaman fiaskosignaturon.

Decida, kiun la postulo bezonas, poste kontrolu ĝin haltigante la tunelon kaj observante la fluon:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

Trafiko originanta de la kurserĉilo mem estas aparta sfero. DNS-plusendado, ĝisdatigaj kontroloj kaj monitorado povas komenci novajn fluojn de la kurserĉilo mem anstataŭ heredi la fontan kongruon de la aparato. Enkalkulu tiujn fluojn eksplicite, alie ili aperos kiel neklarigitaj likoj en la protokoloj.