Sama servila IP, du vojoj: marki la eksteran fluon de OpenVPN

La kutima bukla protekto estas gastiga vojo: sendu trafikon al la publika adreso de la VPN-servilo eksteren per la suprenligo, por ke la ĉifrita seanco neniam eniru sian propran tunelon. Tio funkcias ĝuste ĝis la momento, kiam vi ankaŭ volas atingi retservon sur la sama servilo tra la tunelo, ĉar la escepto ligiĝas al la celo kaj la celo estas identa. La eliro estas ĉesi klasifiki laŭ celo kaj komenci klasifiki laŭ tio, kiu ingo sendis la paketon.

Komencu per la du fluoj, kiujn vi volas apartigi

Unu fluo estas la ĉifrita OpenVPN-transporto mem, kiu devas eliri per la suprenligo, alie la tunelo portus sian propran eksteran konekton. La alia estas ordinara HTTPS-peto al la sama publika adreso, kiun vi volas ene de la tunelo, por ke ĝi alvenu al la servo el tunela fonto. Sama celo, multfoje sama porthumero, malsama bezonata vojo.

Por ĉi tiu trairado, supozu klienton ĉe 10.90.0.10 sur tun1, publikan servilan adreson de 198.51.100.25 kaj netuŝitan ĉefan tabelon, kies defaŭlto montras al la ordinara suprenligo. La servila flanko ankaŭ devas akcepti la retservon sur la interna vojo kaj resendi trafikon al la tunela fonto; sendi paketon al publika adreso ne superregas la aŭskultanton aŭ fajroŝirmilan politikon de la servilo.

Antaŭ ol ŝanĝi ion, registru la nunajn regulojn de la gastigo kaj elektu valorojn, kiujn neniu alia uzas: markon, tabelnumeron kaj tri regulprioritatojn. Konservu vojon reen en la maŝinon, kiu ne iras tra ĉi tiu konekto, ĉar eraro ĉi tie forigas vian propran malproksiman aliron anstataŭ nur rompi retumilan langeton.

Marku la ingon, kiu portas la koverton

La klienta agordo ricevas markon por siaj ĉifritaj elirantaj paketoj kaj ĉesas mem instali vojojn, por ke la anstataŭa politiko estu la sola, kiu decidas vojojn:

mark 42
route-noexec
disable-dco

La dekuma 42 estas deksesuma 0x2a, kaj la deksesuma formo estas tiu, kiun la enkursigaj reguloj kongruos. La referenco pri link-options priskribas mark kiel ion, kio aplikiĝas al ĉifritaj elirantaj paketoj sur Linukso, do ĝuste al la ingo, kies vojon vi devas kontroli. Malŝalti la datumkanalan malŝarĝon tenas ĉi tiun ekzemplon sur la uzantspaca vojo, kie la marka konduto estas tiu priskribita.

route-noexec subpremas la aŭtomatajn aldonaĵojn kaj forigojn de vojoj de OpenVPN. Ĝi instalas nenion anstataŭe, do de ĉi tiu momento la vojposedanto devas prizorgi ĉiun vojon, kiun la tunelo bezonas. Se privata celo malaperas post la ŝanĝo, tio estas la mankanta anstataŭa politiko, ne difekto en la marko.

Ne konservu gastigan vojon en la ĉefa tabelo por 198.51.100.25 dum vi faras tion. Tia vojo reenkondukas ĝuste la escepton, kiun la dezajno provas mallarĝigi, kaj ĝi venkos por la HTTPS-fluo antaŭ ol iu el la subaj politikoj estos konsultita.

Sendu ĉion alian al la tunela tabelo

Post kiam la tunela interfaco ekzistas kaj tenas sian adreson, la politiko aspektas jene:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

La unua regulo tenas la specifajn vojojn de la gastigo videblaj, inkluzive de ajna aprobita loka reto, dum ĝi faras la defaŭltan vojon de la ĉefa tabelo nevidebla por ĉi tiu serĉo. Tiu distingo gravas: subpremi la defaŭlton ne samas ol ignori la tabelon, kaj la lokaj esceptoj, kiujn vi ankoraŭ bezonas, pluvivas ĝuste pro tio. Legu tiujn esceptojn unu post alia anstataŭ supozi, ke la rezulto estas universala haltŝaltilo.

Nemarkita trafiko tiam falas al la tunela tabelo, prenas la tunelan fonton kaj eliras per la VPN. Markita trafiko malsukcesas la fwmark-teston sur la du sekvaj reguloj kaj daŭrigas al la ordinara ĉefa serĉo pli malsupre en la listo, kie la suprenliga defaŭlto ankoraŭ troviĝas. La fina unreachable-regulo estas tio, kio malhelpas nemarkitan fluon silente refali al la suprenligo, kiam la tunela vojo mankas. La selektilo estas la marko de komenco ĝis fino, kaj la celadreso neniam eniras la decidon.

Tenu tiun gardon en loko tra malkonektoj, kaj instaligu ĝin kun la resto de la politiko anstataŭ mane. Regulo, kiu malaperas kun la interfaco, ne estas politiko, ĝi estas koincido. Forigi la politikon, kiam la tunelo falas, ŝanĝas la fiaskmanieron de „blokita” al „likinta”, kaj malnova tunela vojo, kiu eksvalidiĝas poste, estas multe pli facile klarigebla problemo ol trafiko, kiu eliris per la malĝusta interfaco.

Lasu la revenan vojon vidi la saman markon

Elirantaj markoj estas nur duono de la mekanismo, kaj ĉi tio estas la parto, kiun plej multaj reproduktaĵoj preterlasas. Respondoj al la ĉifrita seanco alvenas per la suprenligo kaj estas submetitaj al validigo de la reena vojo, kiu demandas, ĉu la fonto estus enkursigita reen laŭ la sama vojo, laŭ kiu ĝi venis. Sen helpo, tiu serĉo aplikas vian nemarkitan tunelan politikon kaj konkludas, ke la paketo estas sur la malĝusta interfaco.

La korekto apartenas al la fajroŝirmila posedanto: konservu la markon sur la elira konekto, restarigu ĝin sur kongruajn enirajn paketojn kaj ŝaltu fontvalidigitan markotraktadon por la koncerna vojo. Tio, ke OpenVPN starigas ingomarkon, faras neniun el tiuj tri aferoj, kaj recepto, kiu listigas nur la klientajn opciojn, estas nekompleta. Petu tiun integriĝon skribe, ĉar ĝi estas la plej malmulte videbla parto de la dezajno kaj la plej facile perdebla en rekonstruo.

Ankaŭ la loza reena-voja kontrolo ne estas anstataŭaĵo. Loza reĝimo ankoraŭ bezonas, ke ekzistu iu vojo por la fonto, kaj la unreachable-gardo, kiun vi aldonis, intence forigas unu por nemarkitaj serĉoj. Finu kaj reviziu la integriĝon de la konekta marko antaŭ ol fidi ĉi tiun dezajnon, kaj traktu gastigajn filtrilojn kiel apartan demandon: marko estas enkursiga signalo, ne permeso. Se la integriĝo mankas, la simptomo estas seanco, kiu establiĝas kaj poste silentas tuj kiam respondoj komencas alveni.

Pruvu ĝin per du vojserĉoj

Komparu tion, kion la kerno decidas por la du kuntekstoj, kaj legu la kampojn dev kaj src anstataŭ la elirstaton:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

La unua serĉo devus solviĝi al tun1 kun la tunela fonto, kaj la dua al la suprenligo. Ĝi estas sintezaj serĉoj, do ili pruvas la politikon kaj ne la vivantan procezon: konfirmu aparte la efektivan transportan vojon de la kuranta kliento, poste faru realan HTTPS-peton kun ŝaltita atestila kontrolo.

Notu, kion la dezajno ne kovras antaŭ ol deklari ĝin finita. DNS, IPv6 kaj la vivociklo de la reguloj bezonas ĉiu sian propran decidon, kaj ĉi tio estas IPv4-enkursiga ekzemplo anstataŭ kompleta privateca agordo. Ĝia valoro estas la selektilo: la koverto ricevas la suprenligan escepton, kaj ordinara servo ĉe la sama adreso ne devas heredi ĝin.