VPN-kliento sur LAN-servilo: kial respondoj foriras la malĝustan vojon

La simptomoj sekvas unu formon: gastiganto funkcias, poste ĝi konektiĝas al VPN kiel kliento, kaj nun LAN-klientoj atingas ĝin dum ĝiaj respondoj malaperas. Kaptaĵo sur la gastiganto montras, ke la respondoj foriras tra la tunela aparato anstataŭ tra la LAN-interfaco. Nenio en la tunelo estas difektita, kaj la solvo estas itinero, ne rekonekto. Trapasu la kvar kontrolojn sube laŭ ordo kaj haltu ĉe la unua, kiu malsukcesas.

Respondo estas nova pako, ne renversiĝo

Helpas forlasi la ideon, ke respondo vojaĝas reen laŭ la vojo, kiun prenis peto. Enkursigo estas decidita laŭpake kaj laŭdirekte sur la senda gastiganto. Peto, kiu alvenis de 10.64.0.23 ene de la tunelo, kreas neniun revenan vojon; kiam la gastiganto respondas, tiu respondo estas komparata kun la tabelo kiel nova pako kaj foriras laŭ tiu itinero, kiu venkas.

Tial plentunela kliento sur maŝino, kiu ankaŭ servas LAN, produktas tian konfuzan fiaskon. La kliento instalas defaŭltan itineron, aŭ la du duonajn defaŭltajn itinerojn, kiujn preferas iuj klientoj, kaj la respondo al LAN-kliento nun kongruas kun la tunelo. Ĝi iras al la provizanto, kiu havas neniun kialon plusendi ĝin, kaj la LAN-kliento vidas tempolimon malgraŭ gastiganto, kiu estas supre kaj respondas loke. La kaptaĵo igas ĝin evidenta, kaj la enkursiga tabelo klarigas ĝin.

Tenu du subretojn en la kapo dum vi legas la ceteron. Unu estas la VPN-adresa baseno, de kiu venas la malproksimaj klientoj, en ĉi tiu ekzemplo 10.64.0.0/24. La alia estas la LAN, kiu devas daŭre funkcii, 172.16.24.0/24 kun sia enkursigilo ĉe 172.16.24.1. La eraro estas, ke trafiko inter ili estas decidita per la defaŭlta itinero.

Pruvu ĝin per la kaptaĵo kaj la serĉo

Antaŭ ol ŝanĝi ion ajn, konfirmu, kiun aparaton la respondo uzos. Serĉo estas pli rapida ol kaptaĵo kaj respondas ĝuste la demandon, kiun la kerno respondos kiam la pako estas konstruata.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Legu la respondon en du partoj. Se ĝi nomas dev tun0, la gastiganto enkapsuligos la respondon kaj transdonos ĝin al la provizanto, kaj la LAN-kliento neniam vidos ĝin. Se ĝi nomas dev eth0 sed la kliento ankoraŭ ricevas tempolimon, la itinero jam estas ĝusta kaj la pako estas forĵetata pli poste, kio estas alia problemo kun alia solvo.

La kaptaĵo en la sama paŝo solvas la dubon, kiun ping ne povas. Eĥa respondo alvenanta al la LAN-kliento pruvas, ke iu vojo funkcias, ne kiun interfacon ĝi portis, do faru la kaptaĵon sur la gastiganto mem kaj observu, de kie la kadroj foriras. Presilo en la sama subreto daŭre respondas, ĉar ĝia rekta itinero estas pli specifa ol la defaŭlta itinero de la tunelo. Plusendita pordo malsukcesas ĝuste kiel ĉiu alia fluo, ĉar la tabelo elektas la interfacon kaj ne la konekto.

Instalu la plej mallarĝan itineron, kiu superas la tunelon

Decidas la prefiksa longo, ne la metriko, do itinero por la klienta baseno tra la LAN-enkursigilo venkas ajnan defaŭltan itineron, kiun la VPN-kliento instalas. Metrika kirurgio ne necesas, kaj la defaŭlta itinero povas resti ĝuste tie, kie la kliento metis ĝin.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Uzu replace anstataŭ add, ĉar kliento, kiu rekonektiĝos, estos instalinta sian propran rikordon kaj dua add malsukcesas per eraro pri ekzistanta itinero, kiu legiĝas kiel permesa problemo. Sur Windows-gastiganto la ekvivalento estas route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, kie -p konservas la rikordon trans restartigoj, ĉar la kliento povas rekonstrui la tabelon kiam la tunelo releviĝas. Sur nuntempa Windows-gastiganto la subtenata ekvivalento estas New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, kun la pli malnova komando route konservata kiel malnova formo.

Unu detalo decidas, ĉu tio estas ĝusta aŭ nur kredinda: la sekva salto devas esti la enkursigilo, kiu efektive posedas la vojon reen al la klientoj. Montri la itineron al adreso, kiu mem estas atingata tra la tunelo, kreas buklon, kiu aperas kiel intermita perdo anstataŭ pura fiasko. Konfirmu, ke la sekva salto estas en la LAN-subreto antaŭ ol enigi la linion.

Konservu la respondon post rekonekto

Itinero aldonita mane pluvivas plej bone ĝis la sekva rekonekto. Se la klienta baseno estas dinamika, fiksu ĝin en la servila agordo, por ke la prefikso, kiun vi enkursigis, restu la prefikso, kiun klientoj ricevas; alie la rikordo montras al malplena gamo kaj la simptomo revenas semajnojn poste sen evidenta kaŭzo. Skribi la itineron en la propran up-skripton de la kliento estas la alia fidinda opcio, ĉar ĝi ruliĝas post kiam la kliento reskribis la tabelon.

Stathava fajroŝirmilo ankoraŭ povas venki ĝustan itineron. Se la kaptaĵo nun montras, ke la respondo foriras tra eth0, kaj la kliento ankoraŭ ricevas tempolimon, kontrolu, ĉu la gastiganto forĵetas la pakon antaŭ ol sendi ĝin. Strikta inversa voja filtrado kaj net.ipv4.conf.all.rp_filter agordita al 1 forĵetas pakojn, kies fonto ne estus enkursigita reen tra la interfaco, per kiu ili alvenis, kio estas ĝuste la nesimetria kazo, kiun vi ĵus kreis kaj poste riparis, kaj la stato de conntrack rakontas la saman historion por plusenditaj pordoj.

La lasta kontrolo estas tiu, kiun homoj preterlasas: ripetu la serĉon post kiam la tunelo estis malsupre kaj denove supre. Kvar valoroj devus kongrui kun tio, kion vi notis: la celo, la sekva salto, la aparato kaj la elektita fonto. Se iu el ili moviĝis, la kliento reskribis la tabelon kaj la solvo apartenas al ĝiaj hokoj, ne al ŝela historio.