Kial plentunela itinero fortranĉas la servilon, kiu ĝin portas

Ŝaltu plenan tunelon kaj ĉiu celloko nun apartenas al la VPN-interfaco, inkluzive de la maŝino, kiu ĝin finas. La eksteraj pakaĵoj portantaj la tunelon estas adresitaj al tiu maŝino, do la itinero finfine konsumas la transporton, de kiu ĝi dependas. Unu plia specifa itinero solvas tion, kaj la kialo indas esti komprenata. Sen tiu kialo, la sekva rekonstruo ree enkondukas la difekton.

Itinero, kiu manĝas sian propran transporton

Enkapsuligo volvas ĉiun pakaĵon en duan kaplinion. La ekstera estas adresita de la loka fizika adreso al la publika adreso de la servilo, kaj ĝi devas transiri la fizikan ligon antaŭ ol ajna tunelo povas ekzisti.

Nun lasu la serĉadon de tiu publika adreso elekti la tunelon. Por sendi la pakaĵon, la maŝino devas enkapsuligi ĝin, kio postulas itinero al la sama adreso, kiu redonas la tunelon. Klientoj traktas tion en unu el du manieroj. Singarda kliento rifuzas instali la defaŭltan itinero kaj raportas eraron, dum malpli singarda raportas sukceson kaj poste movas nenion. La silenta malsukceso estas tiu, kiu kostas posttagmezon.

La plej longa prefiksa kongruo decidas la serĉadon antaŭ ol konsulti ajnan metrikon, do itinero por unu adreso superas ĉiun defaŭltan itinero en la maŝino. Tio estas la tuta mekanismo malantaŭ la riparo.

Instalu la escepton antaŭ la defaŭlta

Kreu itinero por unu adreso por la servilo, kun la fizika enirejo kiel la sekva salto, antaŭ ol la defaŭlta itinero moviĝas. La ordo gravas: instali ĝin poste signifas vivi kun rompita tunelo dum vi tajpas.

Plej multaj klientoj faras tion sen peto. OpenVPN serĉas la malproksiman adreson kaj fiksas ĝin antaŭ ol reverki la defaŭltan enirejon, kaj ĝia opcio route-delay ekzistas por platformoj, kie tiu sinsekvo kuras. wg-quick prenas tute alian vojon, markante pakaĵojn kaj konsultante politikan regulon anstataŭ aldoni escepton. Malsamaj mekanismoj, sama postulo: la ekstera pakaĵo devas eskapi la tunelon, kiun ĝi kreas.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

La eligo de la serĉado estas la akcepta testo. Ĝi devas nomi la fizikan aparaton kaj la fizikan sekvan salton. Tunela aparato en tiu respondo signifas, ke la escepto mankas aŭ estis metita post io, kio superregas ĝin.

La spegula bildo sur la servilo

La sama kaptilo atendas sur la alia flanko, inverse. Donu al la servilo defaŭltan itinero tra alia tunelo, aŭ puŝu al ĝi itinero, kiu kovras la publikajn adresojn de la klientoj, kaj ĝiaj respondoj akiras kutimon iri malĝustan vojon.

Imagu klienton, kiu konektiĝas kaj sendas peton. La respondo estas adresita al la publika adreso de tiu kliento, kiu nun kongruas kun tunela itinero, do ĝi eliras el alia interfaco portante fonton, kiun la kliento neniam elektis. La kliento povas ricevi tiun pakaĵon kaj tamen forĵeti ĝin, ĉar nenio ligas ĝin al la peto, kiun ĝi sendis. Laboru de la enkursiga decido de la servilo anstataŭ de la tempolimo de la kliento, ĉar nur unu el ili montras la realan elekton.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Ekzistas tri riparoj kaj ili ne estas egalaj. Fiksi la servon al la fizika adreso aŭ traduki la fonton ambaŭ kaŝas la enkursigan decidon anstataŭ korekti ĝin. Sendi respondan trafikon por la tunela baseno tra dediĉita tabelo korektas la kaŭzon, kaj la aliaj du estas akcepteblaj nur dum la enkursiga dezajno estas frostigita.

Esceptoj, kiujn la tunelo daŭre ŝtelas

Plenmano da taskoj bezonas la malferman interreton eĉ dum la tunelo posedas la defaŭltan itinero, kaj ĉiu bezonas sian propran escepton. La ĝisdatigilo de dinamika DNS kutime estas la unua, kiu rompiĝas.

Ĝi solvas la provizanton, malfermas konekton kaj trovas, ke ĝiaj propraj pakaĵoj vojaĝas tra tunelo, kies adreso ŝanĝiĝis antaŭ sekundoj, do la ĝisdatigo malsukcesas aŭ publikigas la malĝustan adreson. Tri eliroj: fiksu la provizanton per gastiga itinero tra la fizika enirejo, rulu la ĝisdatigon antaŭ ol la tunelo leviĝas, aŭ donu al la ĝisdatigilo politikan tabelon, kiun la tunelo neniam tuŝas. Tempa sinkronigo havas la saman eksponiĝon sur aparato, kiu startas sen solvilo, kaj la finpunktoj por validigo de atestiloj apartenas al la listo pro la sama kialo.

Escepto, kiun neniu skribis, estas escepto, kiun la sekva rekonstruo silente forlasos.

Pruvu ĝin post rekonekto, ne antaŭe

Testu tri cellokojn, ne unu: la finpunkton, privatan adreson malantaŭ la tunelo kaj publikan adreson preter ĝi. Unu sukcesa serĉado preskaŭ nenion diras pri la aliaj du.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Poste restarigu la konekton, ĉar kliento, kiu rekonstruas sian tabelon ĉe rekonekto, forĵetos itinero, kiun vi tajpis permane. Kun kill switch en ludo, kontrolu, ke la finpunkto estas permesita, alie la tunelo ne povas reveni post reta ŝanĝo kaj la simptomo aspektas kiel interrompo. Konservu la escepton en la profilo aŭ la unit-dosiero anstataŭ en la ŝela historio, por ke la rekonekto rekreis ĝin anstataŭ forviŝi ĝin.