Du VPN-saltoj sinsekve: kiu vere vidas vian trafikon?

Ĉiu klienta profilo nomas unu servilon, do el la sidloko de la uzanto estas unu tunelo kaj unu loko, kie protekto finiĝas. Kio okazas post tiu unua enirejo, estas dizajna decido, kiun la kliento neniam vidas, kaj la du oftaj dizajnoj kondutas tre malsame sub inspektado. En seria ĉeno la unua enirejo malĉifras kaj reĉifras. En nestita ĉeno ĝi forigas eksteran tavolon kaj plusendas internan tunelon, kiun ĝi ne povas malfermi. La nombro de saltoj estas identa en ambaŭ, tial la diferenco devas esti desegnita, ne kalkulita.

Komencu ĉe la kliento kaj nomu ambaŭ finpunktojn

Komencu tie, kie la uzanto komencas, en la konekta profilo. Ĝi tenas unu malproksiman adreson, unu aŭtentigan metodon kaj, kiam la dizajno subtenas tion, liston de itineroj. Etikedu tiun eksteran tunelon de la kliento al enirejo A kaj donu al ĝi ekzemplajn adresojn: la tunela adreso de la kliento 10.77.0.2, tiu de A 10.77.0.1 kaj la publika finpunkto de A 198.51.100.10, prenitaj el la dokumentada gamo TEST-NET-2, por ke nenio en la ekzemplo povu kolizii kun reala gastiganto.

Nenio en tiu profilo mencias enirejon B, kaj tio ne estas difekto. La dua salto apartenas al A, kaj la sola devo de la kliento estas liveri trafikon al A kaj akcepti tion, kio revenas. Ĉu A finas la tunelon, plusendas ĝin aŭ malfermas novan, estas la demando, kiun la resto de tiu ĉi trairo respondas, kaj ĝi decidas, kion A povas legi.

Serie: A malĉifras, poste reĉifras

En la seria dizajno A finas trafikon dufoje. Ĝi forigas la protekton de la kliento, akiras la IP-paketon de la aplikaĵo kaj poste sendas tiun paketon tra dua tunelo, kiun A starigas al B. Inter tiuj du operacioj la paketo sidas en la plusenda vojo de A kiel ordinara IP-paketo adresita al privata celo.

Tio produktas du sekvojn, kiujn indas diri rekte. A povas apliki politikon al la interna paketo, en formo de itineroj, filtroreguloj kaj protokolado de fonto kaj celo, kaj A devas teni du arojn de akreditaĵoj: unu kiel servilo por la kliento kaj unu kiel kliento de B. Protektado ekzistas en ĉiu momento, tamen la protektata objekto ŝanĝas identecon ĉe A.

El tio ne sekvas, ke A legas la puran tekston de la aplikaĵo. Kiam la kliento kaj la servo uzas TLS kaj reciproke kontrolas la atestilojn, A vidas fluon de TLS-rikordoj anstataŭ legebla peto. Konfirmi, kie tiu protekto finiĝas, postulas rigardon al la atestila ĉeno de la servo, ne al la tunela diagramo.

Nestite: A forigas nur la eksteran tavolon

En la nestita dizajno la kliento unue konstruas internan tunelon al B kaj poste portas tiun tunelon ene de la ekstera al A. A senŝeligas la eksteran kaplinion, trovas internan tunelon kaj plusendas ĝin sen teni ĝiajn ŝlosilojn, do la interna protekto ankoraŭ finiĝas ĉe B.

Tiam la suprena ligo de la kliento portas du tavolojn, dum la vojo inter A kaj B portas unu. A vidas la eksterajn adresojn de la interna tunelo, kio sufiĉas por scii, ke trafiko ekzistas kaj proksimume kien ĝi iras, kaj ne sufiĉas por legi la utilan ŝarĝon. Tio estas la tuta diferenco de la seria kazo, kaj neniu saltokalkulilo montras ĝin. Kion A ankoraŭ povas fari, estas rifuzi plusendi tion, kion ĝi ne povas legi, kaj tio ĉiam disponeblas al la operatoro de tiu enirejo.

Nestado pagas por tiu eco. Ĉiu tavolo aldonas kaplinian superkoston, do planado de MTU kaj MSS fariĝas deviga anstataŭ nur ordema, kaj vojo, kiu funkcias kun unu tavolo, povas silente forĵeti grandajn paketojn kun du. Ĉiu tavolo ankaŭ bezonas sian propran rekonektan kaj vivtenan konduton, kaj paneo en unu tavolo aspektas kiel parta interrompo tra la alia.

Desegnu la observantojn, ne nur la tunelojn

La tuneloj estas la facila parto de la desegno. La observantoj estas tio, pri kio temas la dizajno, do skribu unu vicon por ĉiu vidpunkto kaj plenigu, kion ĉiu vere povas legi.

Du vicoj konstante konfuziĝas: la operatoro de A kaj la provizanto de la klienta tunelo. Ili povas esti unu ento, kaj apartaj enirejaj nomoj ne faras ilin sendependaj. Sendependa posedo bezonas apartan administran kontrolon, apartajn akreditaĵojn kaj apartan protokoladon.

Metadatumoj postvivas ambaŭ dizajnojn. Tempigo, pakaĵgrandoj kaj konektokvantoj restas observeblaj ĉe ĉiu salto, do du saltoj altigas la koston de korelacio anstataŭ forigi la signalon. Dizajno, kiu promesas nevideblecon, devus esti kontrolita kontraŭ tiu listo antaŭ ol iu fidas ĝin.

Trairu la paneajn vojojn antaŭ ol elekti

Rompui aferojn intence de la kliento, laŭ la ordo, en kiu uzanto renkontus ilin. Komencu per la interfaco kaj ĝia MTU, ĉar nestado paneas je pakaĵgrandeco longe antaŭ ol ĝi paneas je aŭtentigo.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Poste konfirmu la protektajn finpunktojn anstataŭ supozi ilin. Petu de la servo ĝian atestilon el interne de ajna tunelo, kiu estas malfermita, kaj komparu la ĉenon, kiun la kliento vidas, kun la ĉeno, kiun la servo efektive prezentas. Enirejo, kiu resubskribas aŭ interceptas, ŝanĝas tiun atestilon, kaj la inspektado fariĝas videbla per unu komando.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Finu per la rekonekta matrico: la tunelo de la kliento falas, la tunelo de B falas, la vojo inter A kaj B ŝanĝiĝas. Notu, kio revenas kaj kio ne, kaj ĉu interna konekto iam falas al itinero ekster sia celita portanto. Registru la adresojn, kiujn uzis ĉiu testoj, ĉar ripeti ĝin en alia alirreto respondas alian demandon. Ripetu ankaŭ la MTU-sondadon post ĉiu rekonekto, ĉar ŝanĝita vojo povas malaltigi la uzeblan grandecon sen moviĝi eĉ unu agordan linion.

Elektu serian, kiam A devas apliki politikon al la interna paketo, aŭ kiam la kliento ne povas funkciigi du stakitajn tunelojn. Elektu nestadon, kiam la interna ŝarĝo devas resti nelegebla ĉe A. Skribu la elekton kun ĝiaj observantoj kaj ĝiaj MTU-nombroj, kaj la sekva persono ne devos redesegni la tutan bildon por respondi unu demandon.