OpenVPN TUN kundrejt TAP: tre kushte që vendosin

Dy tunele mund të transportojnë të njëjtin transferim skedari dhe gjithsesi të jenë krejtësisht të ndryshëm në atë që vendosin në tel. Njëri lëviz paketa IP midis dy adresave; tjetri lëviz kuadro Ethernet dhe mund të urëzohet në një segment. Kjo diferencë vendos cilat aplikacione funksionojnë, cilët klientë mund të lidhen dhe sa projektim rrjeti merrni përsipër.

Në praktikë, tre kushte e zgjidhin këtë. Kalojini sipas radhës, sepse i pari zakonisht e mbyll diskutimin.

Çfarë transporton në të vërtetë secila ndërfaqe

Një pajisje TUN është një ndërfaqe pikë-për-pikë e shtresës 3: kerneli i jep paketa IP dhe tuneli i çon ato në një adresë homologe. Një pajisje TAP është një ndërfaqe e shtresës 2 që transporton kuadro Ethernet, dhe pikërisht kjo e bën të mundur urëzimin, siç përshkruan dokumentacioni i kernelit. Asnjëra nuk ndryshon mënyrën se si kriptohet ngarkesa dhe asnjëra nuk është një cilësim force. Zgjedhja ka të bëjë me atë që duhet të shkëmbejnë skajet, jo me atë se sa mirë mbrohet trafiku.

Një pasojë vjen menjëherë: të dy skajet duhet të bien dakord. Një klient i konfiguruar për një lloj pajisjeje nuk mund t'i bashkohet një serveri të konfiguruar për tjetrin, pavarësisht se çfarë tjetër përputhet.

Kushti i parë: a ka nevojë gjë për shtresën dy?

Urëzimi e meriton kompleksitetin e tij kur një protokoll ka vërtet nevojë për të njëjtin domen transmetimi: trafik jo-IP, zbulim që nuk mund të kalojë një router, ose një aplikacion që këmbëngul të jetë në një segment. Çdo gjë tjetër është problem rrugëtimi, dhe rrugëtimi e zgjidh me shumë më pak makineri. Zgjatja e një segmenti në një zonë të gjerë zgjat edhe transmetimet e tij, kështu që parandalimi i sytheve, planifikimi i adresave dhe domenet e dështimit bëhen të gjitha pjesë e projektimit. Kjo është shumë për t'u pranuar për një kërkesë që një rrugë e vetme do të kishte plotësuar.

Testi është konkret: emërtoni aplikacionin që dështon në një tunel të rrugëtuar dhe thoni pse. Nëse përgjigjja është se i duhet transmetim, shtresa dy është përgjigjja e ndershme. Nëse përgjigjja është se dikush nuk mundi të arrijë një server, kërkesa është një rrugë ose një rregull firewall-i.

Kushti i dytë: a mund ta bëjnë klientët?

Mbështetja nuk është uniforme. Klientët e desktopit zakonisht ofrojnë të dy llojet e pajisjeve, ndërsa klientët celularë dhe të integruar shpesh zbatojnë vetëm modalitetin e rrugëtuar, dhe një profil që importohet pa ankesa mund gjithsesi të dështojë kur përpiqet të krijojë ndërfaqen. Kontrolloni klientin dhe versionin konkret në vend që të nxirrni veçoritë nga emri i platformës.

Një gabim për një opsion të pambështetur nuk është ftesë për të fshirë rreshta të panjohur derisa importi të ketë sukses. Do të thotë që profili dhe klienti nuk bien dakord për atë që është e mundur, dhe riparimi i përket operatorit që lëshoi profilin. Heqja e një opsioni për të qetësuar një validues mund të prodhojë një lidhje që duket se punon ndërsa lë pa zë pronën për të cilën ekzistonte.

Kushti i tretë: është vërtet kjo një çështje ndërfaqeje?

Dy zgjedhje fqinje fajësohen për problemet e ndërfaqes. Pajisja virtuale vendos çfarë hyn në tunel, ndërsa UDP ose TCP vendos si sillet transporti i jashtëm, dhe asnjëra nuk shëron transferimet që ngecin. Kur transferimet e mëdha varen ndërsa të voglat kalojnë, madhësia e paketës dhe MTU meritojnë vëmendjen.

Një klient që lidhet dhe më pas nuk arrin një host të brendshëm zakonisht po shikon rrugëtimin, një rregull firewall-i ose një rrugë kthimi që mungon.

Për një shërbim të menaxhuar, përdorni rregullimin e ndërfaqeve që përcakton profili i operatorit, sepse ana e serverit është ndërtuar tashmë rreth tij. Për një vendosje private, zgjidhni nga kërkesa reale e aplikacionit dhe shkruani arsyen pranë zgjedhjes.

Pyetja nuk është cili opsion është më i fortë. Është cili i duhet vërtet trafikut.