TP-Link TL-R600VPN VPN server z publicznym statycznym IP
Drugi TL-R600VPN - L2TP VPN client, łączy się do VPN serwera.
Komputer PC łączy się do tego samego serwera VPN.
IP serwera VPN (VPN IP): 172.16.0.1
IP klienta (TPLINK) 172.16.0.20
IP komputera (VPN) 172.16.0.3
Chciałbym z komputera PC dostać się do urządzeń po stronie LAN klienta VPN (w jego lokalnej podsieci 192.168.11.0/24
Z komputera PC mogę dostać się na .0.1 (serwer) oraz .20 (ping wraca).
Z urządzeń po stronie LAN klienta 0.20 mogę dostać się tylko do stacji 0.20.
Z samego klienta 0.20 mogę pingować tylko serwer 0.1, co wydaje mi się dziwne (dlaczego nie 0.3)?
Konfigurację klienta L2TP zrobiłem z opcją "routing" a nie "NAT" - tak w ogóle gdzie mogę znaleźć opis konkretny co te dwie opcje zmieniają?
Pomożecie skonfigurować te urządzenia we właściwy sposób? Jak ustawić routing?
To nie jest temat na jeden wpis. Musisz znać zasady działania stosu TCP/IP, routingu i NAT oraz jak działają poszczególne sposoby tworzenia VPNów.
W opisie brakuje w zasadzie większości istotnych szczegółów.
Dlatego na start zacznij od czytania... instrukcji obsługi routera. Dla L2TP masz tutaj: https://www.tp-link.com/en/configuration-guides/configuring_vpn/?configurationId=18575#_idTextAnchor002
Masz nawet przykład, jak połączyć dwa oddziały firmy z wieloma maszynami.
Co do komputera końcowego to nie podałeś nawet jak się łączysz (jaki klient, jakie ustawienia). Dla poszczególnych elementów sieci także nie ma najważniejszych opcji podanych.
Co do NAT i routing - jak sieć po drugiej stronie ma być dostępna w obie strony (a nie tylko do serwera VPN i podłączonych zasobów) to dobrze ustawiłeś, ale to tylko czubek góry lodowej.
Nie bardzo rozumiem jaka rola jest tego głównego serwera VPN tutaj - na razie wygląda jak sprzęt stojący gdzieś poza wszystkimi sieciami i stanowiący punkt pośredniczący - być może to rozwiązanie mało optymalne, ale brakuje szczegółów.
Ogólnie VPNy to trochę złożony temat jak się do tego siada od zera.
Dzięki za odpowiedź.
Na wstępie zaznaczę, że instrukcję obsługi routera przeczytałem i udało się zestawić połączenie L2TP oraz że nie jestem całkiem zielony w temacie sieci, nie siadam od zera do tematu.
Konfiguracja serwera VPN TL-R600VPN
Router jest wystawiony w DMZ routera od dostawcy internetu.
VPN IP Pool następujące:
"pula1" 172.16.0.2-10
"pula2" 172.16.0.20-20 (tak, tutaj ma być tylko 1 adres)
L2TP serwer z enkrypcją IPSEC
konfiguracja użytkowników VPN L2TP
-uzytkownik1, haslo1,
pula IP pula1, local IP address: 172.16.0.1,
client-to-lan
-uzytkownik2, haslo2,
pula IP: pula2, local IP address: 172.16.0.1
client-to-lan
Konfiguracja klienta - router VPN TL-R600VPN
WAN: nieznany adres IP, zakładamy również że niepubliczny. Dlatego odpada site-to-site
LAN 192.168.11.0/24
L2TP client - uzytkownik2, haslo2
serverIP: adres publiczny serwera vpn
remote subnet: 172.16.0.0/12
working mode: route
Takich klientów jak ten powyżej docelowo będzie więcej.
Konfiguracja klienta VPN - Windows 10
standardowo, zgodnie z uzytkownik1,haslo1
dostęp do internetu o nieznanej/zmiennej trasie. Przypuśćmy, że przydzielony komputerowi adres IP nie jest z podsieci 192.168.11.0
Żadnych dodatkowych przekierowań itp.
Tunel działa:
logując się z komputera do VPN komputer PC dostaje adres 172.16.0.3
Wpisując w przeglądarce 172.16.0.1 dostaję się do administracji serwera VPN
Wpisując 172.16.0.20 dostaję się do administracji klienta VPN
Co ma być:
chcę dostać się do urządzeń wpiętych do LAN stacji 172.16.0.20. Jak ustawić tablice routingu?
Proponuję trochę nauki w takim razie i dojdziesz sam co jest nie tak (bo szczegółowo jak to ustawić w tym interfejsie nie powiem na 100% bez dostępu do żywej aparatury).
Brakuje kilku założeń, zakładam domyślny sposób konfiguracji - IP w VPN służą tylko do komunikacji między węzłami VPN, a nie maszynami konkretnymi.
Ustaliliśmy, że połączenia VPN na warstwie pul VPNów działają poprawnie - dobiłeś się do interfejsów powiązanych z poszczególnymi węzłami (zakładam, że poprawnie).
Jedziemy głębiej:
Jaki adres wpisujesz na kliencie Windows (nazwijmy go WIN), żeby dostać do się podsieci (drugi VPN działający jako klient z podsiecią 192.168.11.*) VPN2?
Powiedzmy, że istnieje, żyje i jest włączona maszyna z adresem ..11.5:
ping 192.168.11.5
Co pokazuje WIN jak wyświetlisz tablice routingu? (route -a chyba w Windows się to robi)
Czy WIN wie gdzie kierować pakiety o adresach z puli powyżej?
Przypomnę: próba wysłania do Internetu pakietu kierowanego do pul prywatnych (10.x 192.168.x itd) powoduje domyślnie natychmiastowe wywalenie pakietu do kosza przez router - a nawet jak twój router tego nie zrobi, bo tak mu kazałeś, to następny u operatora z pewnością to zrobi).
Skąd Windows powinien dostać informację o tej puli?
(Utrudnienie przy podłączaniu kolejnych VPNx - skąd tamte komputery będą wiedziały jak odpowiedzieć?)
Jak ustawić pule IP w sieciach wewnętrznych, żeby się komputery z poszczególnych podsieci łączonych VPNami prawidłowo widziały (lub nie widziały)?
Warto stanąć w wyobraźni jako pakiet przed stosem TCP/IP i zobaczyć, co ten stos (na podstawie routingu i opisu interfejsów) zrobi z takim pakietem - po obu stronach patrząc na całą drogę - częsty błąd pojawia się wtedy, gdy dobrze ustawimy routing w jedną stronę, ale zwrotnie już zapomnimy o tym, że pakiet po drodze próbuje wracać w niewłaściwym interfejsem, albo co gorsza został przeadresowany przez NAT). A stos TCP/IP jest jednak dość prostym narzędziem i nie będzie się domyślał, o co nam chodziło, tylko wykona to, co ma w tablicach routingu, interfejsów i ew. NAT.
Dzięki za odpowiedź,
przemyślałem wszystko raz jeszcze i oto jaka jest sytuacja.
0. Router VPN jest w DMZ routera od dostawcy internetu, do którego nie mam dostępu. Routery HQ, Stacja A i Stacja B to routery VPN R600VPN.
Za podstawę połączenia VPN jest wzięty IPSEC. IPSEC w stacji HQ jest skonfigurowany jako responder, w trybie tunelowania. Jako LocalIP jest podany adres 10.0.0.253.
Między LANem Stacji A oraz 10.0.0.253 jest połączenie ipsec client 2 lan. Z poziomu routera HQ można pingować urządzenia w LANie stacji A i o to chodziło. Z poziomu LANu routera HQ również (zatem każde urządzenie w LANie routera HQ ma dostęp do każdego urządzenia w LANie Stacji A).
Z poziomu urządzenia w LANie stacji A można dostać się do 10.0.0.253 co jest ok, ale nie można dostać się do urządzeń w LANie HQ i tak ma być.
Analogicznie między stacją B a HQ.
Między stacją A a B nie ma być połączenia. Tych stacji będzie więcej w przyszłości (każda z innym lanem).
Komputer serwisowy ma klienta shrewsoft vpn za pomocą którego łączy się z HQ poprzez ten sam IPSEC co stacje. Komputer dostaje adres 192.168.254.5 (wirtualny, przydzielony przez ShrewSoft).
Komunikacja działa. Komputer serwis ma dostęp do 10.0.0.253. Tablica routingu pokazuje, że 10.0.0.253 jest bezpośrednio wpięty pod interfejs 192.168.254.5.
Pozostał tylko ostatni krok. Komputer serwis musi mieć dostęp do wszystkich LANów Stacji. Stacje między sobą nie mogą mieć do siebie dostępu.
Idealnym rozwiązaniem byłby cisco dmvpn ale to nie ten sprzęt. W jaki sposób w tym momencie ustawić routing?
Proszę o podpowiedź
Wchodzimy trochę w filozofię, ale mniej więcej takie mam uwagi:
Skąd ten adres 192.168.254.5? To nie może być nadawane lokalnie, jeżeli masz mieć wjazd do maszyn z sieci podłączonych pod A i B itd. To musi być adres znany wszystkim tym maszynom.
Patrz na połączenie z obu stron. Skąd pakiet wracający z LAN podpiętego do B ma wiedzieć, gdzie wysłać pakiet do adresu 192.168.254.5? Każdy stos TCP/IP po drodze musi mieć jasno zapisane w tabeli routingu, gdzie taki pakiet leci, albo zostanie wywalony w powietrze (efektem typowym będzie to, że pakiet do 192.168.11.xx doleci tamże, ale odpowiedź nie będzie miała jak wrócić - widać to będzie np. na licznikach pakietów na interfejsach, albo jak zaczniesz śledzić ruch.
Co do zasady (do złamania, ale jednak) maszyna serwisowa nie powinna mieć też adresu z puli 10.x, a tylko wykorzystywać ten adres na potrzeby VPN. Załóż sobie podsieć serwisową 192.168.254.xx i niech w niej siedzi komputer serwisowy (albo ich większa liczba), ale tę sieć musisz zadeklarować i rozgłaszać z HQ.
Usiłuję właśnie skonfigurować tablice routingu dla komputera Serwis i routera HQ.
Zaznaczę tylko dla jasności, że komputer Serwis łączy się po IPSEC do 10.0.0.253.
Tak wygląda na tę chwilę tablica routingu z zaznaczonymi na czerwono wpisami dokonanymi przez ShrewSoft. Jak widać komputer ma adres 192.168.254.5 a adres drugiej strony tunelu VPN do HQ 10.0.0.253 został wpisany jako znajdujący się bezpośrednio pod IF 8.
Załóżmy od teraz, że stacja A ma LAN 192.168.44.0/24 a LAN routera 192.168.44.1.
Jeżeli teraz bym próbował ping 192.168.44.1 to oczywiście od razu przekierowuje mnie w kosmos.
Jeżeli teraz dodam wpis na komputerze Serwis (przekierować wszystko co do sieci 192.168.44.0/24 na 10.0.0.253
route ADD 192.168.44.0 MASK 255.255.255.0 10.0.0.253 METRIC 1 IF 8
to tracert 192.168.44.1 pokazuje same * * * *
Jednocześnie będąc na komputerze serwisowym mogę przez przeglądarkę wejść na 10.0.0.253 i dostanę się na router HQ. Z routera HQ mogę pingować zarówno 192.168.44.1 jak i 192.168.55.5.
Ponadto, będąc podłączonym do LANu Stacji A mogę wejść na 10.0.0.253. (bo urządzenia w LANie stacji A mają tylko jeden interfejs dostępny i przekierowują wszystko na 192.168.44.1).
Router Stacji A ma wpis w tablicy routingu:
Destination IP 192.168.254.5/32
NextHop 10.0.0.253
Interface WAN
Router HQ ma wpisy w tablicy routingu:
Destination IP 192.168.44.0/24
NextHop 192.168.44.1
Interface WAN
Destination IP 192.168.254.5/32
NextHop 192.168.254.5
Interface WAN
Podpowiedź kolejna: Informacja co zrobić z pakietem musi być nie tylko na końcówce (serwis), ale także na wszystkich pośrednich stacjach routujących pakiety, a ponadto musi być w nich informacja, jak ten pakiet ma wrócić.
"Myśl" jak pakiet, a dokładniej jak stosy TCP/IP na całej trasie w obie strony: może dokładniej postaw się na miejscu pakietu (adres skąd i dokąd) i po kolei prześledź co dzieje się na każdym punkcie, gdzie pakiet jest rozbierany i analizowany. Wystarczy jedno miejsce, gdzie da pakietu nie ma informacji dokąd iść i do połączenia nie dojdzie.
Dlatego wynaleziono protokół ICMP (ping i rozwinięcie w postaci możliwości pingowania po kolei każdego punktu na trasie (traceroute). Brak odpowiedzi już na za pierwszym routerem wskazuje, że może tablica routingu jest błędna już za rogiem.
Ja to rozumiem, że informacja musi być na wszystkich stacjach pośrednich. Ale skoro z komputera Serwis wraca bezpośredni ping do HQ to jeśli dodałem wpis do tablicy routingu jak w poście wyżej tj route ADD 192.168.44.0 MASK 255.255.255.0 10.0.0.253 METRIC 1 IF 8 to znaczy, że próbując wbić na 192.168.44.1 przykładowo pakiet powinien lecieć przez HQ. I w tym momencie mam już **** od razu na pierwszym kroku po tracert. Jak zatem poprawnie powinien wyglądać taki wpis w tablicy routingu? Proszę bez podpowiedzi tylko jeśli można o konkret.
