Plena tunelo mortigis vian SSH-sesion: fiksu la revenan itineron
Plena tunelo ankaŭ kaptas la respondojn al via propra SSH-sesio. Fiksu gastigan itineron por via administra adreso tra la malnova enirejo, kaj reinstalu ĝin ĉe rekonekto.
Startigu OpenVPN klienton sur la maŝino, ĉe kiu vi laboras per SSH, kaj meze de la komando la sesio frostas. La tunelo raportas sin konektita, la gastiganto atingas la interreton tra ĝi, kaj viaj klavopremoj ankoraŭ alvenas dum nenio revenas. Tio, kio ŝanĝiĝis, ne estas la tunelo: temas pri la reena vojo por pakaĵoj adresitaj al vi, kiu nun kongruas kun la nova implicita itinero kaj eniras tunelon, kiun la fora enirejo ne uzos por atingi vian skribotablon.
Kion redirect-gateway efektive instalas
En sia def1 formo redirect-gateway aldonas 0.0.0.0/1 kaj 128.0.0.0/1 anstataŭ anstataŭigi la implicitan itineron. Tiuj du duonoj kovras la tutan adresan spacon, dum ambaŭ restas pli longaj prefiksoj ol 0.0.0.0/0, do ĉiu celo sen pli specifa kongruo nun iras en la tunelon. Tio estas la mekanismo, kiun oni tenu, ĉar ĉiu riparo sube funkcias per instalado de pli specifa kongruo.
Via administra adreso estas unu el tiuj celoj.
La VPN-servilo plusendas trafikon de siaj klientoj al la interreto. Ĝi havas neniun itineron por la publika adreso, de kiu vi konektiĝas, nek kialon trakti tiujn pakaĵojn kiel ion alian ol trafikon alvenantan de kliento, do ĝi faligas ilin. Dume la peto, kiun vi sendis, tamen atingis la gastiganton, kaj tial la sesio ŝajnas viva nur unuflanke.
ip route show table main | head -n 20
ip route get 198.51.100.23Trovu vian fontan adreson kaj la vojon antaŭ la tunelo
Sur la servilo, listigu la establitan SSH-konekton kaj notu la samtulan adreson, de kiu ĝi venis. Tiu adreso estas tio, kion via reena itinero devas kovri, kaj ĝi ne ĉiam estas tio, kion vi pensas: saltgastiganto, NAT-enirejo aŭ tradukilo de la operatoro povas anstataŭigi alian fonton.
Poste trovu la fizikan enirejon kaj la interfacon, kiuj portis trafikon antaŭ ol la tunelo ekfunkciis. En la def1 aranĝo la implicita itinero ankoraŭ ĉeestas sub la duon-implicitaj, do la informo disponeblas, kvankam legi longan itineran tabelon per okulo invitas erarojn.
Notu ambaŭ valorojn kaj la interfacan nomon kune, ĉar la itinero, kiun vi baldaŭ aldonos, bezonas ĉiujn tri. Se la gastiganto uzis politikan enkursigan regulon por elekti sian supran ligon, ordinara itinero eble tute ne estos konsultita, kaj tiu ebleco ŝanĝas la riparadon.
Fiksu gastigan itineron, kiu superas la duon-implicitajn
Itinero /32 estas pli longa ol ĉiu el la du duon-implicitaj, do respondoj al via adreso prenas ĝin anstataŭ la tunelo. La sekva salteto estas la enirejo antaŭ la tunelo kaj la aparato estas la fizika interfaco, kio tenas la pakaĵon sur la vojo, kiun ĝi uzis antaŭ ol ekzistis la tunelo.
ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0Kontrolu per serĉo anstataŭ per inspektado de la tabelo: la respondo devas nomi eth0 kaj la enirejon, neniam tun0.
OpenVPN jam aldonas gastigan itineron al la propra adreso de la VPN-servilo pro la sama kialo, do la ŝablono estas konata kaj la administra adreso estas simple plia escepto. Ne prenu route-nopull por ripari tion, ĉar ĝi forĵetas la puŝitajn itinerojn, kiujn la tunelo bezonas, inkluzive la foran reton kaj la DNS-opciojn.
Igu ĝin postvivi rekonekton
Itinero aldonita permane malaperas, kiam la kliento rekonektiĝas kaj reinstalas sian propran, kio transformas riparadon en revenantan interrompon. Ligigu la komandon al io, kio ruliĝas post kiam la itineroj estas instalitaj.
Kaj route-up skripto kaj la pre-up hoko de la retadministrilo funkcias, kaj la fidinda kontrolo estas rekonekto sekvata de la sama serĉo.
En Windows la ekvivalento estas persista itinero aldonita per -p, kiu postvivas restartigojn sed ankoraŭ devas montri al la ĝusta enirejo post reta ŝanĝo. Sendepende de la platformo, skribu la kialon apud la itinero: la sekva administranto devas scii, ke ĝi ekzistas por protekti administran sesion, ne ĉar la reta dezajno postulis ĝin.
Kiam fiksita itinero ankoraŭ ne sufiĉas
Filtrado de la reena vojo povas faligi pakaĵon, kiu alvenas sur unu interfaco kaj foriras per alia, kaj ĝuste tion kreas fiksita itinero. Kontrolu la efektivan valoron de rp_filter antaŭ ol malŝalti ion tutmonde, kaj preferu ripari la nesimetrion anstataŭ malŝalti la kontrolon. Aplikatas la agordo por ĉiu interfaco, kaj la loza reĝimo ofte nur registras la nesimetrion anstataŭ faligi la pakaĵon. Legu ambaŭ antaŭ ol konkludi, ke la filtrilo estas via kulpo.
Gastigantoj kun politika enkursigado bezonas regulon same kiel itineron, ĉar la regula bazo elektas la tabelon antaŭ ol la itinero ene de ĝi estas konsultita. Itinero en la tabelo main estas nevidebla por fluo, kiu kongruas kun regulo montranta al alia tabelo. Legu la regulojn antaŭ ol aldoni ion al main. Se regulo jam kovras administran trafikon, la escepto apartenas al la tabelo de tiu regulo.
Tenu ekster-bandan konzolon malfermita dum vi testas, kaj rekontrolu de dua saluto antaŭ ol malkonekti tiun, kiun vi uzas. Itinero, kiu sendas vian propran administran trafikon en la tunelon, tranĉas la konekton, per kiu vi ripariĝas. Reeniri tiam signifas serian konzolon aŭ savan lanĉon, kio estas malbona interŝanĝo por preterlasi unu kontrolpaŝon.