Nic, się nie stanie. W 1043v.1 port 0 to ten oznaczony na niebiesko. Jeśli będzie w innym VLANie niż porty 1-4 to nie będzie fizycznego połączenia pomiędzy urządzeniami podłączonymi do żółtych gniazdek i do gniazdka niebieskiego. Separacja set robiona na poziomie ramek ethernetowych.

I to właśnie bardzo mnie zdziwiło.
W moim 1043v.3 wygląda to następująco

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0 1 2 3 4'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '5 6'

Ale przyznaję, że nie próbowałem przepinać portów 5 i 6 do vlanu 1. A teraz nie bardzo mogę to przetestować.

Hmm. Ja mam TL-WR1043N/ND i jedno mogę potwierdzić. Ma on 5 gniazdek RJ-45 na obudowie, ale w odróżnieniu od TL-WDR4300 ma dwa fizyczne interface (eth0 i eth1). Nie wiem czy to ma jakieś znaczenie, ale ja mam wersję 3.0.
Zupełnie inna sprawa to twoja technika pomiarowa. Ja pobierałem wgetem 1GB plik. Taki pomiar jest bliższy temu co na co dzień robimy w sieci.
Również nie zgadzam się, że to antyreklama OpenWRT. Zaletą systemów opartych na Linuksie jest przede wszystkim to, że nikt użytkownikowi nie wciska kitu i jasno piszemy:
- to działa,
- to nie działa i nie będzie działać,
- to nie działa, ale pracujemy nad tym.

Patrząc na schemat twojej sieci to nie widzę.
Ja miałem taki problem z tp-linkiem z oryginalnym firmware, który w mojej sieci robił tylko za AP i switch.
Był podpięty do reszty tylko po LAN i miał dostęp tylko do sieci 192.168.1.x. Resztę chciał przepychać przez nie podłączony WAN. Wymuszenie DNAT na routerze z DEST_IP = IP tp-linka rozwiązało problem.

Nie. Możesz spokojnie do 100 metrów "przekroczyć"

Cały czas dyskutujemy o WDR4300?
Przecież on ma tylko jeden fizyczny interface w postaci 5-portowego switcha. Jeśli maksymalny transfer do urządzenia bez routingu i NAT to 24MB/s to czego oczekiwać gdy musimy zaangażować procesor do dodatkowych czynności? Sam pytałeś ile da się wyciągnąć na czystym OpenWRT. Może jutro przekonfiguruję 4300 tak by pracował jako router bez NAT i sprawdzę przepustowość.

BTW: 24MB/s to 193Mbit/s

Panowie, może to da wam trochę do myślenia.
Czyste OpenWRT (taka minimalna konfiguracja) zainstalowane na WDR4300, do którego mam podpięte dwa debiany PC z apachem oraz laptop.

root@router:~# time wget http://192.168.24.1/1gb.test -O /dev/null
Connecting to 192.168.24.1 (192.168.24.1:80)
null                 100% |***********************************************************************************|  1024M  0:00:00 ETA
real    0m 42.44s
user    0m 1.27s
sys    0m 38.81s

oraz na lapku

sowa:~$ time wget http://192.168.24.1/1gb.test -O /dev/null
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 200 OK
Długość: 1073741824 (1,0G)
Zapis do: `/dev/null'
/dev/null                        100%[============================================================>]   1,00G  78,7MB/s   w  13s    

2017-01-26 21:38:20 (81,8 MB/s) - zapisano `/dev/null' [1073741824/1073741824]

real    0m12.608s
user    0m0.328s
sys    0m0.976s

A drugim przypadku tp-link robił tylko za switch.

Jeszcze raz rzuciłem okien na twój schemat i chyba wiem jak poprawić sytuację. Na VPSie musisz dodać regułkę dla firewalla

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

I oczywiście zezwolić na forwarding z tun+ na eth0 (to już @khain opisał).
Skoro to VPS to nie będziesz miał potrzeby forwardowania z innych interface'ów.

A tak BTW. Skoro masz komputer z debianem, to może niech on robi też za router? Dla swojej sieci wybrałem właśnie taki wariant. TP-Linki służą mi tylko jako switche i AP. A WRD4300 to nie ma nawet interface wan

Ale ja nie mam bladego pojęcia o gargoyle. I nie lubię pisać poradników w stylu "kliknij myszką ...".
Tak możesz skonfigurować klienta pod serwer, który opisałem w innym wątku.
Wystarczy zaznaczyć, skopiować i wkleić do putty (czy co tam używasz).

rm -f /etc/openvpn/*.conf
uci -q delete openvpn.client
uci set openvpn.client=openvpn
uci set openvpn.client.enabled='1'
uci set openvpn.client.client='1'
uci set openvpn.client.dev='tun0'
uci set openvpn.client.proto='udp'
uci set openvpn.client.nobind='1'
uci set openvpn.client.ca='/etc/openvpn/ca.crt'
uci set openvpn.client.cert='/etc/openvpn/domek.crt'
uci set openvpn.client.key='/etc/openvpn/domek.key'
uci set openvpn.client.dh='/etc/openvpn/dh.pem'
uci set openvpn.client.tls_auth='/etc/openvpn/ta.key 1'
uci set openvpn.client.cipher='AES-256-CBC'
uci set openvpn.client.verb='1'
uci set openvpn.client.persist_key='1'
uci set openvpn.client.persist_tun='1'
uci set openvpn.client.comp_lzo='yes'
uci set openvpn.client.remote='<twoj.serwer.vpn>''
uci set openvpn.client.remote_cert_tls='server'
uci set openvpn.client.ping='15'
uci set openvpn.client.ping_restart='60'
uci commit openvpn
/etc/init.d/openvpn restart

Czas poniżej 1 min.
Tylko nie zapomnij zamiast <twoj.serwer.vpn> podać adresu twojego serwera

Konfiguracja serwera, na moje oko, wygląda całkiem dobrze. Jedyne co mogę zasugerować to dodanie opcji

tls-auth /etc/openvpn/ta.key 0

To teraz dla równowagi konfiguracja klienta.

Hmm, aż taki ciemny to ja nie jestem
Oczywiście, że masq 1, ale tylko dla

option dest_ip '192.168.24.254'

To może ja ci wytłumaczę jak działa routing.
Jeśli jakiś komputer wysyła pakiet do innego komputera to musi ustalić czy ma z nim połączenie bezpośrednie, czy musi skorzystać z pośrednictwa routera. W tablicy routingu masz zapisane routery dla poszczególnych adresów docelowych. Wylicza się to na podstawie adresu sieci i maski. Połączenia bezpośrednie mają w tablicy routingu adres gatewaya 0.0.0.0. Adresy, które nie pasują do niczego są kierowane do routera domyślnego (default). Zwykle nie potrzebujemy więcej wpisów bo mamy tylko jedną sieć lokalną z jednym routerem. Twój przypadek jest trudniejszy. Masz dwa routery. Każdy z nich obsługuje sieć VPN. Dlatego musisz ustawić odpowiednie trasy routingu. Routery między sobą nie będą przekazywać ruchu po sieci LAN. Dlatego komputer (stacja robocza) musi wiedzieć, że komputer o IP 10.8.1.1 jest dostępny za pośrednictwem routera 192.168.1.251 i sama wyśle prośbę o routing do właściwego routera. Ta sama stacja musi wiedzieć, że komputer IP=10.8.2.1 jest dostępny via router 192.168.1.240. Podane wyżej opcje konfiguracyjne dla dnsmasq spowodują, że informacje o routerach i obsługiwanych przez nie sieciach zostaną wysłane do stacji roboczych podczas negocjowania z serwerem DHCP adresu IP stacji.

Ja też mam w swojej sieci takiego tp-linka. U mnie jest to TL-WDR4300. Robi on tylko za wifi AP i switch ethernetowy. Oryginalny firmware tp-linka nie umożliwia manipulowania siecią LAN, ale jest na to sposób. Wystarczy ustawić DNAT na routerach. W mojej sieci załatwia to poniższa linijka z konfiguracji firewalla:

# iptables -t nat -A POSTROUTING -o $LAN -d 192.168.1.254 -j MASQUERADE

gdzie 192.168.1.254 to statycznie przypisany adres IP mojego tp-linka. Niestety nie wiem jak to zapisać w stylu /etc/config/firewall bo moim głównodowodzącym jest debian.