Du VPN-saltoj sur unu Pi: kiu itinero portas kiun partneron

Du tunelaj adresoj sur unu malgranda tabulo aspektas kiel eraro, kaj la reflekso estas forigi unu. Tiu reflekso rompas tion, kion ĝi devis ordigi. Gastiganto kun du saltoj tenas unu adreson por ĉiu ligo, kaj ĉiun adreson elektas malsama itinero. La demando inda je starigo estas, kiu itinero elektas kiun portanto por kiu celo, ne kiom da adresoj ekzistas.

Tri celoj, kiuj bezonas malsamajn portantojn

Ĉeno de du saltoj estas tri celaj klasoj stakitaj, kaj ĉiun portas malsama ligo. La ekstera partnero devas esti atingata tra la fizika ligilo. La interna partnero devas esti atingata tra la ekstera tunelo. La celo de la kovrita aplikaĵo devas esti atingata tra la interna tunelo, kies propran transporton portas la ekstera.

Plenigu la vicojn per la realaj adresoj de la leganto antaŭ ol tuŝi itineron, ĉar la tabelo utilas nur kiam ĝi estas konkreta. Funkcianta ĉeno plenumas ĉiujn kvar vicojn samtempe, kaj duone funkcianta ĉeno kutime plenumas unu el ili kun la malĝusta portanto. Ĝuste legi la malĝustan vicon kiel la fiaskon transformas itineran problemon en tutan posttagmezon da redaktoj.

Adresoj havas rolojn, ne nombron

Linux permesas plurajn adresojn sur unu interfaco kaj plurajn tunelojn sur unu gastiganto, do nombro diras nenion pri ĝusteco. Gravas, kiu adreso apartenas al kiu ligo, kaj ĉu la itinero por donita partnero elektas la ligon, kiun vi intencis. Tri vidoj respondas tion el tri direktoj, kaj indas legi ilin en la sama ordo ĉiufoje.

La adresa inventaro montras, kio ekzistas kaj kiu ligo posedas ĝin. La itinera tabelo respondas la portanto-demandon por ordinara celtrafiko. La politika vido respondas ĝin denove por trafiko elektita per fonto aŭ marko, kio estas la normala aranĝo kiam du klientoj dividas unu gastiganton.

ip -4 addr show
ip -4 route show table all
ip rule show

Forigi adreson ĉar la listo aspektas longa povas forpreni parton de la vojo, kaj forigi itineron ĉar ĝi aspektas superflua faras la saman pli silente. Neniu el ili produktas eraron; la partnero simple ĉesas respondi sur la vojo, kiun vi intencis, dum ĝi restas atingebla per alia. Aplikaĵo, kiu raportas la eliran adreson de la interna partnero, ne pruvas, ke la trafiko trapasis la eksteran tunelon, ĉar rekta aliro produktas la saman observon. Ĝuste tiu breĉo inter observo kaj pruvo estas kial la portanto estas kontrolata sur la itinera tavolo.

Aktiviga ordo venkas fiksan dormon

Se la interna kliento dependas de adreso aŭ itinero, kiun provizas la ekstera kliento, la aktivigo devas atendi tiun rimedon anstataŭ prokraston. Dormo funkcias ĝis la tago, kiam la ekstera tunelo estas malrapida, kaj tiam ĝi periode fiaskas tiel, ke neniu povas reprodukti. Ordo bazita sur dependecoj forigas la konjekton kaj kostas nenion krom priskribi la dependecon unufoje. Ankaŭ interfacaj nomoj ne estas ordiga mekanismo.

La kerno disdonas nomojn kiel tun0 kaj tun1 laŭ kreordo, kaj tiu ordo povas ŝanĝiĝi inter restartoj aŭ rekonektoj. Ligu la agordon al identeco, kiun la iloj provizas, aŭ al nomo, kiun vi konscie asignas. Nomo, kiun vi elektas, estas kontrakto; nomo, kiun la kerno elektas, estas hazardo.

Tenadu la transporton de ĉiu kliento ekster la aplika itinero de la alia, kaj estu preciza pri tio, kion la OpenVPN 2.6 itineraj opcioj vere promesas. La dokumentita defaŭlta alidirekta mekanismo tenas klienton kapabla atingi sian propran malproksiman partneron tra la enirejo, kiu jam ekzistis, kio tranĉas unu specifan rekursian buklon. Ĝi ne igas unu klienton la portanto de alia, do la resto de la ĉeno restas via dezajno. Kie la ĉeno bezonas politikon anstataŭ itineron, skribu eksplicitan fontan aŭ markan regulon kaj testu ĝin per la trafiko, kiun ĝi celas kongruigi.

Kio okazas, kiam la ekstera salto mortas

Antaŭ ol la ĉeno validas kiel kompleta, decidu, kio okazas, kiam la ekstera salto malaperas. La transporto de la interna kliento mortas kun ĝi, kaj la sekva paŝo estas politika demando anstataŭ teknika: fiaski, reprovi aŭ rekonekti rekte tra la fizika ligilo. Tiu tria rezulto estas la inda pripenso. Ĝi silente transformas du-salton dezajnon en unu-salton en la momento, kiam la uzanto kredas, ke la kovrado ankoraŭ estas sendifekta.

Se du saltoj estas devigaj, la interna kliento ne devas povi starigi rektan vojon, kiam la ekstera mankas, kaj la maniero scii estas rompi la eksteran salton kaj observi, kion faras la interna. Aprobita rezerva plano estas legitima respondo, sed ĝi devas esti skribita, testita kaj komunikita. Rezerva plano, kiun neniu dokumentis, ne distingiĝas de liko dum incidenta revizio.

DNS kaj la alia adresa familio apartenas al la sama decido. Loke generita serĉo sekvas la propran politikon de la gastiganto, ne tiun de plusendita kliento, do la solvilo, kiu funkcias por plusendita trafiko, eble ne estas tiu, kiun la gastiganto mem uzas.

Akceptu ĉiun tavolon laŭ la ordo, en kiu vi konstruis ĝin

Testu laŭ la ordo, en kiu la ĉeno estis konstruita: unue la ekstera tunelo sola, poste la transporto de la interna kliento tra la ekstera tunelo, poste la aplikaĵo tra la interna tunelo. Ĉiu akcepto devas esti freŝa konekto anstataŭ paĝo jam malfermita. Poste rompu kaj restarigu ĉiun tavolon aparte kaj observu, kion faras la sekva.

La rezulto de la rezerva plano estas la plej valora observo ĉi tie, kaj tiu, kiun publika IP-paĝo neniam montras. Konservu la partnerajn vojojn, la adresojn, kiujn ili uzas, kaj tiun rezulton apud la agordo, ĉar la feliĉa vojo ne estas la parto, pri kiu oni demandas poste.