Kāpēc aizstājējzīme OpenVPN maršruta direktīvā nevar darboties

maršruts instalē adrešu prefiksus, tāpēc resursdatora nosaukuma šablonam nav ar ko saskaņoties. Tīkliem izmantojiet prefiksu, bet, ja jāizlemj domēniem, izmantojiet starpniekserveri vai PAC failu.

Nodoms ir saprātīgs: sūtīt visu vienam uzņēmuma domēnam caur tuneli un atstāt pārējo mierā. Rediģējamā direktīva instalē maršrutus, un maršrutam nav nekāda resursdatora nosaukuma jēdziena, ar ko saskaņoties. Katrs mēģinājums tajā ierakstīt aizstājējzīmi dod vai nu parsēšanas kļūdu, vai, kas ir sliktāk, maršrutu, kas šodien darbojas nejauši, jo nosaukums tika atrisināts uz vienu adresi. Divām atšķirīgām mehānismām tiek prasīts darīt vienai otras darbu.

Ko maršruts instalē un ko tas nekad nelasa

Maršruta ieraksts saka, ka galamērķa prefikss ir sasniedzams caur saskarni. Kodols salīdzina paketes ar šiem prefiksiem, tāpēc vienīgie iesaistītie identifikatori ir adreses un maskas. Resursdatora nosaukums nekad neparādās pārsūtīšanas lēmumā, un tāpēc tur nevar saskaņot šablonu.

OpenVPN dažos maršruta parametros var pieņemt atrisināmu nosaukumu, un šī iecietība ir neskaidrību avots. Nosaukums tiek atrisināts, kamēr konfigurācija tiek piemērota, radot vienu vai vairākas adreses, kas kļūst par parastiem maršrutiem. Pēc tam nosaukums pilnībā pazūd no attēla.

Tātad no nosaukuma būvēts maršruts ir momentuzņēmums, nevis noteikums. Tas aptver to, uz ko šis nosaukums tika atrisināts tuneli palaižot, un tā ir tieši tā uzvedība, ko jūs nevēlaties mainīgai resursdatoru saimei. Ieraksts, kas rīt pārvietosies, atstāj maršrutu rādot uz vakar.

Kad galamērķis patiešām ir prefikss

Ja mērķis ir zināms privāts tīkls, ierakstiet prefiksu. Dokumentācijas telpas piemērā viens resursdators un viens apakštīkls izskatās šādi:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Abi ieraksti nosauc adreses un maskas, un abi pārdzīvo DNS izmaiņas, jo nekas tajos nav atkarīgs no nosaukuma. Tā ir visa priekšrocība: maršruts ir apgalvojums par topoloģiju, nevis par meklēšanu, kas notika vienu reizi.

Neatvasiniet lielu prefiksu no vienas DNS atbildes. Viens resursdatora nosaukums, kas atrisinās uz vienu adresi, neko nepasaka par aiz tā esošā tīkla lielumu, un minēts prefikss ir veids, kā tunelis galu galā sāk uztvert trafiku, ko neviens nebija paredzējis caur to sūtīt. Jautājiet tīkla īpašniekam faktisko prefiksu, tā vietā lai secinātu to no meklēšanas.

Kad darba vienība ir resursdatora nosaukums

Atlase pēc domēna prasa kaut ko, kas lasa domēnu, tas ir, lietojumprogrammu slāņa komponentu. Parastā atbilde ir HTTP starpniekserveris, kas dzīvo tuneļa otrā pusē, un klients izvēlas, kādus pieprasījumus tam sūtīt.

Starpniekservera konfigurācijas fails var izteikt šo izvēli. Tālāk sniegtie ilustratīvie noteikumi sūta vienu domēnu un tā apakšdomēnus starpniekserverim, bet visu pārējo tieši:

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

Precīza nosaukuma salīdzināšana aptver pašu domēnu, un sufiksa salīdzināšana aptver tā bērnus, nesaskaņojot nosaukumu, kas vienkārši beidzas ar līdzīgām rakstzīmēm. Abi ir nepieciešami, un viena izlaišana rada noteikumu, kas izskatās pareizs un izlaiž virsotni vai krāpnieku.

Šie noteikumi izvēlas starpniekserveri; tie to neveido un nemaina nevienu operētājsistēmas maršrutu. Starpniekservera adresei joprojām vajadzīgs savs ceļš caur tuneli, un kā tieši atzīmēti pieprasījumi joprojām seko maršrutēšanas politikai, kas mašīnai jau ir.

Ko starpniekservera opcija neaptver

Programmas, kas ignorē pārlūkprogrammas starpniekservera konfigurāciju, netiks ietekmētas ar neko no tā. Komandrindas rīki, atjauninātāji un lietojumprogrammas ar savu tīkla steku ņem maršrutu tabulu, nevis PAC failu, tāpēc šajos gadījumos ir vajadzīgs atbalstīts mehānisms katrai lietojumprogrammai vai cits dizains. Uzskaitiet svarīgos klientus, pirms apsolāt, ka pārlūkprogrammas noteikums aptver darbplūsmu.

Atgriezties tieši arī nav izeja. Ja mašīnas maršrutēšanas politika jau sūta visu tunelī, kā tieši atzīmēts pieprasījums paliek tā iekšienē, jo starpniekservera izvēle un maršrutu tabula ir dažādi lēmumi, kas pieņemti dažādos slāņos.

Nosaukumu atrisināšana ir trešais atsevišķais jautājums. Izvēle, kuri pieprasījumi iet uz starpniekserveri, neko nepasaka par to, kurš risinātājs uz tiem atbild, un abu uztveršana kā vienu iestatījumu rada noplūdes, kas ir neredzamas, līdz kāds pārbauda no ārpuses. Izlemiet, kur tiek atbildēts uz katru vaicājumu, un pierakstiet šo lēmumu blakus starpniekservera noteikumam. Risinātājs, kas mainās tāpēc, ka tunelis pacēlās, klusi pārvietos atbildi.

Pārbaudīt abus ceļus, ne tikai laimīgo

Pārbaudiet resursdatora nosaukumu, kuram vajadzētu saskaņoties, nosaukumu, kuram nevajadzētu, un domēna virsotni, jo virsotne ir gadījums, ko noteikums tikai ar sufiksu visbiežāk palaiž garām. Pēc tam apstipriniet, kuru ceļu katrs pieprasījums patiešām gāja, tā vietā lai secinātu no tā, vai lapa ielādējās.

Visbeidzot, pārbaudiet kļūmes atzaru. Nesasniedzamam starpniekserverim vajadzētu neizdoties tā, kā jūs iepriekš izlēmāt, nevis klusi atgriezties pie tieša savienojuma. Tīkla opciju uzziņa precīzi dokumentē maršruta parametrus; šī dizaina domēna puse dzīvo pilnībā ārpus tās.

Saistītie raksti