Pse një wildcard në direktivën route të OpenVPN nuk mund të funksionojë

Qëllimi është i arsyeshëm: të dërgohet gjithçka për një domen kompanie përmes tunelit dhe pjesa tjetër të lihet në paqe. Direktiva që po redaktohet instalon rrugë, dhe një rrugë nuk ka asnjë koncept emri hosti me të cilin të përputhet. Çdo përpjekje për të shkruar një wildcard në të prodhon ose një gabim analize ose, më keq, një rrugë që sot funksionon rastësisht sepse emri u zgjidh në një adresë të vetme. Dy mekanizma të ndryshëm po kërkohen të bëjnë punën e njëri-tjetrit.

Çfarë instalon një rrugë dhe çfarë nuk lexon kurrë

Një zë rruge thotë se një prefiks destinacioni është i arritshëm përmes një ndërfaqeje. Kernel-i i krahason paketat me ato prefikse, kështu që identifikuesit e vetëm të përfshirë janë adresat dhe maskat. Një emër hosti nuk shfaqet kurrë në vendimin e përcjelljes, dhe kjo është arsyeja pse një model nuk mund të përputhet atje.

OpenVPN mund të pranojë një emër të zgjidhshëm në disa parametra rruge, dhe kjo tolerancë është burim konfuzioni. Emri zgjidhet gjatë aplikimit të konfigurimit, duke prodhuar një ose më shumë adresa që bëhen rrugë të zakonshme. Pas kësaj, emri zhduket plotësisht nga fotografia.

Pra, një rrugë e ndërtuar nga një emër është një pamje e çastit, jo një rregull. Ajo mbulon atë në të cilën ky emër u zgjidh në momentin kur tuneli filloi, dhe ky është pikërisht sjellja që nuk e dëshironi për një familje hostesh që ndryshon. Një regjistrim që lëviz nesër e lë rrugën duke treguar nga dje.

Kur destinacioni është vërtet një prefiks

Nëse objektivi është një rrjet privat i njohur, shkruani prefiksin. Për një shembull nga hapësira e dokumentacionit, një host i vetëm dhe një nënrrjet duken kështu:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Të dy zërat përmendin adresa dhe maska, dhe të dy i mbijetojnë ndryshimeve të DNS sepse asgjë në to nuk varet nga një emër. Ky është i gjithë avantazhi: rruga është një deklaratë për topologjinë dhe jo për një kërkim që ndodhi një herë.

Mos nxirrni një prefiks të madh nga një përgjigje e vetme DNS. Një emër hosti që zgjidhet në një adresë nuk ju thotë asgjë për madhësinë e rrjetit pas tij, dhe një prefiks i hamendësuar është mënyra se si një tunel përfundon duke kapur trafik që askush nuk synonte ta dërgonte përmes tij. Pyetni pronarin e rrjetit për prefiksin aktual në vend që ta nxirrni nga një kërkim.

Kur njësia e punës është një emër hosti

Zgjedhja sipas domenit kërkon diçka që lexon domenin, domethënë një komponent të shtresës së aplikacionit. Përgjigja e zakonshme është një proxy HTTP që jeton në anën tjetër të tunelit, me klientin që zgjedh cilat kërkesa t'i dërgojë atij.

Një skedar konfigurimi i proxy-t mund të shprehë atë zgjedhje. Rregullat ilustruese më poshtë dërgojnë një domen dhe nëndomenet e tij te një proxy dhe gjithçka tjetër drejtpërdrejt:

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

Krahasimi i emrit të saktë mbulon vetë domenin, dhe krahasimi i prapashtesës mbulon fëmijët e tij pa u përputhur me një emër që thjesht përfundon me karaktere të ngjashme. Të dyja janë të nevojshme, dhe lënia jashtë e njërës prodhon një rregull që duket i saktë dhe kalon majën ose një mashtrues.

Këto rregulla zgjedhin një proxy; nuk krijojnë një dhe nuk ndryshojnë asnjë rrugë të sistemit operativ. Adresa e proxy-t ende ka nevojë për rrugën e saj përmes tunelit, dhe kërkesat e shënuara si të drejtpërdrejta ende ndjekin politikën e rrugëzimit që makina ka tashmë.

Çfarë nuk mbulon opsioni i proxy-t

Programet që injorojnë konfigurimin e proxy-t të shfletuesit nuk do të ndikohen nga asgjë e kësaj. Mjetet e rreshtit të komandës, përditësuesit dhe aplikacionet me stivën e tyre të rrjetit marrin tabelën e rrugëve, jo skedarin PAC, kështu që ato raste kanë nevojë për një mekanizëm për çdo aplikacion të mbështetur ose një dizajn tjetër. Inventarizoni klientët që kanë rëndësi përpara se të premtoni se rregulli i shfletuesit mbulon rrjedhën e punës.

Kthimi drejtpërdrejt nuk është as rrugë shpëtimi. Nëse politika e rrugëzimit të makinës tashmë dërgon gjithçka në tunel, një kërkesë e shënuar si e drejtpërdrejtë mbetet brenda tij, sepse zgjedhja e proxy-t dhe tabela e rrugëve janë vendime të ndryshme të marra në shtresa të ndryshme.

Zgjidhja e emrave është pyetja e tretë e veçantë. Zgjedhja e kërkesave që shkojnë te një proxy nuk thotë asgjë për atë se cili zgjidhës u përgjigjet atyre, dhe trajtimi i të dyjave si një cilësim i vetëm prodhon rrjedhje që janë të padukshme derisa dikush të testojë nga jashtë. Vendosni se ku i përgjigjet secilës pyetje dhe shkruajeni atë vendim pranë rregullit të proxy-t. Një zgjidhës që ndryshon sepse tuneli u ngrit do ta zhvendosë përgjigjen në heshtje.

Të testosh të dyja rrugët, jo vetëm atë të lumturën

Testoni një emër hosti që duhet të përputhet, një emër hosti që nuk duhet, dhe majën e domenit, pasi maja është rasti që humbet më shpesh nga një rregull vetëm me prapashtesë. Pastaj konfirmoni se cilën rrugë mori vërtet secila kërkesë në vend që ta nxirrni nga fakti nëse faqja u ngarkua.

Së fundi, testoni degën e dështimit. Një proxy që nuk arrihet duhet të dështojë në një mënyrë që e keni vendosur paraprakisht, në vend që të bjerë në heshtje përsëri në një lidhje të drejtpërdrejtë. Referenca e opsioneve të rrjetit dokumenton me saktësi parametrat e rrugës; gjysma e domenit e këtij dizajni jeton plotësisht jashtë saj.