From: Ozan Eren Bilgen (oebilgen@uekae.tubitak.gov.tr)
Date: Tue 01 Nov 2005 - 14:02:43 EET
On Tue, 2005-11-01 at 13:39 +0200, Can Erkin Acar wrote:
> Ozan Eren Bilgen wrote:
> > On Tue, 2005-11-01 at 10:46 +0200, Can Erkin Acar wrote:
> >
> >>Ozan Eren Bilgen wrote:
> >>
> >>>Ŭletilen verinin güvenligi de söz konusu. SSH+PPP'li cozumun
> >>>yonetilebilirligi düsük. Onun haricinde IPSec+PPTP var fakat PPTP iyi
> >>>bir çözüm degil deniyor TLDP'de.
> >>>
> >>>Acikcasi 4. katmanda sifreli veri olmasini tercih ediyor ve bu sebepten
> >>>IPSec'in kesin aktör olmasini ongoruyoruz. Nasil bir cözüm onerirdiniz?
> >>
> >>A ve B uzerinde bir ayar yapmak istemediginiz icin
> >>SSH ve/veya PPP anlamli degil. Onceki mesajinizdan
> >>tum ayarlamalari B ve C uzerinde yapmak istediginizi anliyorum.
> >
> >
> > A -> B *** Ŭnternet *** C <- D
> >
> > Ayarlari mümkün oldugunca A ve D'ye tasimak istiyorum. Bu tabi %100
> > mümkün degil, fakat özellikle IPSec kŭsmŭ A ve D'de olmasi daha iyi,
> > zira oraya tam erisim soz konusu fakat B ve C ayarlari cakili kalacak.
> >
> >
> >>B ve C arasina bir tunel kurmaniz gerek. GRE bir cozum IPSec de.
> >
> >
> > Tunel kuramiyoruz. Tunel kurmak icin B ve C'ye (yonlendiricilere)
> > yonetici yetkisiyle ulasmak gerekir bu surekli talep edilemez.
>
> Ok, ben B ve C uzerinde cozmek istediginizi dusunmustum.
> Yanlis anlamisim.
>
> Surekli talep edilemez derken?
> Sadece bir kere yonetici yetkisi ile IPSec tunel tanimlattirsaniz?
> Eger bastan dogru ag bloklari arasinda tunel tanimlatirsaniz
> sonra yeni baglantilar icin ayrica yonetici erisimi gerekmez ;)
Elbette, fakat elle anahtar degisimi konusu ayri problemler yaratir.
> >>IPSec 4. katman ile ilgilenmiyor, siz ayrica uygulama duzeyinde
> >>sifreleme yapacaksaniz GRE de yeterli olabilir. Iki network arasi
> >>trafik sifrelenmeden akacaktir.
> >
> >
> > IPSec devreye girince 4-5-6-7 kapali oluyor ve istedigimiz sey bu.
> >
> > NAT aygitlarindaki IPSec-passthrough ozelligini onerdiler. Ne
> > düsünüyorsunuz?
>
> Pass through ozelliginin bir sinirlamasi var:
> Her ag uzerinde *tek bir* istemci ayni uc ile haberlesebilir.
> Yarin D nin yanina A ile haberlesecek bir de E eklemek isterseniz
> sorun olacaktir.
>
> Her durumda B ve C nin en az bir tanesi uzerinde gelen istekler
> icin bir yonlendirme tanimlamaniz gerek. Sonucta baglantinin
> kurulmasi icin A veya D den birine ilk paketlerin ulasmasi lazim
> hangi protokol olursa olsun bu gerekli.
Iptables *bile* SPI'ya bakarak yonlendirme yapabiliyor, sanirim bu
yeterli olacaktir, eger sorun buradaysa. A, D ve E'ye ayri AH ve ESP SPI
adresleri atanirsa, yonlendirme sorun olmaz. Bir cesit IP gorevi
gorurler.
Bu IPSec-passthrough konusunu anlatan belge bulamadim. Bildiginiz varsa
lutfen payalasir misiniz?
> Sadece iki makina arasinda haberlesecekseniz ve disaridan ssh ile
> hedefe erisebiliyorsaniz, ssh port forwarding cozum olabilir.
> Bizim ekipten Sezai, evden baglanirken karsi tarafin IP adres(ler)ini
> alias olarak kendi bilgisayarinda tanimliyor ve ssh tuneli uzerinden
> hedefe rahatlikla erisebiliyor.
>
> Eger SSH istemiyorsaniz ve her durumda (en az) bir yonlendiricide
> ayar yapacaksiniz. IPSec NAT-T de uygun degilse, o zaman OpenVPN
> sizin icin en uygun cozum gibi gozukuyor. OpenVPN UDP (veya cok
> isterseniz TCP) protokolu kullaniyor, yonlendirici uzerinde
> ilgili portu hedef makinaya yonlendirmeniz yeterli olacaktir.
Istemci-sunucu yazilimlarina (dolayisiyla SSH'a, OpenVPN'e) sicak
bakmiyorum. Bu isi mumkun oldugunca asagida cozmeyi daha saglikli ve
temiz buluyorum.
> Yine de, eger kalici bir tunel olacaksa ve ileride aglar arasi baska
> baglantilar da gerekecekse, o zaman yonlendiriciler uzerinde
> iki ag arasi VPN ayarini bir kere yapin ve rahat edin derim.
>
>
> Iyi calismalar
>
> Can
>
>
_______________________________________________
Linux-ag mailing list
Linux-ag@liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-ag