1 Temat przez awkm80

  • awkm80
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2018-01-22
  • Posty: 15

Temat: Dostęp z WAN do LAN bez publicznego IP

Cześć. Mam w domu (i poza nim) taką oto sieć.
https://docs.google.com/presentation/d/ … sp=sharing
Jakiś czas temu byłem zmuszony zmienić dostawcę na PLAY net box 5G. Niestety nie posiadam teraz publicznego IP. Od paru lat korzystam z Nexcloud, który jest uruchomiony w domu na starym laptopie aktualnie na Ubuntu 20.04. Mając wcześniejszego dostawcę internetu przekierowałem na routrze 2 porty (80 i 443) i sprawa była prosta. Przechodząc na w/w dostawcę internetu sprawa skomplikowała się. Wymyśliłem, że wykupię na jakiś czas (póki nie zmienię dostawcy) serwer VPS z publicznym IP i postawię na nim serwer OpenVPN, a następnie zrobię tunel do domu. Serwerem VPS to Debian 11 z OVH. W domu jako router pracuje TP-Link Archer C7 z Openwrt "22.03.3" i zainstalowanym OpenVPN jako klient. Na potrzeby NextCloud mam wykupioną publiczną domenę, a SSL zapewniam sobie poprzez Lets encrypt. Z założenia dostęp do NextCloud jest publiczny (np po to abym mógł znajomym udostępniać jakieś zdjęcia itp.) a wiec na Serwerz VPS, a następnie na domowym routerze są zrobione odpowiednie przekierowania do NextCloud. Do serwera OpenVPN (na VPS) łączę się także z komórki aby docelowo mieć dostęp do całej sieci LAN i zawartych w niej różnych urządzeń. Serwer OpenVPN jest z konfigurowany w trybie TUN i certyfikaty.

Wykonałem pewne konfiguracje na VPS (iptables), a także na OpenWRT i generalnie dostęp publiczny do NextCloud działa ale mam kilka problemów:

1. Mam np problem z Fail2ban zainstalowanym na serwerze Ubuntu (Nextcloud). Robiąc testy z błędnym logowaniem do NextCloud dochodzi do blokowania adresu IP 10.8.88.1 czyli adresu IP serwera OpenVPN. Nie wiem jak zrobić i czy w ogóle da się  zrobić aby do serwera NextCloud przez tunel VPN docierały publiczne adresy IP, a nie natowane, bo inaczej Fail2Ban na Ubuntu nie ma sensu.

2, Gdy jestem w domu, tzn w sieci LAN i chcę zrzucić coś z telefonu na NextCloud dochodzi chyba do jakiegoś zapętlenia tzn. mam wrażenie, że dane idą do domowego routera OpenWRT ten wysyła je na publiczną domenę czyli do VPS, następnie dalej lecą z VPS poprzez VPN do domu i ponownie przez OpenWRT trafiają wreszcie do serwera NextCloud. Dochodzi do tego, że transfer domowy jest o wiele wolniejszy niż transfer z internetu do domu  smile

3. Trzeci problem to brak komunikacji np. z komórki do sieci domowej poprzez VPN. Tzn tunel działa, VPN łączy się pomyślnie ale pingi działają tylko do 10.8.88.1 lub 10.8.88.6 ale do 192.168.0.1 czyli LANowego adresu IP routera i całej domowej sieci już nie działają.

Póki co nie wklejam żadnej konfiguracji jak reguły z firewalli lub tablic routingu, bo nie wiem od czego zacząć. Jakbyście mogli podpowiedzieć co konkretnie przedstawić aby można było mnie nakierować w temacie będę wdzięczny.

2 Odpowiedź przez mar_w

  • mar_w
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2014-08-16
  • Posty: 2,124

Odp: Dostęp z WAN do LAN bez publicznego IP

moim zdaniem:

ad 1.
robisz maskaradę wszędzie gdzie się da, bo to jest wygodniejsze smile ale ma to woje konsekwencje.
Wszystkie pakiety z zewnątrz mają adres serwera OpenVPN.
Musisz wyłączyć maskaradę na interfejsach tunelu.
Musisz zrobić przekierowanie portów (dowolnych lub 80,443) z adresu 234.234.234.234 na adres 192.168.0.200 na porty 80,443
Serwer OpenVPN musi mieć/znać trasę do sieci LAN 192.168.0.0/24 i wiedzieć, że ona jest za bramą 10.8.88.6 żeby to wszystko pakować w tunel ale bez maskarady czyli NAT-u.
To już jest konfiguracja serwera OpenVPN na Debian 11
dodatkowo musisz zezwolić na forward pakietów na Routerze OpenWRT między interfejsem VPN a LAN i odwrotnie.

ad 2.
Hosty w sieci LAN muszą mieć ustawiony DNS na Router Openwrt i wtedy...
sprawdź to na Routerze Openwrt ustawiając pod siebie odpowiednie regułki:   https://eko.one.pl/?p=openwrt-dns#zamianaadreswdomen

ad 3.
po zezwoleniu na forward pakietów na Routerze OpenWRT między interfejsem VPN a LAN i odwrotnie powinno działać.
Pod jednym warunkiem. Hosty w sieci LAN muszą mieć ustawioną bramę na Router Openwrt który jest klientem OpenVPN.
Jak pakiet z zewnątrz z adresem klienta tunelu np. 10.8.88.10 przejdzie przez router to on w tablicy połączeń zapisze sobie to zdarzenie i pakiety powrotne mając zezwolenie na forward powinny wrócić przez tunel do odbiorcy.

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

3 Odpowiedź przez Kebap

  • Kebap
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2019-12-31
  • Posty: 173

Odp: Dostęp z WAN do LAN bez publicznego IP

https://openwrt.org/docs/techref/unetd
podobno na tym się da bez publicznego ip, postawić wireguarda, ale ja nie potrafię tego ustawić poprawnie

4 Odpowiedź przez Cezary

  • Skąd: Warszawa
  • Zarejestrowany: 2006-02-25
  • Posty: 115,919

Odp: Dostęp z WAN do LAN bez publicznego IP

To działa w identyczny sposób jak próbowałeś zrobić, tylko wykorzystuje chmurę do szukania hostów. Bez udziału swojego serwera możesz to także na zerotier zrobić: https://eko.one.pl/?p=openwrt-zerotier

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

Cezary's Strona

5 Odpowiedź przez Kebap

  • Kebap
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2019-12-31
  • Posty: 173

Odp: Dostęp z WAN do LAN bez publicznego IP

No ale jednak nie byłem w stanie tego poprawnie ustawić, próbowałem wszystko tak jak na wiki, z DHT i kilkoma serwerami, nie tylko googlowymi, jedyne co mi się udało osiągnąć, to połączenie jeśli oba routery były w tej samej sieci lol, jak tylko je podłączałem do lte orange z osobnych modemów to było 0 komunikacji, o zerotier wiem, ale jaka przyszłość z tym będzie to nie wiadomo, bo dla darmowej opcji ciągle coraz większe ograniczenia dowalają, no i na wg mi działa dobrze, to do czego tego potrzebuję, po prostu unetd to by była fajna opcja, jeśli stracę publiczne ip (dawne upc) i bez zastanawiania się czy zerotier nie dowali limitu użytkowników na 10 albo coś...

6 Odpowiedź przez Cezary

  • Skąd: Warszawa
  • Zarejestrowany: 2006-02-25
  • Posty: 115,919

Odp: Dostęp z WAN do LAN bez publicznego IP

No ja mam następny poradnik który napisałem ale tym razem z wireguardem smile https://eko.one.pl/forum/viewtopic.php? … 16#p291616

Do koloru, do wyboru. Masz już vpsa z debianem to dawaj konfigi i jeżeli coś nie działa to spróbujemy to naprawić.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

Cezary's Strona

7 Odpowiedź przez awkm80

  • awkm80
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2018-01-22
  • Posty: 15

Odp: Dostęp z WAN do LAN bez publicznego IP

Dziękuję za propozycje dotyczące WG i zerotier. Póki co chciałbym zostać przy obecnym sofcie smile Poniżej pokazuję szczegóły dotyczące konfiguracji, na pewno jest wiele do poprawy smile Jeśli chodzi o konfigurację UCI w Openwrt kompletnie nie czuję jej i zdaję się na Waszą pomoc smile

Legenda dla przypomnienia:
Debian VPS (OpenVPN Server) - 10.8.88.1
OpenWRT (OpenVPN Client) - 10.8.88.6
NC (NextCloud server http/s w LAN ) - 192.168.0.200
Schemat sieci: https://docs.google.com/presentation/d/ … sp=sharing
Niektóre dane zostały nieco spseudonimizowane wink

Reguły Firewall - Debian VPS

iptables -A FORWARD -i ens3 -o tun0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i ens3 -o tun0 -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i ens3 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 80 -j DNAT --to-destination 10.8.108.6
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to-destination 10.8.108.6
iptables -t nat -A POSTROUTING -o tun0 -p tcp --dport 80 -d 10.8.88.6 -j SNAT --to-source 10.8.88.1
iptables -t nat -A POSTROUTING -o tun0 -p tcp --dport 443 -d 10.8.88.6 -j SNAT --to-source 10.8.88.1

Routing  - Debian VPS

root@vps-xxxx ~ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         135.219.70.1    0.0.0.0         UG    0      0        0 ens3
10.8.88.0       10.8.88.2       255.255.255.0   UG    0      0        0 tun0
10.8.88.2       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
135.219.70.1    0.0.0.0         255.255.255.255 UH    0      0        0 ens3
root@vps-xxxx ~ #

Konfiguracja OpenWrt:

Routing  - OpenWrt

root@OpenWrt:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.156.62.68    0.0.0.0         UG    0      0        0 eth0.2
10.8.88.0       10.8.88.5       255.255.255.0   UG    0      0        0 tun0
10.8.88.5       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.156.62.64    0.0.0.0         255.255.255.248 U     0      0        0 eth0.2
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~#

Network - OpenWRT

root@OpenWrt:~# uci show network
network.loopback=interface
network.loopback.device='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.globals.ula_prefix='fd72:b3d4:764e::/48'
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].type='bridge'
network.@device[0].ports='eth0.1'
network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ip6assign='60'
network.lan.ipaddr='192.168.0.1/24'
network.@device[1]=device
network.@device[1].name='eth0.2'
network.@device[1].macaddr='1c:3b:f3:50:29:c4'
network.wan=interface
network.wan.device='eth0.2'
network.wan.proto='dhcp'
network.wan6=interface
network.wan6.device='eth0.2'
network.wan6.proto='dhcpv6'
network.@switch[0]=switch
network.@switch[0].name='switch0'
network.@switch[0].reset='1'
network.@switch[0].enable_vlan='1'
network.@switch_vlan[0]=switch_vlan
network.@switch_vlan[0].device='switch0'
network.@switch_vlan[0].vlan='1'
network.@switch_vlan[0].ports='2 3 4 5 0t'
network.@switch_vlan[1]=switch_vlan
network.@switch_vlan[1].device='switch0'
network.@switch_vlan[1].vlan='2'
network.@switch_vlan[1].ports='1 0t'
network.ovpn=interface
network.ovpn.proto='none'
network.ovpn.device='tun0'
network.@device[2]=device
network.@device[2].name='eth0'
network.@device[3]=device
network.@device[3].name='tun0'
network.@device[3].ipv6='0'
root@OpenWrt:~#

Firewall - OpenWRT

oot@OpenWrt:~# uci show firewall
firewall.@defaults[0]=defaults
firewall.@defaults[0].input='ACCEPT'
firewall.@defaults[0].output='ACCEPT'
firewall.@defaults[0].forward='REJECT'
firewall.@defaults[0].synflood_protect='1'
firewall.@zone[0]=zone
firewall.@zone[0].name='lan'
firewall.@zone[0].input='ACCEPT'
firewall.@zone[0].output='ACCEPT'
firewall.@zone[0].forward='ACCEPT'
firewall.@zone[0].network='lan'
firewall.@zone[1]=zone
firewall.@zone[1].name='wan'
firewall.@zone[1].network='wan' 'wan6'
firewall.@zone[1].input='REJECT'
firewall.@zone[1].output='ACCEPT'
firewall.@zone[1].forward='REJECT'
firewall.@zone[1].masq='1'
firewall.@zone[1].mtu_fix='1'
firewall.@forwarding[0]=forwarding
firewall.@forwarding[0].src='lan'
firewall.@forwarding[0].dest='wan'
firewall.@rule[0]=rule
firewall.@rule[0].name='Allow-DHCP-Renew'
firewall.@rule[0].src='wan'
firewall.@rule[0].proto='udp'
firewall.@rule[0].dest_port='68'
firewall.@rule[0].target='ACCEPT'
firewall.@rule[0].family='ipv4'
firewall.@rule[1]=rule
firewall.@rule[1].name='Allow-Ping'
firewall.@rule[1].src='wan'
firewall.@rule[1].proto='icmp'
firewall.@rule[1].icmp_type='echo-request'
firewall.@rule[1].family='ipv4'
firewall.@rule[1].target='ACCEPT'
firewall.@rule[2]=rule
firewall.@rule[2].name='Allow-IGMP'
firewall.@rule[2].src='wan'
firewall.@rule[2].proto='igmp'
firewall.@rule[2].family='ipv4'
firewall.@rule[2].target='ACCEPT'
firewall.@rule[3]=rule
firewall.@rule[3].name='Allow-DHCPv6'
firewall.@rule[3].src='wan'
firewall.@rule[3].proto='udp'
firewall.@rule[3].dest_port='546'
firewall.@rule[3].family='ipv6'
firewall.@rule[3].target='ACCEPT'
firewall.@rule[4]=rule
firewall.@rule[4].name='Allow-MLD'
firewall.@rule[4].src='wan'
firewall.@rule[4].proto='icmp'
firewall.@rule[4].src_ip='fe80::/10'
firewall.@rule[4].icmp_type='130/0' '131/0' '132/0' '143/0'
firewall.@rule[4].family='ipv6'
firewall.@rule[4].target='ACCEPT'
firewall.@rule[5]=rule
firewall.@rule[5].name='Allow-ICMPv6-Input'
firewall.@rule[5].src='wan'
firewall.@rule[5].proto='icmp'
firewall.@rule[5].icmp_type='echo-request' 'echo-reply' 'destination-unreachable' 'packet-too-big' 'time-exceeded' 'bad-header' 'unknown-header-type' 'router-solicitation' 'neighbour-solicitation' 'router-advertisement' 'neighbour-advertisement'
firewall.@rule[5].limit='1000/sec'
firewall.@rule[5].family='ipv6'
firewall.@rule[5].target='ACCEPT'
firewall.@rule[6]=rule
firewall.@rule[6].name='Allow-ICMPv6-Forward'
firewall.@rule[6].src='wan'
firewall.@rule[6].dest='*'
firewall.@rule[6].proto='icmp'
firewall.@rule[6].icmp_type='echo-request' 'echo-reply' 'destination-unreachable' 'packet-too-big' 'time-exceeded' 'bad-header' 'unknown-header-type'
firewall.@rule[6].limit='1000/sec'
firewall.@rule[6].family='ipv6'
firewall.@rule[6].target='ACCEPT'
firewall.@rule[7]=rule
firewall.@rule[7].name='Allow-IPSec-ESP'
firewall.@rule[7].src='wan'
firewall.@rule[7].dest='lan'
firewall.@rule[7].proto='esp'
firewall.@rule[7].target='ACCEPT'
firewall.@rule[8]=rule
firewall.@rule[8].name='Allow-ISAKMP'
firewall.@rule[8].src='wan'
firewall.@rule[8].dest='lan'
firewall.@rule[8].dest_port='500'
firewall.@rule[8].proto='udp'
firewall.@rule[8].target='ACCEPT'
firewall.@redirect[0]=redirect
firewall.@redirect[0].dest='lan'
firewall.@redirect[0].target='DNAT'
firewall.@redirect[0].name='NC'
firewall.@redirect[0].proto='tcp'
firewall.@redirect[0].src_dport='443'
firewall.@redirect[0].dest_ip='192.168.0.200'
firewall.@redirect[0].dest_port='443'
firewall.@redirect[0].src='ovpn_fw'
firewall.@redirect[1]=redirect
firewall.@redirect[1].dest='lan'
firewall.@redirect[1].target='DNAT'
firewall.@redirect[1].name='NC'
firewall.@redirect[1].proto='tcp'
firewall.@redirect[1].src_dport='80'
firewall.@redirect[1].dest_ip='192.168.0.200'
firewall.@redirect[1].dest_port='80'
firewall.@redirect[1].src='ovpn_fw'
firewall.@zone[2]=zone
firewall.@zone[2].name='ovpn_fw'
firewall.@zone[2].output='ACCEPT'
firewall.@zone[2].forward='REJECT'
firewall.@zone[2].mtu_fix='1'
firewall.@zone[2].network='ovpn'
firewall.@zone[2].masq='1'
firewall.@zone[2].input='ACCEPT'
firewall.@rule[9]=rule
firewall.@rule[9].name='vpn to lan'
firewall.@rule[9].src='ovpn_fw'
firewall.@rule[9].dest='lan'
firewall.@rule[9].target='ACCEPT'
firewall.@rule[9].proto='all'
firewall.@rule[10]=rule
firewall.@rule[10].src='lan'
firewall.@rule[10].dest='ovpn_fw'
firewall.@rule[10].target='ACCEPT'
firewall.@rule[10].name='lan to vpn'
firewall.@rule[10].proto='all'
root@OpenWrt:~#

8 Odpowiedź przez mar_w (edytowany przez mar_w 2024-01-24 21:22:52)

  • mar_w
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2014-08-16
  • Posty: 2,124

Odp: Dostęp z WAN do LAN bez publicznego IP

1.
Na Debianie nadal robisz zamianę publicznych adresów źródłowych, a chcesz żeby Fail2ban blokował adresy publiczne.
Jak ma to zrobić, skoro nigdy nie zobaczy adresu publicznego, bo robisz Source NAT (czyli odmianę maskarady) ?
ja bym zrobił tak:
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.200
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to-destination 192.168.0.200

pod warunkiem że serwer OpenVPN będzie wiedział że sieć 192.168.0.0/24 jest za klientem 10.8.88.6 (router Openwrt) i tam wyśle pakiety
a router jak odbierze taki pakiet to tylko przerzuci go do interfejsu br-lan sprawdzając tylko pozwolenie na forward.

2.
Debian nie widzi sieci 192.168.0.0/24za klientem 10.8.88.6.
Można wszystko pchać na adres 10.8.88.6 i router niech mieli firewallem, żeby odpowiednio przekierowywać pakiety na adres LAN-owy, a można jak pisałem, zrobić redirect na VPS-ie na adres LAN-owy który jest za klientem VPN i  pakiety będą tylko przelatywać przez tablicę routingu a firewall sprawdzi tylko pozwolenie na "forward"

3.
ja u Siebie wolę jak forward jest robiony tradycyjnie:
firewall.@forwarding[1]=forwarding
firewall.@forwarding[1].src='lan'
firewall.@forwarding[1].dest='vpn'

niż przez rule[12]......
bo tych reguł potem nie chce mi się analizować, bo może coś nie być dopisane, a forwarding widzę z kilometra i mniejsze ryzyko pomyłki smile

EDIT:
1a)
albo zostaw jak jest na VPS (na metodę z tym podwójnym przekierowaniem) ale bez SNAT
iptables -A FORWARD -i ens3 -o tun0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i ens3 -o tun0 -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i ens3 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 80 -j DNAT --to-destination 10.8.108.6 (ja to skopiowałem a tutaj powinno być 10.8.88.6)
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to-destination 10.8.108.6  (ja to skopiowałem a tutaj powinno być 10.8.88.6)

2a)
Na Openwrt usuń maskaradę w zonie ovpn_fw
zostaw przekierowania jak są czyli redirect[0] oraz redirect[1] mają być

to wcześniej to jakby VPS był wyjściem na świat dla routera Openwrt,  a przecież Openwrt ma swoje wyjście.

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

9 Odpowiedź przez awkm80

  • awkm80
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2018-01-22
  • Posty: 15

Odp: Dostęp z WAN do LAN bez publicznego IP

Dzięki, odznaczyłem masqurade na OpenWRT na tym zone "ovpn_fw",a  także zahaszowałem chwilowo linie z SNAT. Cześć Firewalla na VPS odpowiedzialna za przekierowanie  aktualnie wygląda tak: 

iptables -A FORWARD -i ens3 -o tun0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i ens3 -o tun0 -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i ens3 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 80 -j DNAT --to-destination 10.8.88.6
iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to-destination 10.8.88.6

#iptables -t nat -A POSTROUTING -o tun0 -p tcp --dport 80 -d 10.8.88.6 -j SNAT --to-source 10.8.88.1
#iptables -t nat -A POSTROUTING -o tun0 -p tcp --dport 443 -d 10.8.88.6 -j SNAT --to-source 10.8.88.1

Połączenie do NextCloud przestało działać ze świata. Analizuje logi, tcpdump itp.
Konfiguracja na OpenWRT jest teraz raczej dobra (mimo wyłączania maskowania - to co mówiłeś) bo, np:

root@vps-xxxx ~ # curl -v telnet://10.8.88.6:443
*   Trying 10.8.88.6:443...
* Connected to 10.8.88.6 (10.8.88.6) port 443 (#0)
^C
root@vps-xxxx ~ #

Strona serwera NC otwiera się na VPS, tzn:

root@vps-xxxx ~ # lynx 10.8.88.6

powoduje otworzenie się strony Nextcloud na serwerze VPN, natomiast ze świata nie więc jeszcze jest coś nie tak z regułą na firewallu w VPS.

10 Odpowiedź przez mar_w (edytowany przez mar_w 2024-01-24 23:16:35)

  • mar_w
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2014-08-16
  • Posty: 2,124

Odp: Dostęp z WAN do LAN bez publicznego IP

Sorry że na początku wprowadziłem Ciebie w błąd. Myślałem o wiośnie smile

Przeanalizujmy....
Jeżeli VPS poprawnie przerzucił zapytanie z Internetu na adres klienta VPN ...88.6, a router na którym jest ten klient VPN poprawnie przerzucił do NC, to NC musiał zobaczyć adres źródłowy z Internetu.
NC jako odpowiedź musi ją odesłać do swojej bramy, czyli do routera Openwrt, a ten powinien sprawdzić, że zapytanie nr 1 przyszło na jego adres VPN i tym samym interfejsem powinien odesłać odpowiedź.
Skoro Openwrt nie robi maskarady na wyjściu Openvpn to odsyła do VPS-a pakiet z adresem źródłowym z sieci LAN.
VPS oczekiwał odpowiedzi od adresu  ...88.6 (bo na taki adres przerzucił pakiet) a dostał odpowiedź od adresu192.168.0.200 i nie wie co z tym zrobić.

Włącz tą maskaradę na Openwrt smile i przeładuj firewalla. VPS-a nie ruszaj na ten moment.

A jak ruszy to zapytanie ze świata z dowolnego adresu przez publiczny adres VPS to trzeba pomyśleć czy wewnątrz tunelu chcesz się odwoływać po adresie 10.8.88.6:443 żeby zobaczyć NC czy jednak po LAN-owym ...0.200
Jak to drugie to będziesz musiał wysyłać wszystkim klientom VPN trasę do sieci .0.0/24 przez ...88.6

Dodatek:
Jeżeli po włączeniu maskarady na Openwrt nadal zwykły klient z Internetu, nie może otworzyć strony NC poprzez publiczny adres VPS-a to musisz dodać regułę na VPS-ie której być może nie było bo nikt się nie spodziewał, że będą takie przekierowania z innych dalekich hostów:

iptables -t nat -A POSTROUTING -o ens3  -j MASQUERADE

to Ci da tyle, że zwykły klient, który się pytał z Internetu o adres i port PublicIP_VPS:443 dostanie po przekierowaniach odpowiedź z NC, ale zamaskowaną adresem i portem PublicIP_VPS:443 czyli to o co pytał.
I trzeba przeładować firewalla na VPS-ie
Chodzi o to że domyślnie ustawiony VPS ma jeden adres którym wychodzi od siebie i nie musi mieć ustawionej maskarady bo po co skoro wychodzi od siebie samego. Ale gdy nagle dojdą mu interfejsy VPN czy inne to musi robić maskowanie tamtych wewnętrznych adresów.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
nagłówek pakietu musi być zmieniany w taki sposób (s-source , d-destination) :
(s: Internet d: VPS:443) ---> (s: Internet d: ...88.6:443) ---> (s: Internet  d: ..0.200:443)
odpowiedź
(s: 0.200:443 d: Internet) ---> (s:...88.6:443 d: Internet) ---> (s: VPS:443 d: Internet)
nie ma innej możliwości skoro są 2 redirect-y w głąb sieci to muszą być 2 maskarady, żeby się wydostać z tych głębi:
1. na Openwrt na interfejsie VPN i
2. na VPS na interfejsie z publicznym IP.

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

11 Odpowiedź przez ad2014

  • ad2014
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2014-07-04
  • Posty: 1,137

Odp: Dostęp z WAN do LAN bez publicznego IP

ad.2 -  pytanie  jak w domu zrzucasz zdjecia - przez apk  ? jezeli tak jaki adres tam jest do NC wprowadzony  , czy wchodzisz przez przegladrke ? jakim adresem

12 Odpowiedź przez awkm80

  • awkm80
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2018-01-22
  • Posty: 15

Odp: Dostęp z WAN do LAN bez publicznego IP

@mar_w
Po podmianie reguł

iptables -t nat -A POSTROUTING -o tun0 -p tcp --dport 80 -d 10.8.88.6 -j SNAT --to-source 10.8.88.1
iptables -t nat -A POSTROUTING -o tun0 -p tcp --dport 443 -d 10.8.88.6 -j SNAT --to-source 10.8.88.1

na

iptables -t nat -A POSTROUTING -o ens3  -j MASQUERADE

Na serwerze z NC pojawia się publiczny adres i niestety nie ma połączenia na 80 i 443. Po wstawieniu reguł z SNAT połączenie ponownie działa tyle, że nie dochodzi pub ip. Trudno się mówi. Jeśli nie da się inaczej musi zostać jak jest.

@ad2014
Ogólnie zrzucam zdjęcia tylko ze swojej komórki.  Mam w niej zainstalowanego klienta NC i on sam po pojawieniu się nowego zdjęcia w galerii od razu przesyła je na serwer NC. W aplikacji mam podany adres publiczny czyli np. https://nextcloud.mojadomena.pl tyle, że mimo, iż jestem w sieci LAN to prędkość jest jaka jest ze względu, że transfer idzie na publiczny adres IP. Kombinowałem aby w routerze wstawić na sztywno w DNS wpis nextcloud.mojadomena.pl - 192.168.0.200 ale wtedy Client VPN w OpenWRT tracił połączenie do Serwera VPN, bo szukał go pod IP 192.168.0.200. Z tym lokalnym przesyłanie muszę jeszcze pakombinować.

13 Odpowiedź przez mar_w

  • mar_w
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2014-08-16
  • Posty: 2,124

Odp: Dostęp z WAN do LAN bez publicznego IP

Do NC dochodzi publiczny adres z telefonu i co dalej?
NC odpowiada?
Czy odsyła odpowiedź do routera Openwrt ?

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

14 Odpowiedź przez awkm80 (edytowany przez awkm80 2024-01-25 17:57:57)

  • awkm80
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2018-01-22
  • Posty: 15

Odp: Dostęp z WAN do LAN bez publicznego IP

Jeśli chodzi o OpenWrt i Serwer NC to wygląda, że tam wszystko przechodzi. Tak jakby problem był na serwerze VPS, a dokładnie miedzy publicznym interfejsem ens3, a VPNowym tun0. Poniżej testy śledzenia pakietów na ens3. Przy włączonym SNAT łączę się do 443. Zrobiłem nawet taki test, że wyłączyłem port forwarding w OpenWRT aby zobaczyć czy ze świata mogę dostać się na router w domu przez VPS i tunel. Objawy są te same. Gdy na firewallu ustawię MASQUERADE dostępu do openwrt na port 80 nie ma. Przełączając na SNAT dostaję się ze świata na OpenWrt na port 80.

Poniżej testy śledzenia pakietów na ens3 na VPS.

test telnet na port 443 z komórki :
VPS - MASQUERADE=off SNAT=on,
OpenWrt - Masq=off
94.254.236.12 - adres publiczny mojej kom

root@vps-xxxxxxxx ~ # tcpdump -i ens3 dst 94.254.236.12 or src 94.254.236.12
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:48:49.959254 IP user-94-254-236-12.play-internet.pl.24497 > vps-xxxxxxxx.vps.ovh.net.https: Flags [S], seq 1518689419, win 65535, options [mss 1408,sackOK,TS val 4036882909 ecr 0,nop,wscale 9], length 0
15:48:50.015433 IP vps-xxxxxxxx.vps.ovh.net.https > user-94-254-236-12.play-internet.pl.24497: Flags [S.], seq 3549081893, ack 1518689420, win 65160, options [mss 1289,sackOK,TS val 3282925844 ecr 4036882909,nop,wscale 7], length 0
15:48:50.037273 IP user-94-254-236-12.play-internet.pl.24497 > vps-xxxxxxxx.vps.ovh.net.https: Flags [.], ack 1, win 172, options [nop,nop,TS val 4036882998 ecr 3282925844], length 0
15:49:08.759223 IP user-94-254-236-12.play-internet.pl.24497 > vps-xxxxxxxx.vps.ovh.net.https: Flags [P.], seq 1:6, ack 1, win 172, options [nop,nop,TS val 4036901713 ecr 3282925844], length 5
15:49:09.014350 IP vps-xxxxxxxx.vps.ovh.net.https > user-94-254-236-12.play-internet.pl.24497: Flags [.], ack 6, win 510, options [nop,nop,TS val 3282944839 ecr 4036901713], length 0
15:49:09.014457 IP vps-xxxxxxxx.vps.ovh.net.https > user-94-254-236-12.play-internet.pl.24497: Flags [F.], seq 1, ack 6, win 510, options [nop,nop,TS val 3282944839 ecr 4036901713], length 0
15:49:09.049177 IP user-94-254-236-12.play-internet.pl.24497 > vps-xxxxxxxx.vps.ovh.net.https: Flags [F.], seq 6, ack 2, win 172, options [nop,nop,TS val 4036902010 ecr 3282944839], length 0
15:49:09.066322 IP vps-xxxxxxxx.vps.ovh.net.https > user-94-254-236-12.play-internet.pl.24497: Flags [.], ack 7, win 510, options [nop,nop,TS val 3282944896 ecr 4036902010], length 0

   
test telnet na port 443 z komórki :
VPS - MASQUERADE=on SNAT=off,
OpenWrt - nadal Masq=off
94.254.236.12 - adres publiczny mojej kom

root@vps-xxxxxxxx ~ # tcpdump -i ens3 dst 94.254.236.12 or src 94.254.236.12
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:57:56.993234 IP user-94-254-236-12.play-internet.pl.24498 > vps-xxxxxxxx.vps.ovh.net.https: Flags [S], seq 2574686285, win 65535, options [mss 1408,sackOK,TS val 4037429858 ecr 0,nop,wscale 9], length 0
15:57:57.949123 IP user-94-254-236-12.play-internet.pl.24498 > vps-xxxxxxxx.vps.ovh.net.https: Flags [S], seq 2574686285, win 65535, options [mss 1408,sackOK,TS val 4037430889 ecr 0,nop,wscale 9], length 0
15:57:59.949103 IP user-94-254-236-12.play-internet.pl.24498 > vps-xxxxxxxx.vps.ovh.net.https: Flags [S], seq 2574686285, win 65535, options [mss 1408,sackOK,TS val 4037432889 ecr 0,nop,wscale 9], length 0
15:58:03.940161 IP user-94-254-236-12.play-internet.pl.24498 > vps-xxxxxxxx.vps.ovh.net.https: Flags [S], seq 2574686285, win 65535, options [mss 1408,sackOK,TS val 4037436889 ecr 0,nop,wscale 9], length 0
15:58:12.260061 IP user-94-254-236-12.play-internet.pl.24498 > vps-xxxxxxxx.vps.ovh.net.https: Flags [S], seq 2574686285, win 65535, options [mss 1408,sackOK,TS val 4037445209 ecr 0,nop,wscale 9], length 0
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel
root@vps-xxxxxxxx ~ #

Edit
Ruszyło na MASQUERADE
Zmieniłem:
iptables -t nat -A POSTROUTING -o ens3  -j MASQUERADE
na:
iptables -t nat -A POSTROUTING -o tun0  -j MASQUERADE

do serwera NC dalej docierają pakiety z 10.8.88.1, a nie z public IP.

15 Odpowiedź przez mar_w

  • mar_w
  • Użytkownik
  • Nieaktywny
  • Zarejestrowany: 2014-08-16
  • Posty: 2,124

Odp: Dostęp z WAN do LAN bez publicznego IP

z tych wszystkich kombinacji to są co najmniej 4 wink
VPS - MASQUERADE=on SNAT=off,
OpenWrt -  Masq=on

VPS - MASQUERADE=on SNAT=off,
OpenWrt -  Masq=off

VPS - MASQUERADE=off SNAT=on,
OpenWrt -  Masq=off

VPS - MASQUERADE=off SNAT=on,
OpenWrt -  Masq=on

ale zostawmy to.
tcpdump czasem dobrze puścić z przełącznikiem -n i -t bo trochę lepiej widać, gdy filtrujemy tylko pytanie i odpowiedź na ten sam adres.

Skoro router Openwrt ma swój WAN i odpowiedzi na światowe adresy docelowe wysyła tylko WAN-em to jedna z metod żeby odpowiedzi wysyłał z powrotem przez tunel jest zainstalowanie mwan3.
Na początek musisz powrócić/zrobić taką konfigurację, żeby NC (192.168.0.200) dostawał zapytania od publicznych adresów, które wchodzą przez VPS-a do NC (usuń SNAT na VPS-ie). Ścieżka pakietów musi być taka:
klient ---> VPS:443 ---> 10.8.88.6:443 ---> 192.168.0.200:443 (na nim musi się pojawić pakiet z adresem źródłowym z Internetu np. 94.254.236.12)

potem musisz dopisać trasę domyślną przez końcówkę tunelu która jest na VPS np 

ip r a default via 10.8.88.1 dev tun0 metric 10  #jak masz inny niż tun0 to dostosuj

następnie trzeba skonfigurować mwan3 poprzez korekty lub dopisanie czegoś.
Przykład pliku /etc/config/mwan3 który musisz zrobić pod siebie:

...
config interface 'vpn'
    option enabled '1'
    list track_ip '10.8.88.1'
    option family 'ipv4'
    option reliability '1'
...
config member 'wanb_m1_w2'
    option interface 'vpn'
    option metric '1'
    option weight '2'
....
config rule 'vps443'
    option dest_ip '0.0.0.0/0'
    option use_policy 'wanb_only'
    option src_ip '192.168.0.200'
    option src_port '443'
    option proto 'tcp'
    option family 'ipv4'

config rule 'vps80'
    option dest_ip '0.0.0.0/0'
    option use_policy 'wanb_only'
    option src_ip '192.168.0.200'
    option src_port '80'
    option proto 'tcp'
    option family 'ipv4'

config rule 'default_rule_v4'
    option dest_ip '0.0.0.0/0'
    option use_policy 'balanced'
    option family 'ipv4'
....

reguły vps443 i vps80 muszą być przed domyślną regułą.
Zapytania do NC z adresów LAN-owych nie podlegają pod polityki mwan3.
Zapytania do NC z adresów VPN-owych również nie podlegają pod polityki mwan3.
A jak zapytanie do NC przyjdzie ze światowego adresu, to może to zrobić tylko jedyną drogą przez VPS-a oraz tunel i  wtedy odpowiedzi od NC do Internetu załapią się pod reguły mwan3 o polityce "wanb_only" (jako pseudo-WAN)

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *