route-gateway ne estas redirect-gateway: kio efektive ŝanĝiĝas

Via tunelo ekfunkcias, la privata subreto respondas, kaj ordinara retumado ankoraŭ malaperas en la VPN eĉ kvankam iu forigis la enirejan linion el la profilo. Tiu kombinaĵo estas la fingropremo de la malĝusta direktivo, kiu estis redaktita. Tio, kio estis forigita, donis al la kliento sekvan salteton por itineroj, kiujn ĝi instalas; tio, kio daŭre kaptis trafikon, venis de aliloke kaj estis puŝita de la servilo. Kovrado kaj sekva salteto estas apartaj taskoj, kaj nur unu el ili decidas, ĉu publikaj celoj uzas la tunelon.

La linio, kiun vi forigis, estis sekva salteto, ne politika ŝaltilo

Ĉiu itinero, kiun la kliento instalas, bezonas enirejan adreson por montri, kaj la enireja direktivo estas la fonto de tiu adreso, kiam itinero mem ne nomas unu. Forigu ĝin kaj tiuj itineroj havas neniun lokon por alligiĝi, do ili aŭ malsukcesas instaliĝi aŭ surteriĝas sur vojo, kiu kondukas nenie. La privata subreto estas ĝuste tio, kion tia itinero portis.

Dume la konduto, kiu postvivis, havas alian aŭtoron: alidirektan opcion en la puŝita bloko, kiu movas ordinaran elirantan trafikon en la tunelon laŭ siaj flagoj. Forigi la enirejon nek malŝaltas nek malfortigas ĝin. La rezulto estas la plej malbona el ambaŭ statoj, kun publika trafiko ankoraŭ kaptita kaj la privata celo, kiu pravigis la tunelon, nun neatingebla. Tial ankaŭ la dua redakto, farita en la sama spirito, ŝanĝas nenion.

Kvar leviloj, kvar malsamaj taskoj

Kvar direktivoj estas citataj interŝanĝe en ĉi tiu diskuto, kaj nur unu el ili regas kovradon, tio estas, kiuj celoj entute estas direktitaj tra la tunelo. Dua fiksas la sekvan salteton, kiun uzas itineroj, tria instalas unu prefikson, kaj kvara forĵetas ĉion, kion la servilo puŝis, inkluzive de la privataj itineroj, kiujn la lanĉo bezonas. La tabelo ordigas ilin laŭ tio, kion administranto provas ŝanĝi, ne laŭ nomo, ĉar la nomoj kaŭzas la konfuzon. Traktu ilin kiel kvar apartajn decidojn kaj elektu tiun, kiun vi vere volas malfari.

En praktiko ĉiuj kvar ofte alvenas en unu puŝita bloko, linio post linio, kio igas ilin aspekti kiel partoj de unu agordo. Ili ne estas, kaj la OpenVPN-referenco dokumentas ilin kiel malsamajn mekanismojn ĝuste pro tio. Eltrovi, kiun decidon vi malfaras, estas la tasko; la redakto estas unu linio.

Filtru la puŝitan linion, konservu la sekvan salteton

Se la kovrado, kontraŭ kiu vi protestas, alvenas kiel puŝita opcio, la mallarĝa respondo estas ignori tiun opcion laŭnome kaj lasi la reston de la puŝita bloko netuŝita. Skribite kiel filtrilo, ĝi aspektas kiel la linio sube, kaj ĝi apartenas al la profilo de la trafita kliento, ne al la servila agordo.

pull-filter ignore "redirect-gateway"

Mallarĝeco estas la punkto. Ĉar la filtrilo komparas tekstan prefikson, pli mallonga ŝablono ankaŭ kongruas kun la direktivo de la sekva salteto, kio forprenas ĝuste la informon, de kiu dependas la privataj itineroj, kaj ripetas la originalan eraron en nova kostumo. Filtrilo ankaŭ efikas nur sur puŝitajn opciojn, do ĝi neniam tuŝas ekvivalentan linion skribitan loke aŭ truditan de retadministranto. Rekonektiĝu poste, ĉar viva seanco ne ree taksas tion, kion la servilo puŝis.

Legu la serĉon, ne la tabelon

Post reŝargi la profilon, demandu la kernon, kien du celoj efektive irus: unu ene de la privata prefikso kaj unu en la publika interreto. Plena eligo de la ĉefa tabelo estas pli malfacile legebla kaj pli facile mislegebla, ĉar itinero povas ekzisti kaj tamen perdi al pli specifa kongruo. Ĉe politika enkursigado la regulo, la tabelo kaj la fonta adreso ankaŭ apartenas al la kontrolo.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

La variaĵo def1 meritas familiarecon, ĉar ĝi lasas la malnovan implicitan enskribon videbla dum paro da duonimplicitaj gajnas la serĉon. Do linio 0.0.0.0/0 en la eligo pruvas nenion per si mem. La serĉo respondas la demandon, kiun la listo nur ŝajnas respondi.

DNS, IPv6 kaj la privata itinero ankoraŭ devas funkcii

Rifuzi unu IPv4-alidirektadon diras nenion pri la solvilo, do puŝita DNS-opcio povas daŭre sendi demandojn en la tunelon dum la itineroj aspektas ĝustaj. IPv6-implicito povas fari la samon por adresfamilio, kiun la IPv4-kontrolo neniam tuŝis. Ambaŭ bezonas eksplicitan decidon anstataŭ supozon. Poste konfirmu, ke la privata servo ankoraŭ respondas, ĉar disigita tunelo, kiu perdis sian privatan itineron, ne estas disigita tunelo, ĝi estas rompita.

Pli larĝa ilo meritas averton: route-nopull forĵetas ĉiun puŝitan itineron kaj ĉiun puŝitan DNS-opcion, kio certe haltigas la plenan tunelon kaj same certe rompas la privatajn itinerojn, de kiuj dependas la lanĉo, do ĝi estas multe pli granda martelo ol nomfiltrilo celita al unu opcio. Kontrolu la privatan celon, publikan celon kaj la solvilon post ĉiu ŝanĝo, kaj traktu kompletigitan manpremon kiel pruvon de nenio krom la manpremo.