z tych wszystkich kombinacji to są co najmniej 4
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)

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

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

moim zdaniem:

ad 1.
robisz maskaradę wszędzie gdzie się da, bo to jest wygodniejsze 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.

Cudy WR3000 sprawia/ł? problemy u jednego z użytkowników jako AP-client. Wątek tu: https://eko.one.pl/forum/viewtopic.php? … 17#p291817

Skoro na jednym radiu nie jest dobrze robić kilka trybów bo dzieli przepustowość, a karty WiFi na USB to lepiej sobie odpuścić jeżeli chemy wysoki bitrate to zostaje np. niezbyt ładne rozwiązanie ale w miejsce routera nr 2 postawić 2 routery.
Brzmi dziwnie i śmiesznie ale jeden mógłby robić tylko jako AP-Client i przerzucałby pakiety po kablu (1 Gbps) do "kolegi" który pracowałby tylko jako AP.
Czyli razem 4 szt. routerów.
Jak chcemy szybkość po WiFi przez stropy to niestety koszta w utrzymaniu powinny schodzić na drugi plan.
Jak to mówi pewien chłop: "nie sztuka kupić szybkiego konia, ale jeszcze trzeba mieć na paszę dla niego"

EDIT:
Serwer iperf3 jest podłączony po kablu do Routera 1 w którym radio robi tylko jako AP,
R6220 który wg topologii @samsona jest jako Router 2 pracujący tylko w trybie STA, to na kliencie podłączonym do tego routera można wycisnąć 260 / 380 lub ciut więcej (przynajmniej tyle się da).
Kolejność cyfr w zależności czy klient puści iperf3 bez -R czy z -R.
I to by było na tyle. A więc co było wiadome od początku, R6220 nie nadaje się do takich celów, żeby łyknąć duży bitrate i to jeszcze do NAS-a.
Trzeba szukać czegoś lepszego czyt. droższego.

tylko połowicznie to jest bez sensu.
Masz Internet na WAN 2 Gbps i dzięki portom 1 Gbps na LAN rozkładasz go po równo na 2 strumienie bez zaprzęgania QoS-a
Dla jednego hosta to trzeba kombinować żeby wyssać te 2 Gbps

jaka ciekawostka? Nie odkryłeś Ameryki. To normalne działanie firewalla.
Z LAN do WAN masz zawsze dostęp.
ale jak pakiet złapie się na regułę From: LAN To: WAN IP: 192.168.1.0/24  REJECT to go odrzuci nie analizując dalszych reguł.
jak złapie się na regułę From: LAN To: WAN IP: 192.168.1.1  ACCEPT to wejdziesz i firewall dalej nie analizuje reguł bo już go wpuścił

on wgrywa za każdym razem obraz sysupgrade....
Zawsze mi się wydawało, że przez tftp potrzeba inny

Cezary nie napisał po których świętach
6 stycznia jest kolejne święto.
7 stycznia Prawosławni obchodzą swoje święta.

Cezary,

1. W dzisiejszych czasach mało kto przyznaje się do tego co ma jeśli chodzi o taki soft, bo jak mówią/piszą różni ludzie, stanowi to zachętę/ułatwienie do prowadzenia ataku na taką bramę.
Chodzi o zasadę, a nie o to, czy zawsze jest to logiczne  rozumowanie czy nie.
Niektórzy boją się cokolwiek ujawniać chyba że chodzi o chwalenie się najnowszym "jabłuszkiem"

2. Statystyki powodują to, że ktoś analizuje procentowy udział  w rynku takiego typu oprogramowania i może z zazdrości wprowadzać utrudnienia.
Klient zamiast kupić model z najwyższej półki danego producenta, to kupuje model z półki "home" i wgrywa sobie takie Openwrt i nagle ma pół-profesjonalny sprzęt z VLAN-ami i na każdym porcie LAN osobną sieć
Producent traci na sprzedaży drogich sprzętów, ale mógłby mocno zyskać na tych tanich, jakby chciał.
A gdy wypuszcza np. Ver.3 na Broadcomie to leży takie g...o na półce w sklepie bo nikt tego nie chce z tej społeczności.

3. Gdy ktoś chce mieć dostęp do roota i otwarte oprogramowanie na routerze, to jest uważany za kombinatora i chachmęta i na pewno ma coś do ukrycia

Wyjątki w chwaleniu się Openwrt  to takie, gdy ktoś potrzebuje pomocy i musi powiedzieć co ma i co nie działa, lub...
nie ma kasy na drogi sprzęt i chce udowodnić bogatszemu koledze, że tamten jest frajerem bo przepłacił, a mógł mieć to samo za darmo

czy tak trudno poszukać tego hasła?
https://openwrt.org/docs/guide-user/network/routing/pbr

Być może potrzebujesz wpisać odpowiedni MAC adres na porcie WAN do R6220.
Niektórzy dostawcy tego pilnują. Sprawdź.

i dopiero teraz wiadomo, że chodziło o dostawcę tunelu VPN a nie dostawcę Internetu
Nikt tu nie ma szklanej kuli, żeby wiedzieć o co dokładnie Tobie chodziło.
@szwagier44 też pewnie pomyślał, że chodzi o dostawcę Internetu, bo opisał szybkość "punkt - punkt" a nie "klientVPN - serverVPN - klient VPN"

mogłeś napisać, że potrzebujesz do gier, czy streamingu jako wyjścia na świat, bo jeżeli chcesz łączyć różne swoje lokalizacje, to na takich dostawcach VPN-u co wymieniłeś, to może się nie udać. Piszę żebyś nie był zdziwiony.