TL-R600VPN routing do podsieci LAN


#1

Cześć!
Mam następującą sytuację

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?


(Jakub Danecki) #2

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.


#3

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?

Czy potrzebne są jakieś dodatkowe dane?


(Jakub Danecki) #4

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:

  1. 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
  2. Co pokazuje WIN jak wyświetlisz tablice routingu? (route -a chyba w Windows się to robi)
  3. 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).
  4. 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ć?)
  5. 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.


#5

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.

  1. 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.

  2. 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).

  3. 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ć.

  4. Analogicznie między stacją B a HQ.

  5. 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).

  6. 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).

  7. 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ź :slight_smile:


(Jakub Danecki) #6

Wchodzimy trochę w filozofię, ale mniej więcej takie mam uwagi:

  1. 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.
  2. 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.

Poza tym dobrze kombinujesz :slight_smile: