OpenVPN TUN aŭ TAP: tri kondiĉoj decidas

Du tuneloj povas porti la saman dosierotransigon kaj tamen tute malsami en tio, kion ili metas sur la draton. Unu movas IP-paketojn inter du adresoj; la alia movas Ethernet-kadrojn kaj povas esti pontita en segmenton. Tiu diferenco decidas, kiuj aplikaĵoj funkcias, kiuj klientoj povas konektiĝi, kaj kiom da reta projektado vi akceptas.

Tri kondiĉoj klarigas ĝin en la praktiko. Trairu ilin laŭorde, ĉar la unua kutime finas la diskuton.

Kion ĉiu interfaco efektive portas

TUN-aparato estas punkt-al-punkta interfaco en tavolo 3: la kerno donas al ĝi IP-paketojn kaj la tunelo portas ilin al la adreso de la alia fino. TAP-aparato estas interfaco en tavolo 2, kiu portas Ethernet-kadrojn, kaj ĝuste tio ebligas pontadon entute, kiel priskribas la dokumentaro de la kerno. Neniu el ili ŝanĝas kiel la utilaĵo estas ĉifrata, kaj neniu el ili estas fortagordo. La elekto temas pri tio, kion la finpunktoj devas interŝanĝi, ne pri tio, kiom bone la trafiko estas protektata.

Sekvo sekvas tuj: ambaŭ finoj devas konsenti. Kliento agordita por unu aparattipo ne povas aliĝi al servilo agordita por la alia, kion ajn alie kongruas.

Kondiĉo unu: ĉu io ajn bezonas tavolon du?

Pontado gajnas sian komplikecon, kiam protokolo vere bezonas la saman dissendan domajnon: ne-IP-trafikon, malkovron kiu ne povas transiri enkursigilon, aŭ aplikaĵon kiu insistas esti en unu segmento. Ĉio alia estas enkursiga problemo, kaj enkursigado solvas ĝin per multe malpli da maŝinaro. Etendi segmenton trans grandan areon ankaŭ etendas ĝiajn dissendojn, do bukla preventado, adresa planado kaj panejaj domajnoj fariĝas parto de la projekto. Tio estas multe akcepti por postulo, kiun unu sola vojo jam plenumus.

La testo estas konkreta: nomu la aplikaĵon, kiu malsukcesas sur enkursigita tunelo, kaj diru kial. Se la respondo estas, ke ĝi bezonas dissendon, tavolo du estas la honesta respondo. Se la respondo estas, ke iu ne povis atingi unu servilon, la postulo estas vojo aŭ fajroŝirma regulo.

Kondiĉo du: ĉu la klientoj povas tion?

Subteno ne estas unuforma. Labortablaj klientoj ĝenerale montras ambaŭ aparattipojn, dum poŝaj kaj enkorpigitaj klientoj ofte realigas nur la enkursigitan reĝimon, kaj profilo, kiu enportiĝas sen plendo, povas tamen malsukcesi kiam ĝi provas krei la interfacon. Kontrolu la konkretan klienton kaj version anstataŭ dedukti la kapablojn el la platforma nomo.

Eraro pri nesubtenata opcio ne estas invito forigi nekonatajn liniojn ĝis la enporto sukcesos. Ĝi signifas, ke la profilo kaj la kliento malkonsentas pri tio, kio eblas, kaj la riparo apartenas al la administranto, kiu eldonis la profilon. Forigi opcion por silentigi validilon povas produkti konekton, kiu ŝajnas funkcii dum ĝi silente preterlasas la econ, por kiu ĝi ekzistis.

Kondiĉo tri: ĉu tio vere estas demando pri la interfaco?

Du najbaraj elektoj kulpigatas pri interfacaj problemoj. La virtuala aparato decidas, kio eniras la tunelon, dum UDP aŭ TCP decidas, kiel kondutas la ekstera transporto, kaj neniu el ili kuracas transigojn, kiuj haltas. Kiam grandaj transigoj haltas dum malgrandaj sukcesas, paketa grando kaj MTU meritas la atenton anstataŭe.

Kliento, kiu konektiĝas kaj poste ne povas atingi unu internan gastiganton, kutime rigardas enkursigadon, fajroŝirman regulon aŭ mankan returnan vojon.

Por administrita servo, uzu la interfacan aranĝon, kiun specifas la profilo de la administranto, ĉar la servila flanko jam estas konstruita ĉirkaŭ ĝi. Por privata deplojo, elektu laŭ la reala postulo de la aplikaĵo kaj skribu la kialon apud la elekto.

La demando ne estas, kiu opcio estas pli forta. Ĝi estas, kiun la trafiko efektive bezonas.