OpenVPN TUN pret TAP: trīs nosacījumi, kas izšķir

Divi tuneļi var pārvietot vienu un to pašu faila pārsūtīšanu un tomēr pilnīgi atšķirties tajā, ko tie liek uz vada. Viens pārvieto IP paketes starp divām adresēm; otrs pārvieto Ethernet kadrus, un to var savienot tiltā ar segmentu. Šī atšķirība izšķir, kuras lietotnes darbojas, kuri klienti var pieslēgties un cik daudz tīkla projektēšanas jūs uzņematies.

Praksē to izšķir trīs nosacījumi. Izskatiet tos pēc kārtas, jo pirmais parasti beidz diskusiju.

Ko katrs interfeiss patiešām pārvieto

TUN ierīce ir 3-slāņa punkts-punktā interfeiss: kodols tai nodod IP paketes, un tunelis tās aizved uz partnera adresi. TAP ierīce ir 2-slāņa interfeiss, kas pārvieto Ethernet kadrus, un tieši tas vispār padara iespējamu tiltu, kā apraksta kodola dokumentācija. Neviens no tiem nemaina to, kā tiek šifrēta lietderīgā slodze, un neviens nav stipruma iestatījums. Izvēle ir par to, kas galapunktiem jāapmaina, nevis par to, cik labi trafiks ir aizsargāts.

Viena sekas uzreiz izriet: abiem galiem jāvienojas. Klientam, kas konfigurēts vienam ierīces tipam, nevar pievienoties serverim, kas konfigurēts otram, lai kas cits sakristu.

Pirmais nosacījums: vai kaut kam vajag otro slāni?

Tilts pelna savu sarežģītību, kad protokolam patiešām vajag vienu un to pašu apraides domēnu: ne-IP trafiku, atklāšanu, kas nevar šķērsot maršrutētāju, vai lietotni, kas uzstāj būt vienā segmentā. Viss pārējais ir maršrutēšanas problēma, un maršrutēšana to atrisina ar daudz mazāk mehānismiem. Segmenta paplašināšana plašā teritorijā paplašina arī tā apraides, tāpēc cilpu novēršana, adrešu plānošana un kļūdu domēni kļūst par dizaina daļu. Tas ir daudz, ko pieņemt prasībai, ko būtu apmierinājis viens maršruts.

Tests ir konkrēts: nosauciet lietotni, kas neizdodas maršrutētā tunelī, un pasakiet, kāpēc. Ja atbilde ir, ka tai vajag apraidi, otrais slānis ir godīgā atbilde. Ja atbilde ir, ka kāds nevarēja sasniegt vienu serveri, prasība ir maršruts vai ugunsmūra noteikums.

Otrais nosacījums: vai klienti to var?

Atbalsts nav vienmērīgs. Darbvirsmas klienti parasti piedāvā abus ierīces tipus, savukārt mobilie un iegultie klienti bieži ievieš tikai maršrutēto režīmu, un profils, kas importēts bez iebildumiem, tomēr var neizdoties, kad tas mēģina izveidot interfeisu. Pārbaudiet konkrēto klientu un versiju, nevis seciniet funkcijas no platformas nosaukuma.

Neatbalstītas opcijas kļūda nav aicinājums dzēst nepazīstamas rindas, kamēr imports neizdosies. Tas nozīmē, ka profils un klients nav vienisprātis par to, kas ir iespējams, un labojums pieder operatoram, kas izdeva profilu. Opcijas noņemšana, lai apklusinātu validatoru, var radīt savienojumu, kas šķiet strādājam, bet klusi izlaiž īpašību, kurai tas pastāvēja.

Trešais nosacījums: vai tas tiešām ir interfeisa jautājums?

Par interfeisa problēmām vaino divas blakus esošās izvēles. Virtuālā ierīce nosaka, kas nonāk tunelī, bet UDP vai TCP nosaka, kā uzvedas ārējais transports, un neviens no tiem nedziedē pārsūtīšanas, kas iestrēgst. Kad lieli pārsūtījumi karājas, bet mazie izdodas, uzmanības vērti ir paketes izmērs un MTU.

Klients, kas pieslēdzas un pēc tam nevar sasniegt vienu iekšējo resursdatoru, parasti skatās maršrutēšanu, ugunsmūra noteikumu vai trūkstošu atgriešanās ceļu.

Pārvaldītam servisam izmantojiet interfeisu izkārtojumu, ko nosaka operatora profils, jo servera puse jau ir uzbūvēta ap to. Privātai izvietošanai izvēlieties pēc lietotnes patiesās prasības un pierakstiet iemeslu blakus izvēlei.

Jautājums nav par to, kura opcija ir stiprāka. Jautājums ir par to, kura trafikam patiešām vajadzīga.