Forum Debian Users Gang

[quote=jurgensen]Łącząc tylko dwa hosty, bez podsieci powinieneś użyć trybu transportowego. Przykład takiej konfiguracji znajdziesz tu: [url]http://www.infond.fr/2010/04/basics-9-tutorial-ipsec-transport-mode.html[/url][/quote]
Dzięki za zwrócenie uwagi. Rzeczywiście porąbałem strony, a ten link super. teraz działa :)

@Jacekalex, dzięki za sugestie, zapewne też tym się pobawię. swego czasu na strongswanie robiłem l2tp/ipsec ale to były dawne czasy, że aż nie prawda.
tak ogólnie, co jest lepsze, racoon czy strongswan?

Witam ponownie.
Trochę się pobawiłem oboma rozwiazaniami. Z jednej strony strongswan jest "lepiej" udokumentowany w przykładach, z drugiej racoon+setkey wydaje się być łatwiejszy, aczkolwiek oba prowadzą do tego samego i chyba skłonie się do strongswana.

Chcę teraz połączyć odległe sieci w jedną. w obu lokalizacjach załóżmy że jest ta sama sieć 192.168.0.0/24, bramy połączone ipsec'iem. ze względu na brak możliwości przeadresowywania sieci w jednej lokalizacji będzie serwer dhcp, z którego hosty w drugiej lokalizacji będą pobierać adresy.
Chcę uzyskać coś w stylu bridge w OpenVPN, czyli cały ruch l2 ma "przechodzić" do drugiej lokalizacji łącznie z broadcastem i multicastem.

                                                   RGW1                    RGW2
(sieć 192.168.0.0/24)---[eth1:192.168.0.1--eth0:1.2.3.4.5]===inet===[eth0:6.7.8.9--eth1:192.168.0.2]---(sieć 192.168.0.0/24)

chcę osiągnąć bridgea pomiędzy eth1 na RGW1 i eth1 RGW2 a nie mogę znaleźć exampla do tego rozwiązania :/
może ktoś podzieli się przykładem? z góry dzięki

[quote=Jacekalex]

leftsubnet=0.0.0.0/0

Wszystko powinno iść przez vpna po zestawieniu tunelu.[/quote]
hmm, L3 tak, a L2 i multicast?

[quote=Jacekalex]Za to OpenVPN chodzi jak każda usługa ssl, nie wymaga żadnych kombinacji z ustawieniami sieci i firewalla po stronie klienta,
i wymaga tylko jednego otwartego portu na serwerze.[/quote]
Gdyby jeszcze nie ograniczenie interfejsu do 10M to byłaby to rewelacja.

IPsec nie obsługuje bezpośrednio połączeń w warstwie 2. Na OpenBSD zrealizowałem to, tworząc wirtualne interfejsy gif na zewnętrznych adresach. Na nich zestawiłem IPSec w trybie transportowym z opcją etherip. Później zrobiłem bridge między interfejsem gif oraz interfejsem zewnętrznym i miałem połączenie w warstwie 2.

ps. jeśli masz niewielką przepustowość łącza i duży ruch w sieci, broadcasty mogą je całe zapchać.

Ostatnio edytowany przez jurgensen (2013-03-22 21:40:22)

gif to wirtualny interfejs, wykorzystywany do tuneli (podobny, do znanego m.in. z Cicsco gre - różni się tylko enkapsulacją danych). Tunel można zestawić bez IPSeca, właśnie przy użyciu tych interfejsów. Na istniejącym już tunelu konfigurowałem IPSec dla zachowania integralności danych i szyfrowania. Interfejs gif korzysta z zewnętrznego interfejsu do zestawienia tunelu, natomiast zbridgowany jest z wewnętrznym interfejsem, aby właśnie połączyć sieć wewnętrzną z tunelem, który na drugim końcu również jest zbridgowany z siecią wewnętrzną. Wszystko może obyć się oczywiście bez IPSeca. Służy on wyłącznie do szyfrowania. Jeśli będziesz chciał, mogę odgrzebać działającą konfigurację i wrzucić tu (dla OpenBSD, nie Debiana).

[quote=Jacekalex]Z tego, co widzę, po podniesieniu interfejsu tap domyślna prędkość tapX wynosi 10m.
Na forum openvpn piszą, ze jak interfejs tap ruszy z inną prędkością, to openvpn powinien to załapać.
Ale nie mam w tej chwili pomysłu, jak ustawić 100 lub 1000M na tapX.
ethtool nie ogarnia tego interfejsu, w modinfo tun też nic ciekawego nie widziałem.[/quote]
tap jest do L3 (co nie zmienia faktu jego prędkości 10M), do L2 używam tun. Gdyby w openvpn były "normalne" prędkości do bym nie kombinował dla moich 3 rw, z których jeden to ja :)
[quote=jurgensen]gif to wirtualny interfejs, wykorzystywany do tuneli (podobny, do znanego m.in. z Cicsco gre - różni się tylko enkapsulacją danych). Tunel można zestawić bez IPSeca, właśnie przy użyciu tych interfejsów. Na istniejącym już tunelu konfigurowałem IPSec dla zachowania integralności danych i szyfrowania. Interfejs gif korzysta z zewnętrznego interfejsu do zestawienia tunelu, natomiast zbridgowany jest z wewnętrznym interfejsem, aby właśnie połączyć sieć wewnętrzną z tunelem, który na drugim końcu również jest zbridgowany z siecią wewnętrzną. Wszystko może obyć się oczywiście bez IPSeca. Służy on wyłącznie do szyfrowania. Jeśli będziesz chciał, mogę odgrzebać działającą konfigurację i wrzucić tu (dla OpenBSD, nie Debiana).[/quote]
Dzięki, już nie co kumam. Nie chciałbym nadwyrężać Twojej dobrej woli żebyś szukał tej konfiguracji, ale jak znajdziesz chwilkę i odrobinę chęci, to fajnie byłoby to zobaczyć. Może coś by się wykombinowało pod debiana.

Ostatnio edytowany przez Nicram (2013-03-22 22:30:52)

Dzięki @jurgensen, zasada jest jasna i właśnie takie coś chcę osiągnąć. teraz kwestia tego tunelu. jak wcześniej wspomniałeś gif to interfejs tunelujący podobny do gre, z tym, że podobny to nie identyczny :) jaki odpowiednik tego tunelu będzie w linuxie/debianie? czyżby ipip? bo reszta jest jasna

[quote=jurgensen]gif to właściwie to samo, co gre, różni się jedynie sposobem enkapsulacji danych. Wydaje mi się, że na gre powinno to również działać, ale nie jestem na 100% pewien.[/quote]
właśnie sprawdziłem. nie mogę dodać interfejsu tunelowego do bridgea :/

ip tunnel add tunel0 mode gre remote 10.21.7.15 local 10.21.7.57
ip link set up dev tunel0
...
~#brctl addbr br0
~#brctl addif br0 tunel0 
can't add tunel0 to bridge br0: Invalid argument

jakieś sugestie?

-------------

gretap

Ostatnio edytowany przez Nicram (2013-03-23 15:01:15)

zrobiłem to tak i działa :)

Host A:

ip link add gretap0 type gretap local 172.31.0.1 remote 172.31.0.2
ip link set dev gretap0 up
ip link set dev eth1 up
brctl addbr br0
brctl addif br0 gretap0
brctl addif br0 eth1
ip addr add 10.10.10.1/24 dev br0
ip link set br0 up

Host B:

ip link add gretap0 type gretap local 172.31.0.2 remote 172.31.0.1
ip link set dev gretap0 up
ip link set dev eth1 up
brctl addbr br0
brctl addif br0 gretap0
brctl addif br0 eth1
ip addr add 10.10.10.2/24 dev br0
ip link set br0 up

dodatkowo między hostami 172.31.0.2 i 172.31.0.1 ustawiłem ipseca i działa. podsłuchując tcpdumpem na br0 i próbując pingować coś z sieci br0 widzę zapytania arp więc L2 działa :)
słuchając na interfejsach zewnętrznych (172.31.0.1) widzę ruch szyfrowany ESP :) jednym słowem super.

dzięki za sugestie