|
Tunel VPN - łączenie sieci
|
| sszpila |
Dodano 27-02-2012 19:51
|
User
Posty: 147
Dołączył: 20/08/2009 10:59
|
Witam. Problem następującego typu:
Do połączenia mam dwie odległe sieci o różnych adresacjach, tzn. 10.2.1.0/24 i 10.3.1.0/24. Routery to WRT54G-TM z tomato k24 v83 oraz Asus RT-N16 z tomato k26 v85. Połączone ze sobą tunelem TUN na kluczu statycznym z adresacją 10.8.0.1 - 10.8.0.2. Tunele zestawiają się bezproblemowo. Z każdego routera można pingować obie strony tunelu i oba routery. Trasy routingu są ustawione poprawnie, także wpisy iptables w łańcuchach INPUT i FORWARD wyglądają na poprawne. Problemem jest to, że nie mogę pingować komputerów w sieci klienta VPN z sieci serwera VPN, nawet z routera gdzie jest serwer VPN. Z routera gdzie jest klient VPN mogę pingować wszystkie komputery w sieci serwera VPN. |
| |
|
|
| js1972 |
Dodano 28-02-2012 20:15
|
User
Posty: 3
Dołączył: 28/02/2012 20:13
|
A nie lepiej zestawić tunel TAP? |
| |
|
|
| sszpila |
Dodano 29-02-2012 08:12
|
User
Posty: 147
Dołączył: 20/08/2009 10:59
|
TAP jest fajny, jeśli mam dołączyć się jednym komputerem do sieci i mają broadcasty działać. W przeciwnym razie musiałbym chociażby wycinać ruch DHCP żeby komputery raz z jednego, a raz z drugiego routera nie pobierały sobie adresu. Na TAP'ie pewnie że da się to zrobić, ale to wiąże się z przykładowo z wydzieleniem odobnego bridge z własnym serwerem DHCP i później zmostkowaniu go z br0. TUN idealnie nadaje się do połączeń site to site, tylko nie wiem czemu to nie chce działać jak potrzeba.
Połączony z 29 luty 2012 08:31:02:
Konfiguracja serwera:
# Automatically generated configuration
daemon
ifconfig 10.8.0.1 10.8.0.2
proto tcp-server
port 1196
dev tun22
comp-lzo adaptive
keepalive 15 60
verb 3
secret static.key
status-version 2
status status
# Custom Configuration
persist-tun
persist-key
route 10.3.1.0 255.255.255.0
log /dev/null
Konfiguracja klienta:
# Automatically generated configuration
daemon
dev tun11
proto tcp-client
remote xxxx 1196
ifconfig 10.8.0.2 10.8.0.1
resolv-retry 30
nobind
persist-key
persist-tun
comp-lzo adaptive
verb 3
secret static.key
status-version 2
status status
# Custom Configuration
route 10.2.1.0 255.255.255.0
log /dev/null
Trasy na serwerze:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
89.68.112.1 0.0.0.0 255.255.255.255 UH 0 0 0 vlan2
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun22
10.3.1.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun22
10.2.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
89.68.112.0 0.0.0.0 255.255.252.0 U 0 0 0 vlan2
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 89.68.112.1 0.0.0.0 UG 0 0 0 vlan2
Trasy na kliencie:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun11
82.139.48.1 0.0.0.0 255.255.255.255 UH 0 0 0 vlan1
10.2.1.0 10.8.0.1 255.255.255.0 UG 0 0 0 tun11
10.3.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
82.139.48.0 0.0.0.0 255.255.248.0 U 0 0 0 vlan1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 82.139.48.1 0.0.0.0 UG 0 0 0 vlan1
Na serwerze i kliencie dodane dla pewności regułki:
iptables -A FORWARD -i tun+ -o br0 -j ACCEPT
iptables -A FORWARD -i br0 -o tun+ -j ACCEPT
I działa jak działa. Z klienta widzę sieć LAN za serwerem, ale w drugą stronę już nie, sygnał umiera na routerem.
Edytowany przez sszpila dnia 29-02-2012 08:32
|
| |
|
|
| mieszk3 |
Dodano 29-02-2012 12:29
|
Power User
Posty: 201
Dołączył: 09/02/2008 18:17
|
mam to samo niestety. Mecze temat juz dlugo i dalem sobie spokoj na razie. Dlatego tez podpinam sie pod temat.
Asus RT-AC66U + FreshTomato Firmware 2020.2 MIPSR2 K26AC USB AIO-64K
|
| |
|
|
| sszpila |
Dodano 29-02-2012 15:11
|
User
Posty: 147
Dołączył: 20/08/2009 10:59
|
A może to wina wersji openVPN na tomato ? Bo google uparcie twierdzi że takie rozwiązanie wszystkim działa, wszystkie poradniki opisują jedną i tą samą konfigurację, z tym że na pełnoprawne linuxy i instalacje na nich openVPN. Może u nas w tomato coś jest zrąbane. Zobaczcie: http://www.mcbsys.com/techblog/2011/1...ith-tomato Niby ma działać a nie działa... Przy autoryzacji TLS też próbowałem - nie działa jak opisują 
Edytowany przez sszpila dnia 29-02-2012 15:26
|
| |
|
|
| js1972 |
Dodano 29-02-2012 19:54
|
User
Posty: 3
Dołączył: 28/02/2012 20:13
|
Ja też męczyłem się najpierw z TUN i nie mogłem sobie poradzić przesiadłem się na TAP i wszystko jest w zasadzie ok. poza DHCP. W każdej z sieci jest serwer DHCP z jednej strony bezpośrednio na routerze a z drugiej na windowsowym serwerze podłączonym do routera. No i niestety klienci czasami podbierają adresy ze złego serwera co powoduje że ruch do internetu przekierowany jest przez tunel VPN (mimo odznaczonych opcji na routerach) Nie wiem jak rozwiązać ten problem. Jak wiesz jak sobie z tym poradzić (Ewentualnie jak poradzisz sobie z konfiguracją TUN) to podziel się wiedzą bedę wdzięczny bo męczę się z tym bez efektów już parę dni. |
| |
|
|
| sszpila |
Dodano 29-02-2012 20:31
|
User
Posty: 147
Dołączył: 20/08/2009 10:59
|
Da się to zrobić oczywiście. Ale niestety nie znam szczegółów strony serwera, moja rola ograniczała się do poskładania strony klienta, co też takie łatwe nie było. W skrócie po stronie serwera VPN wyglądało to tak, że został utworzony nowy bridge, dajmy na to br1, z inną adresacją niż sieć LAN na br0. W tym br1 działał serwer DHCP, który przydzielał adresy klientom VPN. Następnie bridge br1 został zmostkowany z br0 plus odpowiednie trasy wysyłane do klientów, żeby mieli dostęp do sieci LAN. Na klientach trzeba było napisać skrypty up/down do openVPN'a oraz skrypt klienta udhcpc zeby ustalić na interfejsie tap adres otrzymany od serwera VPN. |
| |
|
|
| falitorek |
Dodano 29-02-2012 20:46
|
User
Posty: 140
Dołączył: 04/03/2006 21:30
|
Może warto sprawdzic ten opis.
Osobiście nie testowałem ale opis jest godny uwagi.
http://radziu.jogger.pl/2011/10/30/op...eci-sieci/
Jak coś z tego wyjdzie to dajcie znac bo na razie nie mam czasu na testy 
1xRT-N16
2xWRT610N v2
1xQNAP TS-110
1xPCH C-200
|
| |
|
|
| js1972 |
Dodano 29-02-2012 22:27
|
User
Posty: 3
Dołączył: 28/02/2012 20:13
|
Dzięki za pomoc wkleiłem poniższe regułki na kliencie i wygląda na to że problem z DHCP rozwiązany. Jak coś wymyślicie z TUN to dajcie znać - może sie kiedyś przyda.
#Block DHCP between OpenVPN TAP
ebtables -I FORWARD -i tap21 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I FORWARD -o tap21 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I INPUT -i tap21 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I OUTPUT -o tap21 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
#Block UPnP between OpenVPN TAP
ebtables -I FORWARD -i tap21 -p IPv4 --ip-protocol udp --ip-destination-port 1900 -j DROP
ebtables -I FORWARD -o tap21 -p IPv4 --ip-protocol udp --ip-destination-port 1900 -j DROP
ebtables -I INPUT -i tap21 -p IPv4 --ip-protocol udp --ip-destination-port 1900 -j DROP
ebtables -I OUTPUT -o tap21 -p IPv4 --ip-protocol udp --ip-destination-port 1900 -j DROP |
| |
|
|
| psoft |
Dodano 01-03-2012 14:35
|
User
Posty: 46
Dołączył: 26/04/2006 19:56
|
To może zadam podstawowe pytanie:
Czy komuś wogóle działa na tomato połączenie dwóch sieci przez TUN?
Moje boje z openVPN na tomato dały taki sam efekt jak pierwszym poście. |
| |
|
|
| sszpila |
Dodano 01-03-2012 14:50
|
User
Posty: 147
Dołączył: 20/08/2009 10:59
|
Przeszukując zasoby naszego forum, wydawało mi się że Shibby kiedyś wspominał, że przestawił u siebie połączenie dwóch sieci z TAP na TUN i działało mu to w dwie strony |
| |
|
|
| ml |
Dodano 01-03-2012 21:30
|
User
Posty: 21
Dołączył: 22/01/2012 23:09
|
Potwierdzam działaie OpenVPN w Tomato w takiej konfiguracji (połączenie dwóch sieci poprzez TUN). OpenVPN mam jednak skonfigurowany i uruchomiony ręcznie, bo potrzebowałem w sumie 5 różnych konfiguracji tuneli, a wyklikać się da tylko 4.
Oto pliki konfiguracyjne:
daemon
dev tun10
ifconfig 192.168.110.1 192.168.110.2
proto udp
port 1310
secret secret.key
persist-tun
persist-key
keepalive 30 300
script-security 2
comp-lzo
route 192.168.6.0 255.255.255.0
user openvpn
group openvpn
daemon
dev tun10
ifconfig 192.168.110.2 192.168.110.1
remote xxxxxxxxxxxxxxxxx.pl 1310 udp
secret secret.key
nobind
persist-tun
persist-key
keepalive 30 300
script-security 2
comp-lzo
route 192.168.7.0 255.255.255.0
user openvpn
group openvpn
Taką konfigurację miałem wcześniej na zwykłym linuxie, teraz przeniosłem właściwie 1:1 na tomato i bez problemu działa :) |
| |
|
|
| sszpila |
Dodano 02-03-2012 08:57
|
User
Posty: 147
Dołączył: 20/08/2009 10:59
|
Widzę że konfiguracja w zasadzie niczym się nie różni od mojej. W zasadzie tylko poleceniem nobind w kliencie. Potestuję dziś wieczorem i zobaczymy czy coś to zmieni.
Połączony z 02 marzec 2012 20:06:56:
No i niestety nie działa. W dalszym ciągu nie ma dostępu do sieci za routerem klienta openvpn
Edytowany przez sszpila dnia 02-03-2012 20:06
|
| |
|
|
| ml |
Dodano 02-03-2012 21:59
|
User
Posty: 21
Dołączył: 22/01/2012 23:09
|
Moja konfiguracja różni się jeszcze tym, że mam równorzędne połączenia UDP zamiast TCP klient-serwer. Próbowałeś takiej konfiguracji?
Połączenie poprzez tun jest chyba taką najbardziej typową i najprostszą konfiguracją - to raczej musi działać  Na pewno OpenVPN z Tomato nie jest zrąbane, bo u mnie działa dobrze (Netgear WNR3500Lv2, Tomato V083)
Stosowanie zamiast routera (tun) mostu (tap) w opisanym przypadku, spowoduje właśnie przesyłanie broadcastów przez tunel, co obciąży niepotrzebnie łącze.
Proponuję zatem:
1. Sprawdzić konfigurację z UDP
2. Prześledzić dokładnie ruch sieciowy - w optware dostępny jest tcpdump, najlepiej go zainstalować na obu routerach i po kolei jak "woltomierzem" wpinać się w poszczególnych punktach sieci i patrzeć co się dzieje na poszczególnych interfejsach. Pakiety muszą przejść te wszystkie punkty tam i z powrotem:
komputer w sieci 10.2 <-> serwer br0 <-> serwer tun22 <-> klient tun11 <-> klient br0 <-> komputer w sieci 10.3
3. Sprawdzić wszystkie reguły iptables - wywołanie poniższych poleceń
iptables -A FORWARD -i tun+ -o br0 -j ACCEPT
iptables -A FORWARD -i br0 -o tun+ -j ACCEPT
Powoduje dopisanie reguł na końcu łańcucha FORWARD, a wcześniej w tym łańcuchu mogą być reguły które dropują pakiety.
Najlepiej reguły sprawdzić z opcją verbose (iptables --list -nv)
Spowoduje to wypisanie przy każdej regule ilości pakietów przetworzonych przez tę regułę, jeżeli będzie "0", to właśnie będzie znaczyło że ta reguła nie była w ogóle zastosowana.
Pozdrawiam
ml |
| |
|
|
| sszpila |
Dodano 03-03-2012 08:44
|
User
Posty: 147
Dołączył: 20/08/2009 10:59
|
Niestety, na UDP też nie zaskoczyło. Ale zrobiłem coś innego.
W akcie desperacji zamieniłem rolami serwer i klienta VPN. I teraz serwerem jest WRT54G-TM z v83 k24 a klientem RT-N16 z v85 k26. Komunikacji po TCP, klucz statyczny etc. I wiecie co? Zaskoczyło od pierwszego strzału. Mogę teraz z serwera pingować całą sieć za klientem VPN, w drugą stronę, tzn. z klienta sieć serwera VPN jeszcze nie wiem, bo żaden komputer nie jest włączony. Później dam znać czy działa. Może to był problem styku kerneli 2.4 i 2.6 ?
Połączony z 03 marzec 2012 09:17:57:
ewentualnie coś nie tak jest z tomato na k24. Bo w jednym i drugim przypadku z WRT54G mam dostęp do sieci za Asusem z k26, a w drugą stronę już nie.... Wieczorem zdam relację czy działa komunikacja w dwie strony.
Połączony z 03 marzec 2012 15:38:22:
No i nie działa. Wybitnie jest problem z komunikacją z Asusa na Linksysa. Konfiguracje tomato są absolutnie identyczne na obu routerach. Różnią się tylko wersjami kerneli i brakiem obsługi ipv6 w linksysie.
Edytowany przez sszpila dnia 03-03-2012 15:38
|
| |
|
|
| hermes-80 |
Dodano 03-03-2012 15:42
|
VIP
Posty: 3676
Dołączył: 21/04/2009 11:24
|
A jaki problem jest zainstalowanie na WRT54G-TM Tomato z k2.6??
===============================================================
Netgear WNR3500L v1
Podziękowania dla administracji Openlinksys.info!
|
| |
|
|
| ml |
Dodano 03-03-2012 21:56
|
User
Posty: 21
Dołączył: 22/01/2012 23:09
|
Generalnie nie może to być problem "styku" kerneli, bo kernele się bezpośrednio nie komunikują. Taka konfiguracja działa nawet jeżeli z jednej strony jest Windows a z drugiej Linux/Tomato - mam też i taki tunel na swoim Tomato.
Proponuję sprawdzić pkt 2 i 3 z mojego poprzedniego postu. Możliwości jest wiele - teoretycznie problem może być nawet po stronie tych końcowych komputerów (np. jakieś dodatkowe wpisy w tablicy routingu, przez które pakiety idą nie tam gdzie trzeba). Dlatego chyba najprościej będzie sprawdzić snifferem co się dzieje w poszczególnych punktach - to jest metoda skuteczna i mało inwazyjna
Pozdrawiam
ml |
| |
|
|
| rogalix |
Dodano 04-03-2012 12:24
|
User
Posty: 21
Dołączył: 04/03/2012 12:09
|
Witam.
Włączę się do dyskusji. Według mnie rozwiązanie na TAP z wydzieloną nawet kolejną siecią LAN dla VPN z własnym dhcp (nawet dla 2 punktów) i wyrutowaniem tras jest czytelniejsze i co najważniejsze przetestowane i co jest jeszcze zaletą skalowalne o kolejne punkty. |
| |
|
|
| ml |
Dodano 04-03-2012 21:37
|
User
Posty: 21
Dołączył: 22/01/2012 23:09
|
Moim zdaniem jest zupełnie odwrotnie. Tunel z TAP to działa po prostu jak most w warstwie 2 - przekazuje wszystkie pakiety w obie strony. Tunel z TUN działa jak router w warstwie 3 - przekazuje pakiety między sieciami jeżeli jest to potrzebne.
Skoro mówimy o połączeniu site-to-site, to znaczy że łączymy dwie autonomiczne sieci i wówczas naturalne jest zastosowanie TUN. Konfiguracja jest prosta, nie trzeba tworzyć żadnych mostów, nie trzeba wycinać/przekonfigurowywać dhcp, itd. Jedyne co trzeba zrobić to dodać odpowiednie wpisy w tablicy routingu, co załatwia nam już OpenVPN.
TAP byłby z kolei lepszy w przypadku połączenia client-to-site - wówczas pojedynczy komputer byłby widziany w sieci dokładnie tak samo jak gdyby był wpięty do niej "fizycznie". Czyli krótko mówiąc zgadzam się w 100% z tym co napisał sszpila w poście #3 w tym wątku
Jeżeli chodzi o skalowalność, to właśnie łączenie sieci przez TAP spowoduje wzmożony ruch wewnątrz tunelu, bo będą tam przesyłane broadcasty z wszystkich podsieci. Problem będzie narastał proporcjonalnie do liczby komputerów w sieci, czyli będzie to właśnie rozwiązanie nieskalowalne Inaczej stosowanie TUN nie miałoby w ogóle żadnego sensu...
Generalnie zależy też co chcemy osiągnąć - w przypadku zastosowania TAP np. wszystkie komputery z systemem Windows będą się wzajemnie widzieć w otoczeniu sieciowym, bo protokół NetBIOS opiera się właśnie o broadcasty. W przypadku połączenia dwóch małych sieci broadcastów nie byłoby dużo, a konfiguracja byłaby prosta, bo nie trzeba byłoby stosować np. serwera WINS. Z drugiej jednak strony przy łączeniu kilku autonomicznych oddziałów firm może to być wadą.
Pozdrawiam |
| |
|
|
| sszpila |
Dodano 05-03-2012 12:00
|
User
Posty: 147
Dołączył: 20/08/2009 10:59
|
Nie mam jak zainstalować optware na WRT. Nie ma w nim ani usb, ani sdmoda. Chyba że ktoś udostępni mi wszystkie potrzebne pliki do tcpdumpa i pcapa i jakoś wrzucę je do ramu routera i stamtąd odpalę. Fleszowanie do k26 też na jakiś czas odpada, router jest 100km ode mnie.
Połączony z 10 marzec 2012 22:04:17:
Witam po przerwie.
Profilaktycznie wyzerowałem NVRAM w WRT54G-TM i wprowadziłem od nowa konfigurację sprzętu i serwera OpenVPN i wszystko działa jak należy. Także konfiguracja klient-serwer na TUNie którą tu zamieściłem działa jak najbardziej poprawnie.
Edytowany przez sszpila dnia 10-03-2012 22:04
|
| |
|
' target='_blank'>Link
