Nestita VPN: kiu tunelo portas la eksteran konekton?

Du samtempe funkciantaj VPN-klientoj ne produktas nestitan tunelon; ili produktas du tunelojn kaj disputon pri la enkursigado. Nestita tunelo ekzistas, kiam la konekto de la interna kliento al sia propra servilo mem estas portata de la ekstera tunelo, kaj tio estas aranĝo, kiun oni konstruas intence. Se ĝi pravas, la interna servilo vidas la adreson de la ekstera servilo; se ĝi malpravas, unu kliento silente rekonektiĝas ĉirkaŭ la alia. Tri kondiĉoj decidas, ĉu la nestado estas reala aŭ hazarda.

Tri kondiĉoj decidas la nestadon

La unua estas, kiu finpunkto bezonas kiun vojon. Nomu la adreson de la interna servilo, nomu la adreson de la ekstera servilo, kaj eksplicite deklaru, ke la interna servilo atingeblas nur tra la ekstera tunelo. Ĉio alia sekvas el tiu frazo, inkluzive kiuj vojoj apartenas al kiu tabelo.

La dua estas, ĉu vi povas vidi la vojon ĉe ĉiu tavolo. Se vi ne povas demandi la kernon, kiun vojon specifa celo uzus, vi deduktas la ĉenon el fina elira IP, kaj tio estas ĝuste la pruvo, kiu ne povas distingi nestadon disde koincido.

La tria estas, kio okazas, kiam la ekstera tunelo falas. La interna tunelo povas halti kun ĝi, rekonektiĝi tra la ordinara reto aŭ resti blokita ĝis la ekstera vojo revenos, kaj ĉiuj tri estas defendeblaj politikoj. Ili ne estas la sama politiko, kaj la defaŭlta konduto de la plej multaj klientoj estas la dua. Kliento, kiu rekonektas sian finpunkton tra la fizika reto dum ĝi montras sanan konekton, estas la plej ofta maniero, laŭ kiu intencita ĉeno silente fariĝas du senrilataj tuneloj.

Kondiĉo unu: kiu finpunkto bezonas kiun vojon

ip route get 203.0.113.10 rekte respondas tiun demandon: ĝi presas la vojon, la fontan adreson kaj la interfacon, kiun la kerno uzus por tiu celo nun.

Rulu ĝin por la interna servilo antaŭ ol la interna kliento ekfunkcias kaj denove poste, kaj komparu. Se la respondo ŝanĝiĝas de la fizika interfaco al la interfaco de la ekstera tunelo, la nestado estas reala en tiu momento. Se ĝi ne ŝanĝiĝas, la interna kliento konektiĝas rekte, kion ajn diras la panelo. Ripetu por la adreso de la ekstera servilo, kiu ankoraŭ devas esti solvita tra la fizika interfaco, ĉar vojo, kiu kaptas ambaŭ finpunktojn rekursive estas la paneo, kiu tute forigas la maŝinon el la reto.

Kondiĉo du: inspektu la vojon ĉe ĉiu tavolo

Vojoselektado estas pli ol la ĉefa tabelo ĉe moderna kliento. Politikaj reguloj povas sendi markitajn pakaĵojn al alia tabelo, kliento povas ligi sian soketon al interfaco, kaj ujo aŭ nomspaco havas tute proprajn tabelojn. Per ip rule kaj ip route show table all vi ekscias, kiu el tiuj mekanismoj estas en ludo.

Kliento, kiu metas SO_MARK sur sian propran soketon aŭ estas agordita ligiĝi al difinita aparato, ĉirkaŭiras la defaŭltan vojon, kiun vi kredis esti aranĝinta. Tio estas funkcio kaj ne cimo, kaj ĝi signifas, ke la sola fidinda kontrolo estas tiu, kiu rulas en la sama nomspaco kiel la kliento. Se la klientoj rulas en ujoj, rulu la kontrolojn en tiuj ujoj anstataŭ sur la gastiganto.

Kondiĉo tri: kio okazas, kiam la ekstera tunelo falas

Misfunkcia konduto postulas decidon, ne defaŭlton. Notu, kio devas okazi al la interna tunelo, kiam la ekstera malaperas, kaj poste igi la klientojn tion fari.

La elektoj estas konkretaj. Haltigi la internan klienton, kiam la ekstera vojo malaperas, donas puran ĉenon kaj evidentan paneon. Lasi ĝin rekonektiĝi rekte donas haveblecon kaj silente forigas la econ, por kiu la ĉeno estis konstruita. Bloki ĝis la ekstera vojo revenos estas la plej strikta kaj la plej ĝena por funkciigi, ĉar ĉiu oscilado de la ekstera tunelo fariĝas videbla incidento.

Testu ĉiujn tri per sendanĝera trafiko kaj intenca paneo de la ekstera tunelo, ĉar legi la agordon ne diros al vi, kiun vi havas. Mortigu la eksteran tunelon, observu, kion faras la interna kliento, kaj kontrolu la vojon denove, dum ĝi estas malsupre. Poste revenigu la eksteran tunelon kaj konfirmu, ke la ĉeno reformiĝas anstataŭ lasi la internan klienton sur la rekta vojo, kiun ĝi elektis intertempe.

Kion la ĉeno ne donas al vi

Pliaj tavoloj aldonas finpunktojn, ŝlosilojn kaj paneojn; ili aldonas neniun garantion de anonimeco kaj ili ne malebligas al la ekstera operatoro vidi, ke tunelo ekzistas. Ĉiu aserto pri tio, kion protektas la nestado, devas nomi la observanton, kontraŭ kiu ĝi protektas.

La liveraĵo estas mallonga dokumento kaj ne funkcianta konekto: kiu finpunkto uzas kiun vojon, kio okazas ĉe ekstera paneo, kaj la tri komandoj, kiuj montras la nunan staton. La dokumentaro de strongSwan pri plusendado estas utila referenco por tio, kiel tunela trafiko estas plusendata inter interfacoj sur Linux-gastiganto. Rerulu la kontrolojn post ĉiu klienta ĝisdatigo, ĉar la defaŭltoj, kiuj kreis vian ĉenon, ne estas kontrakto. Nestita tunelo, kiun vi ne povas inspekti, estas onidiro kun statuslumo.