Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → Wireguard serwer na VPS - ruch przez Klienta z Polskim IP
Zaloguj się lub zarejestruj by napisać odpowiedź
Hej, czy możliwe jest taki scenariusz, mam serwer wireguard na VPS w Holandi, ale chce aby klienci podłączenie do serwera nie korzystali z IP Holanderskiego, tylko klienta w Polsce z polskim Ip. Nie mam polskiego prywatnego IP, więc kombinuje czy taki scenariusz jest możliwy?
Wychodzisz przez jednego z klientów. Normalny scenariusz, np. https://forum.openwrt.org/t/wireguard-o … ver/163542
Łatwo wygląda, ale będą problemy.
Teoretycznie połączyłem się z routerem , używając innego poradnika. Moge wejść na stronę routera po włączeniu tunelu, ale nic więcej, nie mam internetu.
Czyli masz skopany routeing/firewall/pbr.
a nie lepiej zerotier lub tailscale? jesli masz vps , to postaw na nim headscale i w zasadzie nie bedziesz mial limitow. tak samo mozesz postawc swoj serwer zerotier. bedziesz mial wtedy direct polaczenie wychodzac z polskim IP. troche zabawy w konfiguracje tego , ale potem czysta satysfakcja.
Czyli masz skopany routeing/firewall/pbr.
tak wyglada moja tablica routingu
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 phy0-sta0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
37.23.IP.VPS 192.168.2.1 255.255.255.255 UGH 0 0 0 phy0-sta0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 phy0-sta0
192.168.7.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
dodam ze ruter jest połączony nie kablem do portu WAN ale przez WWAN, ale chyba to nie ma znaczenia co jest w tej samej strefie WAN ( czerwonej) ?
Firewall - masakrada i MSS włączone
config defaults
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
list network 'wwan'config forwarding
option src 'lan'
option dest 'wan'config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'config zone
option name 'vpn'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option masq '1'
option mtu_fix '1'
list network 'wg0'config forwarding
option src 'vpn'
option dest 'wan'
Tak to wyglada konfig na VPS
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey =uE98HIahjJYU1ez1xxxxxxxxxxxxxxxxxxPostUp = ip rule add to 10.8.0.0/24 priority 10 table main
PostDown = ip rule del to 10.8.0.0/24 priority 10 table mainPostUp = ip rule add from 10.8.0.0/24 priority 20 table 120
PostDown = ip rule del from 10.8.0.0/24 priority 20 table 120PostUp = ip route add default via 10.8.0.2 dev wg0 table 120
PostDown = ip route del default via 10.8.0.2 dev wg0 table 120# --- PEER 1: POLSKI ROUTER (Exit Node) ---
[Peer]
PublicKey = oRL1WBFSEexxxxxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.8.0.2/32# --- PEER 2: TWOJE URZĄDZENIE (np. Smartfon 1) ---
[Peer]
# Ten klucz wygenerujesz w aplikacji WireGuard na telefonie
PublicKey = 7OX1tbQAVsaxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.8.0.10/32
Co do PBR nie wiem jak powinienem w takiej sytuacji ustawic
Na vps w sumie nie robisz nic, a kliencie A dajesz allowedips na 0.0.0.0/0 i robisz masq 1 w strefie wg, na kliencie B ręcznie robisz trasę domyślą przez interfejs wg z gatewayem wskazującym na adres IP klienta A. Całkiem możliwe że zadziała, nie sprawdzałem nie chcę sobie rozwalić swojego wireguarda na razie.
Na vps w sumie nie robisz nic, a kliencie A dajesz allowedips na 0.0.0.0/0 i robisz masq 1 w strefie wg, na kliencie B ręcznie robisz trasę domyślą przez interfejs wg z gatewayem wskazującym na adres IP klienta A. Całkiem możliwe że zadziała, nie sprawdzałem nie chcę sobie rozwalić swojego wireguarda na razie.
Ciężko bedzie, ale sprobuje, narazie posiłkowałem sie Gemimi , czy dobrze mi to przedstawił ?
Założenia:
Klient A (Brama): IP VPN: 10.0.0.1, Publiczny IP: 1.2.3.4Klient B (Użytkownik): IP VPN: 10.0.0.2
Port WireGuard: 51820
Klient A (Router jako Gateway/Serwer)
Na tym routerze musisz zezwolić na ruch z tunelu do internetu i włączyć maskaradę.1. Konfiguracja interfejsu i Peera (Klienta B):
# Dodanie peera (Klienta B)
uci add network wireguard_wg0 peer
uci set network.@wireguard_wg0[-1].public_key='KLUCZ_PUBLICZNY_KLIENTA_B'
uci set network.@wireguard_wg0[-1].allowed_ips='10.0.0.2/32' # Tylko IP klienta B
uci commit network
/etc/init.d/network restart
2. Konfiguracja Firewalla (Kluczowy krok):
Musisz stworzyć strefę dla WireGuarda i pozwolić jej "wychodzić" przez WAN.# Utworzenie strefy VPN
uci add firewall zone
uci set firewall.@zone[-1].name='vpn'
uci set firewall.@zone[-1].input='ACCEPT'
uci set firewall.@zone[-1].forward='REJECT'
uci set firewall.@zone[-1].output='ACCEPT'
uci set firewall.@zone[-1].network='wg0'
uci set firewall.@zone[-1].masq='1' # To jest Twoje "masq 1" w strefie WG# Pozwolenie na ruch ze strefy vpn do wan (internet)
uci add firewall forwarding
uci set firewall.@forwarding[-1].src='vpn'
uci set firewall.@forwarding[-1].dest='wan'# Otwarcie portu UDP dla WireGuarda na WAN
uci add firewall rule
uci set firewall.@rule[-1].name='Allow-WireGuard'
uci set firewall.@rule[-1].src='wan'
uci set firewall.@rule[-1].dest_port='51820'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].target='ACCEPT'uci commit firewall
/etc/init.d/firewall restartKlient B (Router przekierowujący cały ruch)
Na tym routerze kierujemy cały ruch lokalny (br-lan) do tunelu WireGuard.1. Konfiguracja Peera (Klienta A) z 0.0.0.0/0:
uci add network wireguard_wg0 peer
uci set network.@wireguard_wg0[-1].public_key='KLUCZ_PUBLICZNY_KLIENTA_A'
uci set network.@wireguard_wg0[-1].endpoint_host='1.2.3.4'
uci set network.@wireguard_wg0[-1].endpoint_port='51820'
uci set network.@wireguard_wg0[-1].allowed_ips='0.0.0.0/0' # Przekazuj wszystko
uci set network.@wireguard_wg0[-1].persistent_keepalive='25'
uci commit network
/etc/init.d/network restart
2. Konfiguracja Firewalla:
Musisz pozwolić sieci lokalnej (LAN) wychodzić przez tunel VPN.Bash
# Utworzenie strefy VPN
uci add firewall zone
uci set firewall.@zone[-1].name='vpn'
uci set firewall.@zone[-1].input='ACCEPT'
uci set firewall.@zone[-1].forward='REJECT'
uci set firewall.@zone[-1].output='ACCEPT'
uci set firewall.@zone[-1].network='wg0'# Forwarding z LAN do VPN
uci add firewall forwarding
uci set firewall.@forwarding[-1].src='lan'
uci set firewall.@forwarding[-1].dest='vpn'uci commit firewall
/etc/init.d/firewall restart
a nie lepiej zerotier lub tailscale? jesli masz vps , to postaw na nim headscale i w zasadzie nie bedziesz mial limitow. tak samo mozesz postawc swoj serwer zerotier. bedziesz mial wtedy direct polaczenie wychodzac z polskim IP. troche zabawy w konfiguracje tego , ale potem czysta satysfakcja.
Mam aktualnie Zerotier przez ktorego idzie cały ruch, tez mialem troche roboty aby na drugim routerze cały ruch szedł przez Polske ale ostatecznie sie udalo, musialem zmienic trasy , ostatecznie Gemini pomógł, nie wiem czy problemem nie był Starlink .
Chce zmienic na wireguard bo teoretycznie powienienem wyciagnac wiecej z Upload na Xiaomi AX3000T.
W weekend sprawdze to headscale
Ciężko bedzie, ale sprobuje, narazie posiłkowałem sie Gemimi , czy dobrze mi to przedstawił ?
NIe, zrobił ci normalnie połączenie serwera z klientem.
OT: A teraz pomyślcie - z tego forum już korzystają AI jako źródło wiedzy i dyktują odpowiedzi. Jak będziecie zamieszczać na tym forum jakiś losowe nie sprawdzone chore pomysły AI, to przyszłe modele będą się uczyć na tych danych i pokazywać je jako rozwiązania które ktoś będzie chciał zastosować. Jak już umieszczacie tu wymysły jakiś "sztucznych inteligencji" to chociaż napiszcie że to jest nie sprawdzone, nie działa itd, bo będzie zaraz co chwila wyrywane z kontekstu.
pazdzioch napisał/a:Ciężko bedzie, ale sprobuje, narazie posiłkowałem sie Gemimi , czy dobrze mi to przedstawił ?
NIe, zrobił ci normalnie połączenie serwera z klientem.
OT: A teraz pomyślcie - z tego forum już korzystają AI jako źródło wiedzy i dyktują odpowiedzi. Jak będziecie zamieszczać na tym forum jakiś losowe nie sprawdzone chore pomysły AI, to przyszłe modele będą się uczyć na tych danych i pokazywać je jako rozwiązania które ktoś będzie chciał zastosować. Jak już umieszczacie tu wymysły jakiś "sztucznych inteligencji" to chociaż napicie że to jest nie sprawdzone, nie działa itd, bo będzie zaraz co chwila wyrywane z kontekstu.
No nie działa 
Każdy się posiłkuje tym co może, gdyby był przykład na stronie lub jak bym wiedział gdzie taki na forum jest, a zapewne jest to by próbował. W sumie po to jest forum i strony tego typu.
Na vps w sumie nie robisz nic, a kliencie A dajesz allowedips na 0.0.0.0/0 i robisz masq 1 w strefie wg, na kliencie B ręcznie robisz trasę domyślą przez interfejs wg z gatewayem wskazującym na adres IP klienta A. Całkiem możliwe że zadziała, nie sprawdzałem nie chcę sobie rozwalić swojego wireguarda na razie.
czy tak ma wyglądać trasa domyślna na kliencie B
ip route del default
ip route add default via 10.0.0.3 dev wg0
?
Co do firewall to w luci masq 1 - to jest opcja maskarada?
Tak to jest to. Tak, o ile taki adres ma drugi klient.
Łel... Zrobiłem mały eksperyment. Klient A <> vps z serwer <> Klient B. I tak jak chciałeś, klient B ma wychodzić w internety przez klienta A a nie serwer.
No i teraz było pytanie: czy zamiast bawić się z pbr'em da się zrobić tak żeby spiąć tylko tunel pomiędzy A/VPS/B i żeby B zestawił sobie drugi tunel już bezpośrednio do A przez ten poprzedni tunel. Więc... da się, tylko trzeba zrobić dwa tunele.
(nazwy są takie a nie inne bo jak na mifi jadę)
EDIT: kodu nie ma bo takie rozwiązanie wymaga dopracowania.
I tu ten magic - peer ma nawiązać połączenie z 192.168.23.4 czyli klientem A. Do tego firewalla, strefa, masq 1 i ACCEPTY.
Działa, bo klienta A to router z modemem i jak robię z klienta B pobieranie strony to widzę że idzie przez modem a nie przez VPS czy adresu kablówki na którym jest klient B.
Jak chcesz to spróbuj powtórzyć, tylko pamiętaj że wg nadpisuje trasę domyślną 0.0.0.0 i jak zrobić coś źle to stracisz połączenie. Lepsze jest tam wpisane 128.0.0.1/1.
Aż dziwne że udało się to tak zestawić, pierwszy raz zrobiłem tunel wg przez tunel wg.
PS. i się płącze po restarcie. Jak ręcznie zrobiony jest wan, pierwszy tunel i uruchamiany drugi tunel to dopiero działa.
PS1. Nie, straszny problem jest z czymś takim, nie stosujcie takiego rozwiązania.
Ale ta konfiguracja dotyczy dwoch routerow z openwrt A i B ?
Musze skombinowac drugi sprzet z openwrt aby na sucho sprobowac to zestawic
Tak, to były openwrt. Ale nie rób tak, nie jest to rozwiązanie na którym można polegać.
najpierw spróbuje tez pierszej opcji którą napisales
Projekt na sobotę, wracamy z tematem.
Przyznam się szczerze że nie wiem jak to ugryźć z pbr'em, przynajmniej tak żeby zbytnio nie ruszać VPS'a - co zrobiłem to ruch i tak wychodził przez VPSa, a nie chcę go jakoś dużo zmieniać, więc odpuściłem temat. Jeżeli ktoś opanuje ten temat z pbr'em to niech zrobi poradnik, z chęcią zobaczę jak to zrobić.
Wracam do swojego pierwotnego założenia: klient A łączy się wireguardem z VPS, klient B także łączy się wireguardem z VPS, klient B zestawia sobie tunel do klienta A i wychodzi jego wanem w świat. Klient A i B to OpenWrt 25.12, A ma modem komórkowy, B jest spięty siecią kablową. VPS to Debian. Za klientem B jest host który ma wychodzić w świat nie przez VPSa a przez klienta A.
Założenia:
VPS: adres wireguard 192.168.30.1
Klient A: adres 192.168.30.4 oraz 192.168.40.4, na lanie ma 192.168.11.1/24, wan to modem komórkowy
Klient B: adres 192.168.30.3 oraz 192.168.40.3, na lanie ma 192.168.1.1/24, wan to zwykłe dhcp, adres 10.11.12.xx
0:
Robisz normalnego wireguarda na A/B z VPS, sprawdzasz czy działa, czy wychodzą przez VPS'a w świat bo to oznacza że działa routing, forwarding, dns itd. Bez zrobienia takiego połączenia i testu nie robisz nic dalej.
1: VPS
Zwykły debian, robisz konfigurację np. taką
[Interface]
PrivateKey = <priv-vps>
Address = 192.168.30.1/24
ListenPort = 53100
[Peer]
# Name = klient B
PublicKey = <pub-b>
AllowedIPs = 192.168.30.3/32
PersistentKeepalive = 25
[Peer]
# Name = klient a
PublicKey = <pub-a>
AllowedIPs = 192.168.30.4/32, 192.168.40.4/32
PersistentKeepalive = 25+ forwarding, nat, firewall, jak to w zwykłym debianie
2. Klient A
network
config interface 'wg0'
option proto 'wireguard'
option private_key '<priv-a>'
list addresses '192.168.30.4/24'
config wireguard_wg0
option description 'vps'
option public_key '<pub-vps>'
option endpoint_host '<adres-ip-publiczny-vps>'
option endpoint_port '53100'
option persistent_keepalive '25'
option route_allowed_ips '1'
list allowed_ips '192.168.30.0/24'
config interface 'wg1'
option proto 'wireguard'
option private_key '<priv-a>'
list addresses '192.168.40.4/24'
option listen_port '52000'
config wireguard_wg1
option public_key '<pub-b>'
option persistent_keepalive '25'
option route_allowed_ips '1'
list allowed_ips '192.168.40.0/24'firewall
config zone 'wg0'
option name 'wg0'
list network 'wg0'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option masq '1'
option mtu_fix '1'
config forwarding
option dest 'lan'
option src 'wg0'
config forwarding
option src 'lan'
option dest 'wg0'
config forwarding
option dest 'wan'
option src 'wg0'
config zone 'wg1'
option name 'wg1'
list network 'wg1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option masq '1'
option mtu_fix '1'
config forwarding
option dest 'lan'
option src 'wg1'
config forwarding
option src 'lan'
option dest 'wg1'
config forwarding
option dest 'wan'
option src 'wg1'
config forwarding
option dest 'wg0'
option src 'wg1'
config forwarding
option src 'wg0'
option dest 'wg1'wg0 to tunel do VPS'a. wg1 to tunel do którego będzie nawiązywać połączenie klient B, którym będzie wychodził w świat. Dodatkowo zezwolenie na ruch pomiędzy każdym z tuneli a drugim tunelem, lan i wan.
3. Klient B
network
config interface 'wg0'
option proto 'wireguard'
option private_key '<priv-b>'
option auto '1'
list addresses '192.168.30.3/24'
config wireguard_wg0
option public_key '<pub-vps>'
option endpoint_host '<adres-ip-publiczny-vps>'
option endpoint_port '53100'
option persistent_keepalive '25'
option route_allowed_ips '1'
list allowed_ips '192.168.30.0/24'
list allowed_ips '192.168.40.4/32'
config interface 'wg1'
option proto 'wireguard'
option private_key '<priv-b>'
option auto '0'
list addresses '192.168.40.3/24'
config wireguard_wg1
option public_key '<pub-a>'
option endpoint_host '192.168.40.4'
option endpoint_port '52000'
option persistent_keepalive '25'
option route_allowed_ips '1'
list allowed_ips '0.0.0.0/1'
list allowed_ips '128.0.0.0/1'firewall
config zone
option name 'wg0'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'wg0'
option masq '1'
config forwarding
option src 'wg0'
option dest 'wan'
config forwarding
option src 'wg0'
option dest 'lan'
config forwarding
option dest 'wg0'
option src 'lan'
config zone
option name 'wg1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'wg1'
option masq '1'
config forwarding
option src 'wg1'
option dest 'wan'
config forwarding
option src 'wg1'
option dest 'lan'
config forwarding
option dest 'wg1'
option src 'lan'
config forwarding
option src 'wg1'
option dest 'wg0'
config forwarding
option src 'wg1'
option dest 'wg0'i jeszcze trzeba zrobić plik /etc/hotplug.d/iface/99-wg o zawartości
if [ "$ACTION" = "ifup" ] && [ "$INTERFACE" = "wg0" ]; then
sleep 3
ifup wg1
fi
if [ "$ACTION" = "ifdown" ] && [ "$INTERFACE" = "wg0" ]; then
sleep 3
ifdown wg1
fiJak to ma działać:
- klient A nawiązuje połączenie do wanu, zestawia się tunel do VPS'a. I jednocześnie zrobi się końcówka drugiego tunelu która słucha na porcie 52000.
- klient B nawiązuje połączenie do wanu, zestawia się tunel do VPS'a. jest tak zrobiony, żeby forwardować tylko pakiety adresowane pierwszym tunelem ORAZ adres 192.168.40.4 który jest adresem drugiego tunelu na kliencie A. ten pierwszy tunel do VPS jest zawsze aktywny, drugi tunel jest domyślnie wyłączony - nie uruchomi się po starcie. Jak wg się zestawi z VPS'em to skrypt w hotplugu włączy drugi tunel i automatycznie zestawi się drugi tunel bezpośrednio z klientem A: raz nadpisując się trasę do hosta 192.168.40.4 oraz dwa - robiąc sobie trasę domyślną do internetu przez wg1. Można by tam umieścić 0.0.0.0/0 jak to jest w poradnikach do wg ale ja nie lubię jak mi nadpisuje trasę domyślną a później jak padnie to jej nie ustawia i wolę zapis list allowed_ips '0.0.0.0/1' oraz list allowed_ips '128.0.0.0/1'.
Mamy więc przez klienta B najpierw zestawiany tunel do VPS'a, po tym tunelu zestawiany jest drugi tunel bezpośrednio już do klienta A i klient B ustawia globalny routing przez ten drugi tunel. Działa, właśnie piszę przez taki zestaw, przeżywa restarty i nic nie trzeba grzebać ręcznie żeby to działało
4. Diagnostyka
Do diagnostyki na kliencie B:
ifdown wg1
ifdown wg0
ifup wan
ping 8.8.8.8 <- ma działać, wyjście na świat przez wan
ifup wg0
ping 8.8.8.8 <- ma działać, wyjście na świat przez wan
ping -I wg0 192.168.30.4 <- ma działać, druga strona pierwszego tunelu
ping -I wg0 192.168.40.4 <- ma działać, druga strona drugiego tunelu
ifup wg1
traceroute 8.8.8.8
musisz widzieć coś w rodzaju
root@OpenWrt:~# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 46 byte packets
1 192.168.40.4 (192.168.40.4) 90.328 ms 80.017 ms 78.626 ms
...Czyli idzie przez drugi tunel.
I teraz dowolny host podłączony do klienta B będzie wychodził jego trasą domyślną przez drugi tunel do klienta A i dalej w świat:
host:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 OpenWrt.lan (192.168.1.1) 0.671 ms 0.678 ms 1.679 ms
2 192.168.40.4 (192.168.40.4) 121.148 ms 121.311 ms 121.387 ms
....Wchodząc z hosta na adres np. https://twojeip.wp.pl/ powinieneś widzieć IP z klienta A, nie z VPS czy swojego wanu.
Kawał dobrej roboty, teraz muszę to po swojemu przetrawić na sucho na dwóch routerach
Jeszcze pytanie aktualnie do routera A, mam dostęp przez zerotier, czy zero i wireguard mogą działać niezależnie?
No mogą działać, o ile nie popsujesz routingu i nie będziesz używał tych samych klas adresowych.
No właśnie muszę zmienić IP routerów na inne.
czy przy tej konfiguracji którą podałes, klienci urządzenia podłaczone do Klienta A beda korzytały z Ip serwera VPS ? chce aby zostali przy swoim polskim IP.
Taką konfiguracje chyba bedzie mozna tez na mikrusie zastosowac ? korzystając z poradnika do mikrusa która podałes w seksji wireguard na stronie?
Nie, nie będą korzystały z VPS. Klient A nie ma rutowania całego ruchu, nie zauważyłeś tego?
Tak, możesz to i na mikrusie zrobić.
Nie, nie będą korzystały z VPS. Klient A nie ma rutowania całego ruchu, nie zauważyłeś tego?
Tak, możesz to i na mikrusie zrobić.
no nie widze, ale w koncu dojde do tego
Żeby cały ruch szedł przez wg to w allowedips musi być wpisane 0.0.0.0/0, czyli trasa domyślna. Klient A tego nie ma, ma wskazaną tylko adresację właściwą dla samego wg.
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → Wireguard serwer na VPS - ruch przez Klienta z Polskim IP
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc