Retservilo malaperas kiam la VPN-kliento konektiĝas

Servo, kiu malaperas en la momento, kiam VPN-kliento konektiĝas, kutime ne estas blokata, ĝi respondas tra la malĝusta interfaco. La peto alvenas sur la fizikan retkarton, la daemono skribas respondon, kaj la enkursigada tabelo transdonas tiun respondon al la tunelo, ĉar la tunelo transprenis la implicitan itineron. La fora kliento neniam vidas respondon al konekto, kiun ĝi malfermis, do ĝi atendas kaj poste raportas tempolimon. Neniu fajroŝirma regulo partoprenas ie ajn en tiu sinsekvo.

La simptomo: petoj enen, respondoj eksteren tra la malĝusta pordo

La signo estas envenanta konekto, kiu malsukcesas dum ĉio alia sur la gastiganto funkcias. Plia indiko estas gastiganto atingebla el la LAN sed ne el la interreto, aŭ unu kiu funkcias ĝis la tunelo rekonektiĝos kaj poste haltas. En ĉiu kazo la antaŭa direkto funkciis kaj la revena ne, kio indikas enkursigadan malsimetrion prefere ol politikon.

Konfirmu ĝin observante, kien iras la respondo, ne observante, kiel alvenas la peto.

Kaptu samtempe sur la fizika interfaco kaj sur la tunela aparato. Se la peto aperas sur la fizika interfaco kaj la respondo sur la tunelo, la diagnozo estas finita. Respondo, kiu aperas nenie, signifas ke la servo neniam akceptis la konekton, kio estas aparta esploro kun aparta kaŭzo.

Du implicitaj itineroj kaj unu enkursigada decido

Kliento, kiu instalas implicitan itineron, aldonas duan rikordon kun pli bona metriko ol la LAN-pordego. Iuj klientoj anstataŭe instalas du duon-gamajn itinerojn, kiuj kovras la saman spacon pli specife kaj gajnas la serĉon same. Ambaŭ teknikoj lasas ordinarajn elirantajn pakojn elekti la tunelan interfacon.

Tiu elekto fariĝas nur laŭ celo. La kerno ne demandas, de kie venis pako, krom se politika regulo ordonas al ĝi. Do la respondo al publika klienta adreso estas transdonata al la tunelo, kies fora fino ricevas pakon kun fonta adreso, kiun ĝi ne posedas, kaj forĵetas ĝin aŭ plusendas ĝin ie senutile. En Linux, strikta inversvoja filtrado ankaŭ povas forĵeti la originan peton antaŭ ol via servo eĉ vidos ĝin, kio de ekstere aspektas idente. Ambaŭ simptomoj venas de la sama mankanta ligo inter envenanta fluo kaj ĝia respondo.

La tunelo kondutas ĝuste la tutan tempon. Oni diris al ĝi porti la implicitan itineron kaj ĝi faras ĝuste tion.

Riparu la revenan vojon sen rompi la tunelon

Ekzistas tri daŭraj formoj de riparo, kaj la elekto dependas de tio, kiom da propra trafiko de la gastiganto devas resti ene de la tunelo. Ekskludi la celon aŭ pordon de la servo estas la plej malgranda ŝanĝo. Politika enkursigado laŭ fonto aŭ marko estas la plej preciza. Fonta traduko estas la plej kruda kaj la plej facile klarigebla post du jaroj.

Elektu laŭ tio, kion la gastiganto devas fari, ne laŭ tio, kiun fragmenton vi trovis unue.

Ekskludi celon taŭgas por servo kun stabila publika adreso, kaj ligi la daemonon al la fizika adreso anstataŭ al ĉiu adreso faras tiun ekskludon pli sekura. Politika regulo, kiu elektas tabelon laŭ fonto, tenas la proprajn konektojn de la gastiganto ene de la tunelo dum ĝi resendas la respondojn de la servo tra la WAN-pordego. Maskado de respondoj al la WAN-interfaco atingas la saman vojon je la kosto kaŝi la adreson de la kliento el la protokoloj de la servo. Adhoka ŝanĝo de la implicita itinero estas diagnozo kaj ne agordo, ĉar la kliento reskribas itinerojn ĉe ĉiu rekonekto.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Kiam la gastiganto ankaŭ enkursigadas por LAN malantaŭ ĝi

Unu salteto pli ekstere, la sama malsimetrio revenas kun pli da movaj partoj. Trafiko alvenas al la enkursigilo el la interreto, estas plusendata al interna aparato, kaj la sola revena vojo de tiu aparato estas la tunelo, do la respondo alvenas al la originala kliento el la adreso de la provizanto mem. Tiam konekta spurado renkontas respondon por fluo, kies komencon ĝi ne vidis, kaj forĵetas ĝin. La kliento dume vidas tute nenion.

Du ŝanĝoj riparas ĝin: cella traduko por ke la envenanta konekto atingu la internan aparaton, kaj fonta traduko por ke la respondo de tiu aparato ŝajnu veni de la enkursigilo mem.

En la firmvaro de enkursigiloj la kutima esprimo estas politika regulo, kiu fiksas la pordplusendadon al la WAN-flanko dum la propra trafiko de la enkursigilo veturas tra la tunelo. Sen fonta traduko, tiu respondo estas adresita al la ekstera kliento kaj la interna aparato simple ne havas itineron al ĝi. Testu tri aferojn aparte, ĉar ili malsukcesas pro malsamaj kialoj: konekton alvenantan de ekstere, unu kiun la gastiganto mem komencas, kaj nomserĉon.