Kion OpenVPN route-nopull vere malhelpas la servilon puŝi

Vi metis route-nopull en klientan profilon por malhelpi la tunelon engluti vian defaŭltan itineron, kaj nun la oficeja subreto estas neatingebla dum la kliento ankoraŭ diras, ke ĝi estas konektita. Ambaŭ observoj veras, kaj nenio malsukcesis. La flago diras al la kliento preterpasi la itinerojn kaj DHCP-rikordojn, kiujn la servilo puŝas, kio estas pli mallarĝa instrukcio ol plej multaj homoj atendas, kiam ili aldonas ĝin. Kio restas, estas funkcianta tunelo sen opinio pri tio, kiuj celoj uzu ĝin.

Tiu breĉo estas la tuta decido, pri kiu temas ĉi tiu artikolo. Aŭ la servilo priskribas la reton, aŭ la kliento faras tion, kaj la flago transdonas tiun laboron al la kliento sen fari ion ajn el ĝi por vi.

Kion la flago malŝaltas ĉe konektiĝo

Kliento de OpenVPN, kiu tiras, kutime ricevas de la servilo post aŭtentigo pakaĵon: itinerojn, alidirektigon de la defaŭlta pordego, DNS-servilojn kaj kelkajn agordajn direktivojn. Kun route-nopull en efiko la kliento ankoraŭ akceptas la sesion, ankoraŭ kontrolas atestilojn, ankoraŭ intertraktas ĉifrojn kaj keepalive, kaj ankoraŭ suprenigas la interfacon. Kion ĝi forĵetas, estas la apliko de puŝitaj route-linioj kaj puŝitaj dhcp-option-linioj, inkluzive de DNS.

La konfuzo venas de verda indikilo apud morta aplikaĵo. La tunelo ekzistas; la mapo de celoj al tiu tunelo ne. Nenio en la statusa panelo de la kliento distingas «konektita kaj enkursiganta» de «konektita kaj senefika», ĉar de la vidpunkto de la tunelo ambaŭ estas la sama stato.

Kial viva tunelo tamen povas enkursigi nenion

La interfaco aperas kun sia propra adreso kaj, ĉe punkto-al-punkta ligo, ofte havas nenion pli specifan ol gastigantan itineron al la kunulo. Privata subreto atingeblas nur, kiam iu itinero montras al tiu interfaco kun la ĝusta prefikso, kaj kun la puŝado malŝaltita tiu itinero neniam alvenas. Ankaŭ la elŝutita profilo kutime ne povas helpi, ĉar ĝi estis skribita laŭ la supozo, ke la servilo provizu ĝuste ĉi tiun informon. Tial la interfaco povas aspekti sana dum la subreto restas malluma.

Legi la profilon do pruvas tre malmulte. Legu la kurantan staton anstataŭe, sur la konektita maŝino:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Adreso sen subreta itinero en la dua komando estas la signo de ĉi tiu problemo. La tria komando tiam respondas la demandon, pri kiu uzantoj vere zorgas, ĉar ĝi raportas la interfacon, kiun la kerno elektus por specifa celo, anstataŭ la liston, kiun vi esperis, ke ĝi uzu. Se ĝi respondas tra via fizika ligo, la tunelo tute ne estas en la vojo.

Noma solvado malsukcesas pro rilata kaŭzo, ne pro aparta. Puŝitaj dhcp-option DNS-rikordoj estas preterpasataj de la sama flago, do demandoj pri internaj gastigantoj iras al kiu ajn solvilo, kiun la loka reto provizis. Tiu solvilo ne havas zonon por la oficejo, do la demando malsukcesas aŭ redonas publikan respondon, kaj la paneo aspektas kiel servila problemo, dum ĝi estas klienta agorda problemo. Testi adreson antaŭ nomo estas tio, kio apartigas la du.

Elekti inter la flago kaj prefiksa filtrilo

La du opcioj solvas malsamajn formojn de la sama plendo, kaj malbona elekto estas tio, kio produktas la staton konektita-sed-senutila. Unu anstataŭigas la puŝitan politikon tute, dum la alia redaktas ĝin laŭ prefikso. La tabelo donas la mallongan version, kaj la alineo post ĝi kovras la parton, kiu kaptas homojn.

pull-filter estas prefiksa kongruigilo kun tri verboj, do ĝi povas akcepti familion de linioj, silente ignori ilin aŭ tute rifuzi la konekton, kiam prefikso aperas. Tiu lasta konduto estas la inda scii: rifuza regulo igas politikan malkonsenton malsukcesa manpremo anstataŭ silenta preterlaso. La manlibro de OpenVPN 2.6 listigas la akceptitajn prefiksojn kaj la precizan semantikon de ĉiu verbo.

Komuna meza vojo estas rifuzi nur redirect-gateway kaj lasi la oficejajn itinerojn kaj DNS alveni laŭintence. Tio tenas la puŝadon funkcianta por la partoj, kiujn la servilo komprenas pli bone ol vi, samtempe malhelpante la unu linion, kiu transprenus vian defaŭltan itineron.

Aldoni itinerojn kaj solvilon permane

Se vi konservas la flagon, la profilo devas diri tion, kion la servilo dirus. Klientflankaj route-direktivoj aplikiĝas post kiam la konekto establiĝis, do ili funkcias apud la flago anstataŭ esti blokitaj de ĝi. Metu ilin en la profilon, ne en interagan komandlinion, alie la sekva rekonekto ne reproduktos la funkciantan staton.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

La DNS-linio staras en maloportuna pozicio: ĝi estas klientflanka direktivo, sed iuj klientoj aplikas ĝin nur per la DNS-integriĝo de la platformo, kiu povas anstataŭigi ĝin, kiam la ligo ŝanĝiĝas. Ĉe systemd-gastiganto, difini la solvilon rekte sur la tunela interfaco estas pli antaŭvidebla ol esperi, ke la kliento gajnos la prioritatan konkuradon:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

La enkursiga domajno gravas tiom kiom la adreso. Sen ĝi, demandoj pri publikaj nomoj ankaŭ povas esti senditaj al la interna solvilo, kaj ajna interna solvilo, kiu rifuzas rikuron, rompos retumanadon dum la privata zono restas funkcianta. Kun ĝi, nur nomoj sub tiu sufikso enkursiĝas al la tunela solvilo kaj ĉio alia sekvas la fizikan ligon.

Kontroli la rezulton: adreso, nomo kaj la ekstera vojo

Tri testoj apartigas la eblajn paneojn. Prenu la privatan adreson per IP, poste la saman gastiganton per nomo, poste ordinaran publikan retejon. Funkcianta IP kun malsukcesa nomo montras al la solvilo; malsukcesa IP kun funkcianta nomo montras al enkursigado; se ambaŭ malsukcesas, kutime la tunelo ne estas en la vojo.

Poste rigardu eksteren anstataŭ internen. La propra itinero de la tunela finpunkto devas postvivi la ŝanĝon, kaj ajna blokado devas esti limigita al la tunelo sen kapti la finpunkton. Kliento, kiu daŭrigas retumanadon post kiam la tunelo falas, estas politika problemo, ne enkursiga, kaj ĝi ne aperos en iu el la tri testoj supre.

Skribu la finan liston en la dokumentaron de la profilo: la itinerojn, la solvilon, la domajnojn kaj la kialon, kial ĉiu ekzistas. Rekonekto, kiu reproduktas la saman tabelon, estas la sola pruvo, ke la loka politiko estas kompleta. Se aplikaĵoj ankoraŭ malsukcesas kun la tunelo supren kaj ĉiuj tri testoj trapasitaj, la sekva loko rigardi estas la klaso de problemoj konektita-sed-senreta, ne atestiloj, kiuj jam estis kontrolitaj.