VPN konektiĝas sed ne atingas LAN-aparatojn: kion kontroli

Trafiko eniras la tunelon, la pordego respondas ĉe sia propra adreso, kaj nenio malantaŭ ĝi respondas. Tiu ŝablono oftas kaj ĝi ne estas kontraŭdiro: respondo de la pordego pruvas, ke la tunelo finiĝis, kaj ĝi pruvas nenion pri tio, kio okazas al paketo adresita preter ĝi. La du testoj ekzercas malsamajn kodajn vojojn sur la sama maŝino.

De nun testu ion ĉe la alia flanko de la pordego. La propra adreso de la pordego daŭre respondos, kiom ajn difektita la plusendado estos.

La pordego respondas el sia propra stako

Paketo adresita al la pordego estas liverata al ĝia loka eniga vojo, kie la kerno decidas ĉu ĝin akceptas aŭskultanta ingo. Paketo adresita al gastiganto malantaŭ la pordego estas liverata anstataŭe al la plusenda vojo, kie validas alia aro da kontroloj. Plusendado povas esti tute malŝaltita, aŭ la kerno povas ŝalti ĝin kaj poste filtro-regulo, kiu neniam mencias la tunelon, povas malakcepti ĝin. Nenio el tio efikas al la propra respondo de la pordego, tial la simptomo tiel fidinde misgvidas.

Administraj paĝoj atingitaj tra la tunelo ankaŭ apartenas al la unua kategorio. Ili estas pruvo pri la tunelo, ne pri la reto malantaŭ ĝi.

Sekvu la fluon ĝis la unua limo, kiu faligas ĝin

Komencu ĉe la kliento kaj konfirmu la itineron kaj la fontan adreson, kiujn la fluo uzos. Poste observu la pordegon por la alveno de ĝuste tiu fluo, kaj denove por la sama fluo foriranta al la LAN. Se ĝi neniam alvenas, la problemo estas ĉe la klienta flanko aŭ ĉe la permesitaj prefiksoj de la tunelo. Se ĝi alvenas kaj neniam foriras, la problemo estas plusendado aŭ filtrilo de la antaŭa vojo, kaj la kaptaĵo jam diris, kiu el la du.

Ruli la saman teston de la pordego kaŝas la interesan duonon, ĉar paketo origininta ĉe la pordego havas alian fonton kaj alian postulon pri reveno. Uzu la fluon de la kliento, kun ĝia propra fonta adreso, ĉe ĉiu paŝo. Kaptaĵo farita sur la malĝusta interfaco produktas memfidan sensencaĵon.

Revenaj itineroj kaj gastigantaj fajroŝirmiloj malsukcesas aparte

Post kiam la paketo atingas la gastiganton, tri pliaj aferoj devas validi. La servo devas aŭskulti ĉe la adreso, al kiu la paketo estis sendita, la fajroŝirmilo de la gastiganto devas akcepti ĝin, kaj la respondo devas havi itineron reen al la klienta baseno. Tiu lasta ofte malsukcesas, ĉar la defaŭlta itinero de la gastiganto montras al enkursigilo, kiu neniam aŭdis pri la tunela gamo. La rezulto estas konekto, kiu establiĝas el la vidpunkto de la gastiganto kaj silente mortas en la alia direkto.

Testu la revenan vojon intence sendante de la kliento kaj observante la revenon. Unudirekta kaptaĵo solvas en sekundoj tion, kion horo da spekulado ne solvos.

Konfirmu ĉiun salton per la fonta adreso de la kliento

Rulu la kontrolojn laŭorde kaj konservu ĉiun eligon, ĉar la valoro kuŝas en la komparo, ne en iu unuopa linio. La subaj komandoj fiksas la fontan adreson, montras la elektitan itineron kaj kaptas ambaŭ flankojn de la plusendado. Anstataŭigu vian propran LAN-gastiganton kaj tunelan interfacon.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

La itinera demando montras, ĉu la kliento entute sendus tiun paketon en la tunelon, kaj la ping montras, ĉu io revenis de la gastiganto. Kompari la du kaptaĵojn apartigas alvenon de eliro, ĉar kadro sur la tunela interfaco sen ekvivalento sur la LAN-interfaco estas plusenda decido, ne servo-malsukceso. Kiam ambaŭ kaptaĵoj montras la peton kaj nur unu montras la respondon, la revena itinero estas la restanta suspektato.

Notu, kiu adreso respondis kaj kiu plusendita celo malsukcesis. Tiu frazo faras la raporton plenumebla anstataŭ aserto, ke la servilo estas neatingebla.