Chcę podłączyć kilka sieci LAN znajdujących się na odległych budynkach.
Witryna „centralna” ma komputer z systemem Linux i OpenVPN. Na każdej zdalnej stronie działa również OpenVPN.
- strona centralna ma sieć LAN o numerze 192.168.0.0/24
- kilka zdalnych stron jest również ponumerowanych 192.168.0.0/24
- Nie mogę / nie chcę / nie chcę / cokolwiek modyfikować numeracji LAN
- Nie mam kontroli nad większością zdalnych OpenVPN
Następnie muszę:
1. zdefiniować wirtualne sieci LAN
2. skonfigurować NAT 1: 1 dla każdej witryny
3. NAT 1: 1 należy skonfigurować na centralnym routerze
.
Tak więc każda witryna ma sieć LAN 10.10.x.0 / 24.
Gdy komputer chce dotrzeć, powiedzmy, 192.168.0.44 na stronie 12, wystarczy wysłać paquet na 10.10.12.44
Obsługa VPN nie stanowi dla mnie problemu. Obecnie łączę ponad 60 witryn. Ale nie znajduję prostego sposobu na zrobienie tego NAT 1: 1.
Oto przykład pakietu wysłanego z witryny centralnej do witryny zdalnej i jego pakietu odpowiedzi:
Zrobiłem kilka testów z iptables NETMAP, ale nie mogę sprawić, aby działało, ponieważ nie znajduję sposobu na modyfikację źródła + miejsca docelowego po decyzji o routingu.
Wolę unikać nowej --client-nat
funkcji OpenVPN.
Może muszę wymusić routing ip route
? A może dwukrotnie zapętlić w stos sieciowy veth
?
Uwaga: nie chcę używać maskarady. Tylko 1/1 NAT.
EDYCJA:
Nie jest to możliwe przy regularnej konfiguracji openVPN. Ponieważ pakiet ze zdalnej strony jest nierozróżnialny od pakietu z innej strony: oba mają podobne adresy źródłowe i docelowe, a oba pochodzą z tego samego interfejsu tun (lub tap). Więc nie jest możliwe, aby go pobrać.
Rozwiązanie 1: wykonaj translację NAT na zdalnych stronach. W moim przypadku niemożliwe. Muszę to zrobić tylko na stronie centralnej.
Rozwiązanie 2: skonfiguruj jedną sieć VPN dla każdej zdalnej witryny. Więc mam jeden tun dla każdego. Myślę, że to może być w porządku. Niezbyt wydajna pamięć, ale w porządku.
Rozwiązanie 3: skonfiguruj (niezaszyfrowany) tunel w sieci VPN dla każdej witryny. To da jeden interfejs dla każdego. Proste tunele nie są wieloplatformowe (ku memu knoledge). Na przykład GRE, ipip lub sit są w porządku dla Linuksa, ale na niektórych odległych stronach działa tylko jeden komputer z Windows, więc jest na nim zainstalowany openVPN. Tak niemożliwe jest ustawienie prostego tunelu. Inną opcją jest użycie bardziej skomplikowanego tunelu (który?), Ale narzut w systemie i na sysadminie może być większy niż w przypadku posiadania wielu sieci VPN
Rozwiązanie 4: skompiluj najnowszy openVPN, ponieważ zawiera on funkcję NAT 1: 1. Testuję w tym tygodniu.
Odpowiedzi:
Bardzo podstawowym rozwiązaniem jest:
1. użyj OpenVPN 2.3 lub więcej (obecnie najnowsza wersja to 2.3-alpha) dla serwerów + klientów
2. użyj opcji konfiguracji OpenVPN poniżej
3. nie używaj niczego innego (bez ipfilter, żadnych sztuczek)
Po stronie serwera musisz ręcznie dystrybuować adresy VPN (więc nie ma
server
opcji, musisz użyćifconfig
lubifconfig-push
):route
Ipush route
iclient-nat
linie są wymagane, jeśli chcesz komunikować się bezpośrednio między routerami (ping 10.99.99.1
z odległym miejscu przechadzkę VPN). W przeciwnym razie możesz je odrzucić..
.
Teraz musisz wybrać wirtualny adres sieciowy. Zachowałem to samo, co w przykładzie: 10.10.0.0/16 Zezwalasz
na routing w tym celu:
.
.
Musisz teraz poinstruować klienta, aby używał NAT 1: 1:
W pierwszym wierszu ustaw adres routera zdalnego. Uwaga na sterownik Windows wymagający specjalnych adresów.
Druga i ostatnia linia pozwalają odległemu routerowi komunikować się z jego interfejsu 10.99.99.x.
Trzecia i czwarta linia zawierają źródłowy i docelowy NAT 1: 1
Piąty wiersz mówi OpenVPN, co zrobić z odpowiednimi pakietami.
Ta metoda pozwala łączyć witryny z identycznymi (lub nie) adresami LAN, bez hostowania w tle.
źródło
Zrobiłem coś podobnego z prawdziwymi interfejsami, ale nie rozumiem, dlaczego to nie działa z interfejsami VPN.
Chodzi o to, że ponieważ masz tę samą podsieć dostępną w różnych interfejsach na tym routerze, komplikuje to routing. Zasadniczo, gdy pakiet dla 10.10.13.123 wchodzi do routera, jest on DNATed przed routingiem do 192.168.0.123, więc musisz być w stanie powiedzieć routingowi, że był przeznaczony dla 192.168.0.123 na interfejsie VPN13 .
Można to zrobić za pomocą znaków zapory i reguł routingu korzystających z tych znaków. SNAT i DNAT należy wykonać przy użyciu zapory sieciowej NETMAP. W przypadku SNAT jest to ten sam problem, w POSTROUTINGU straciłeś informacje, że pakiet pochodzi z tego lub innego interfejsu i wszystkie one mają adres źródłowy 192.168.0.x. Potrzebujesz więc znaku, aby przenosić te informacje - od PREZENTACJI do maglera, po PREZENTACJĘ nat. Możesz użyć tego samego znaku, ale wtedy oznaczałoby to, że te pakiety korzystałyby z tej alternatywnej tabeli routingu, więc musisz zduplikować globalną tabelę routingu.
Dla każdej sieci zrobiłbyś:
Powyżej używamy pierwszych 4 bitów znaku , aby umożliwić routing do 7 sieci w ten sposób.
źródło