IP naslovi - 192 ali 10

der_Alte

der_Alte

Fizikalc
21. jul 2007
2.063
10
38
Zemlja
alte.aufbix.org
iSCSI nima enkripcije, IP tudi ne, če ne uporabiš IPSEC. Če pa uporabiš disk enkripcijo na klientu in skriptiraš celoten iSCSI disk, potem bodo podatki kriptirani na samem disku in kriptirani bodo tudi med prenosom, saj se podatki dekriptirajo šele v pomnilniku klienta. Kdorkoli bi posnifal promet med iSCSI initiatorjem in targetom, ne bi dobil kaj pametnega ven.
 
Jernej

Jernej

Fizikalc
18. avg 2007
7.124
0
36
Aha... ok, narobe sva se razumela. Sem mislil, da govoriva o AFP ali Sambi. Tam se TC enkripcija seveda podre. Nevermind, zamešal. To glede prenosa kriptiranih podatkov mi je približno jasno. Ravno zaradi tega, kar si napisal, mi je tako všeč princip iSCSI. Ampak na mac-u je problem iniciator. Imaš kakšne izkušnje s tem GlobanSAN-ovim?

Alternativa je NAS rešitev z možnostjo enkripcije podatkov. Dokler gre promet po lokalni mreži, je lahko tudi nešifiriran. Ampak potem je spet vprašanje, kaj uporabit za strežnik.

Uh...
 
Jernej

Jernej

Fizikalc
18. avg 2007
7.124
0
36

Še eno podvprašanje v zvezi z network file sharingom... da ne bom še ene teme odpiral. Kaj pa varianta, da je celotna enkripcija file-based. Torej, da se na NAS naloži samo eno pretty large TC datoteko, ki se jo potem mount-a na željenem client-u. S tem se izognem potrebi po iSCSI-ju ter obenem tudi potrebi po enkripciji na samem strežniku in/ali podatkovni poti do tja.


Skrbi me samo ena stvar... kako se recimo obnaša ext4 in SMB, če je na disku samo ena 2 TB velika datoteka?!
confused-1.gif
 
J

Jurij

Pripravnik
22. sep 2007
821
0
16
Ext4 podpira do 16TiB file, tako da mu to ne bi smelo predstavljati težav. Sicer ne vem če bi se take rešitve lotil, ker ne vem kaj se s podatki zgodi, če se poškoduje kakšen sektor na disku, je zadeva v večini berljiva ali gre vse v nepovrat, glede na to, da je samo ena datoteka.
 
Jernej

Jernej

Fizikalc
18. avg 2007
7.124
0
36
Citat:
What will happen when a part of a TrueCrypt volume becomes corrupted?

In encrypted data, one corrupted bit usually corrupts the whole ciphertext block in which it occurred. The ciphertext block size used by TrueCrypt is 16 bytes (i.e., 128 bits). The mode of operation used by TrueCrypt ensures that if data corruption occurs within a block, the remaining blocks are not affected. See also the question 'What do I do when the encrypted filesystem on my TrueCrypt volume is corrupted?
Klikni za razširitev

I guess it should be ok.

Za 16TiB sem prebral... bolj me skrbi podatkovni promet preko SMB. Vem, da se sliši malce neumno najbrž, ampak pisanje v 2 TB veliko datoteko malo tu, malo tam me navdaja s kar precejšnjo sumničavostjo.
smirk-1.gif


Saj vem, da so samo ničle in enke, ampak v moji glavi je volume-based bolj varno kot file-based. Bom moral malo spremenit to prepričanje zgleda.
 
der_Alte

der_Alte

Fizikalc
21. jul 2007
2.063
10
38
Zemlja
alte.aufbix.org
SMB1 bolj slabo, ker ima omejitev 2GB na datoteko. Zato se že dolgo uporablja CIFS (ja tudi windows so zdavnaj zamenjali). Kako se obnaša? Normalno. Samo vedi, da boš moral imet FS večji od 2TB.

Drugače ext4 dovoljuje 16TiB velike datoteke. CIFS pa 2^64 byte velike datoteke. Problem utegneš imet zaradi Mac OS X. Boš moral preveriti, če zna delat tudi s tako velikimi datotekami. Predvidevam, ker drugače se DAVE ne bi prodajal.

Ne razumem pa kaj si mislil s tem, da se izogneš enkripciji poti. CIFS nima enkripcije podatkov, tako da je zgodba enaka kot pri iSCSI. S Truecrypt datoteko na strežniku boš imel tudi prenos podatkov kriptiran.

Saj drugače iSCSI ni tak bavbav. V osnovi narediš particijo na disku ali pa logical volume, če uporabljaš LVM. Recimo, da imaš cel disk /dev/sde1 na nas.domena.internal (ali karkoli pač uporabljaš za interno domeno).
Namestiš paket scsi-target-utils (RHEL ali sorodni), v datoteko /etc/tgt/targets.conf daš nekaj takega
Koda: 
<target iqn.2011-12.si.domena.nas:sata.truecrypt>
        backing-store /dev/sde1
        initiator-address 192.168.1.12
        initiator-address 192.168.1.13
</target>

Zaženeš service tgtd in poskrbiš, da so vrata tcp/3260 dosegljiva. Potem lahko dostopaš do diska z dveh klientov (.12 in .13). Samo poskrbi, da ne z obeh naenkrat. Za take zadeve potrebuješ kakšen cluster aware FS.

Tole zgoraj je brez avtentikacije itd. Dela pa. Hitreje kot CIFS.
 
R

reality

Vudu lešinar
24. jul 2007
4.731
0
36
po mojem mnenju če že vzrtrajaš pri enkricpciji je najbolj da daš na primeren volume pač datotetko.. ta volume pa naj bo narjen z primernim raidom...

sam še zdej mi ni jasno, kaj zahudiča ti tko siliš v to enkripcijo, pri kakšnem dizastru so stem sami problemi.... Maš mogoče res tko hudo zasebne podatke al kaj?

Predstavljam si jest tko, da pač enkriptam kake občutljive podatke ne pa slik ali kej podobnega? Tega pa ne more bit 2 TB ja???
 
Jernej

Jernej

Fizikalc
18. avg 2007
7.124
0
36

OCD. Razmišljam o terapiji.
smirk-1.gif
Oziroma še bolje... v tovrstnih debatah razmišljam, kako enostavna bi bila zadeva, če ne bi silil v to enkripcijo (kot si se lepo izrazil). Kriptirano je pa popolnoma vse... tudi večpredstavne datoteke. Tako pač nikoli ne bom (ne bi) pozabil na kakšno datoteko.

Raid 1 + file based encrypted container je best bet zaenkrat. Enako iSCSI in volume based encryption.
 
Jernej

Jernej

Fizikalc
18. avg 2007
7.124
0
36

Hvala!


Torej CIFS dela počasneje kot iSCSI? Bral sem, da je ravno obratno.
confused-1.gif
 
R

reality

Vudu lešinar
24. jul 2007
4.731
0
36
zaenkrat je še zmeraj bolj en usb disk, pomožnosti usb 3.0. Je cenejš, manj potratno. Danes je štrom že kr bistvena postavka, pa še disk se ti ne vrti noč in dan.

Z raidi je vse fino fajn, dokler ne pride do nekosistenčnosti, če že maš diske v raidih skoraj pod mus morš met tud ups, ker blinkanje štroma ali sad je san ga ni, najbolj škoduje raidom.... Dobri kontrolerji pa tudi stanejo...

Če sumo potegnem, pristaneš na usb disku za nekaj eurov in je to to....... Drgač bomo pa pač mogli zaupati v oblake, bo sigurno najceneje in najvarneje.

moje mnenje....
 
Za odgovor se prijavite ali registrirajte.
Na vrhu Bottom