From: Can Erkin Acar (can.acar@pro-g.com.tr)
Date: Tue 01 Nov 2005 - 15:50:19 EET
Ozan Eren Bilgen wrote:
> On Tue, 2005-11-01 at 13:39 +0200, Can Erkin Acar wrote:
>
>>Ozan Eren Bilgen wrote:
[snip]
>>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.
Elle anahtar degisimi?
IKE kullanirsaniz anahtar degisimi probleminiz olmayacaktir.
Uclar arasindaki guven iliskisini de sertifikalarla tanimlarsiniz
paylasilan anahtar bile kalmaz ortada.
>>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.
Bunun icin bile yonlendirme isini B ve C de tanimlamak lazim.
B ve C linux mu? SPI ye gore filtrelerken bir tarafta NAT yapip sonra
da gercek kaynak IP adresi (orn. D) ile hedefe (A) ulastirmak pek cok
ticari urunde bulamayacaginiz kadar ince ayar gerektirecektir.
IPSec yaninda hep IKE kullandigim icin SPI lerin elle ve sabit
tanimlanmasini goz onune almadim. Bence de tunelleri elle kurmak
ve duzenli anahtar degistirmeye calismak sistem yoneticisine
cok fazla yuk getirecektir.
Genellikle IPSec kulanirken tuneli IKE ile kurup anahtar degisimini ve
SPI atanmasini otomatiklestirmek tavsiye edilir (en azindan periyodik
anahtar degistirdigi icin daha guvenli). Ancak eger SPI ye gore
filtreleme gerekecekse IKE ortaligi karistiracaktir.
> Bu IPSec-passthrough konusunu anlatan belge bulamadim. Bildiginiz varsa
> lutfen payalasir misiniz?
Boyle bir konu aslinda yok ;) Sadece NAT-T becerisi olmayan uclarin
NAT uzerinden haberlesebilmesini saglamak icin uretilmis cesitli
zorlama cozumler. Passthrough yapan cihazin kalitesi ve becerisi ile
sinirli kaliyorsunuz, genelde de daha once bahsettigim ayni hedefe tek
istemci sinirlamasina takiliyorsunuz. Tum protokolu genel olarak
dusundugumuzde passthrough yapmak icin sadece AH/ESP paketlerini degil
IKE (udp port 500) paketlerini de uclar arasinda eslestirmek ve ikisi
arasinda iliskiler kurmak durumunda kaliyorsunuz. IKE sonucunu ve
kararlastirilan protokolu ve SPI leri bilmediginiz icin de bu
eslestirmeyi guvenli ve dogru yapmak mumkun olamiyor.
>>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.
Eger saglikli ve temiz cozum istiyorsaniz B ve C uzerinde
kurun IPSec tunelinizi. IKE ile de anahtar degisimi problemini
halledersiniz. Bu yontemin tek dezavantaji A-B ve C-D arasinda
bir sifreleme olmamasi olabilir.
Can
-- Dr. Can E. Acar Pro-G Bilisim Guvenligi ve Arastirma Ltd. http://www.pro-g.com.tr _______________________________________________ Linux-ag mailing list Linux-ag@liste.linux.org.tr http://liste.linux.org.tr/mailman/listinfo/linux-ag