Kial UDP-respondo de OpenVPN foriras de la malĝusta adreso

Kliento de OpenVPN alvokas unu adreson, la servilo respondas el alia, kaj la tunelo neniam ekfunkcias. La servila protokolo montras la paketon alvenantan kaj kaptaĵo montras respondon forirantan, do la fiasko estas riproĉata al la kliento. Sur gastiganto kun pluraj interfacoj, aŭ pluraj adresoj sur unu interfaco, la du flankoj simple malkonsentas pri tio, kiu adreso estas uzata. La respondo validas je la IP-nivelo, tamen multaj klientoj forĵetas datagramon kies fonto ne estas la adreso, kiun ili alparolis.

Kion la kliento vidas kiam la fonto ŝanĝiĝas

UDP-ingo ne ligita al specifa loka adreso havas neniun fiksan fonton, do la kerno elektas unu ĉe sendado. Tiu elekto venas el vojserĉo al la adreso de la kliento, kaj la fonto fariĝas la adreso de la interfaco, kiun la serĉo elektas. Sur unuinterfaca maŝino la elekto estas nevidebla; sur gastiganto kun administra adreso, publika adreso kaj duaranga adreso sur la sama retkarto, ĝi dependas de vojaj metrikoj kaj politiko. Politika vojigo igas la malkongruon pli probabla anstataŭ malpli, ĉar regulo povas elekti suprenligon, kiun la kliento neniam atingis. Sufiĉas apriora vojo lernita de unu provizanto plus fonta regulo montranta al alia.

Klientoj, kiuj filtras respondojn, kaj konekta spurado, kiu atendas la ĝustan kvaropon kaj la fonton, forĵetos la respondon sen utila mesaĝo. Tiam la tunelo finiĝas kvazaŭ nenio alvenis, kaj tial tio estas erare prenata kiel fajromura problemo ĉe la klienta flanko. Kaptaĵo prenita nur sur la servilo konfirmas la eraron anstataŭ klarigi ĝin, ĉar la respondo vere foriras. Komparu la fonton de la respondo kun la adreso, kiun la kliento alvokis, antaŭ ol ŝanĝi ion alian.

Kion la opcio multihome efektive faras

La direktivo estas skribata kiel multihome en agorda dosiero kaj kiel --multihome en la komandlinio, kaj ĝi igas UDP-servilon respondi el la adreso, kiun atingis la paketo de la kliento. La kerno transdonas la originan celadreson kiel flankan datumon ĉe ricevo, kaj OpenVPN uzas tiun valoron kiel fonton de la respondo. Tiel servilo aŭskultanta sur ĵokera adreso, local 0.0.0.0 por IPv4 aŭ ĝia IPv6-ekvivalento, kondutas kvazaŭ ĉiu kliento atingis dediĉitan aŭskultanton. Klientoj, kiuj venis tra la publika adreso, ricevas respondojn el la publika adreso, kaj klientoj sur interna adreso ricevas ilin el tiu. Nenio alia en la paketa vojo moviĝas: la vojo, la filtroreguloj kaj la tunela agordo restas precize kiel ili estis.

Ĝuste tiu lasta eco estas la kialo, ke la opcio estas sendanĝera aldoni al alie funkcianta servilo, kaj ankaŭ la kialo, ke ĝi ne povas ripari filtron, kiu permesas nur unu adreson. La paketo ankoraŭ devas esti akceptita laŭ la vojo, kiun ĝi sekvas, do la fonta korekto ŝanĝas la originon de la respondo kaj nenion pli. Ĝi ankaŭ estas nur por UDP: TCP-aŭskultanto ne havas ĉi tiun problemon en la sama formo, ĉar la konekto estas identigata per la kvaropo anstataŭ per la fonta adreso de la respondo.

Kiam fiksa loka adreso estas la malĝusta aprioro

Antaŭ ol ekposedi la opcion, kontrolu ĉu la servilo ligas unu specifan lokan adreson, ĉar ligita aŭskultanto ĉiam respondas el tiu adreso. Tio estas ĝusta por unuinterfaca enmeto kaj malĝusta tuj kiam klientoj laŭleĝe uzas pli ol unu adreson. Se la ligo estis intenca, decidu ĉu la servilo entute akceptu trafikon sur pliaj adresoj. Forigi la ligon pliigas la elmetiĝon, do la permesitajn interfacojn kaj fontajn retojn devas devigi la servo kaj la filtro, ne nur la ligan adreson.

La referenco de OpenVPN limigas la opcion al UDP-serviloj, notadas la plian prilaboradon en la paketa vojo, kaj registras kiujn platformojn subtenas ĝin. Konfirmu tion ĉe la instalita eldono antaŭ ol plani surbaze de ĝi. Kie ĝi ne estas subtenata, la alternativo estas ligi la specifan adreson aŭ ripari la revenan vojon, kaj ambaŭ estas pli mallarĝaj ŝanĝoj ol ili unue ŝajnas. Aŭskultado sur ĵokero ankaŭ havas sekvojn preter respondoj: servilo sur ĉiuj adresoj estas atingebla el ĉiu reto, al kiu la gastiganto estas alkroĉita, kaj tio eble ne estas la elmetiĝo, kiun iu intencis.

Pruvu la fonton de la respondo de ekstere

Testu de ekstere de la servilo, kaj notu la precizan adreson kaj transporton, kiujn la kliento uzis, antaŭ ol kapti ion ajn. La tri sondoj sube respondas tri malsamajn demandojn, kaj la ordo gravas.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

La kaptaĵo montras la fontan adreson en la respondo, kaj tio estas la fakto, sur kiu turniĝas la tuta artikolo. La inga listo montras, kion la servilo efektive ligis, ĉar ĵokera aŭskultanto kaj specifa aŭskultanto aspektas identaj en agorda dosiero kaj kondutas malsame en la reto. La voja serĉo montras la fonton, kiun la kerno elektus por tiu fluo, kaj tio klarigas la kaptaĵon antaŭ ol vi ŝanĝos ion ajn. Ripetu ĉiujn tri por IPv4 kaj IPv6 aparte, ĉar ili estas apartaj aŭskultantoj kaj apartaj serĉoj, kaj ĵokera enskribo por unu familio diras nenion pri la alia.

Vojigo, malkovro kaj filtrado restas apartaj

Konservi la fonton de la respondo ne instalas eliran vojon, ne ĝisdatigas dinamikan DNS, kaj ne igas unu adresan familion akcepti la alian. Sur servilo kun pluraj suprenligoj la reva vojo por ĉiu fonto devas esti intence interkonsentita, alie respondoj foriras tra interfaco, kiun la filtro de la kliento neniam permesis. Same, nova adreso post antaŭfiksa ŝanĝo devas atingi klientojn per malkovro kaj la subtenata rekonekta fluo, ne per la malnova rikordo.

Lasu la servilajn identecajn kontrolojn kaj la atestilan kontroladon precize kiel ili estas, ĉar ŝanĝita adreso ne pravigas akcepti nepruvitan partneron. Se la respondo nun foriras el la celita fonto kaj la tunelo ankoraŭ malsukcesas, konsideru la fontan problemon solvita kaj pluiru. La sekva observata eraro apartenas al vojigo, filtrado aŭ aŭtentigo, kaj denova ŝanĝo de la aŭskultanto ne atingos ĝin. Skribu la fonton de la respondo en la bileto apud la adreso, kiun la kliento alvokis, por ke la sekva persono povu kontroli la saman fakton per unu komando.