Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → Przepychanie/most przez VPN
Strony Poprzednia 1 2 3 4 5 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Co to znaczy " sieć gościnną tunelowaną przy użyciu gre poprzez wireguard "
W sensie że zestawiasz tunel wireguard i przez to pchasz dodatkowy tunel gre czy jak to chciałeś zrobić?
Dokładnie tak, tunel gre działa na podstawie zestawionego dotychczas tuneru wireguard.
Do gre na dwóch końcach tunelu połączone powinny być sieci gościnne.
Z jednej strony guest jest serwerem dhcp zarówno dla strony lokalnej jak i zdalnej sieci gościnnej.
męczysz to przepychanie od stycznia. Kobiety zdążyły by urodzić dzieciaka do tego czasu.
...
#config device
#option name 'guest'
#option type 'bridge'
#list ports '@gretap'
#list ports 'lan4'...
#config interface 'guest'
#option proto 'dhcp'
#option type 'bridge'
#option device '@gretap'
#option force_link '1'
#option broadcast '1'
1. Nie wiem czy to dobry pomysł definiować typ "bridge" w sekcji "interface" skoro jest już w sekcji "device"
2. Twój device nazywa się "guest" a Ty w sekcji interfejsu wybierasz "@gretap"
Liczyłem na Ciebie @mar_w, że się odezwiesz. Do tego strofującym tonem, ale rozumiem, że mimo to z pozytywnym nastawieniem do moich problemów.
W sumie to mogłem skorzystać z Twoich podpowiedzi, które zamieściłeś tutaj w temacie wcześniej, ale jakoś wyleciało mi to z główy, w momencie kiedy byłem przy zdalnym routerze. Projekt/test nie jest priorytetowy dlatego to, tak długo twa. 
Ponieważ nie jestem fizycznie przy routerze zdalnym to dam sobie na wstrzymanie, bo jak grzebałem ostatnio na odległośc to odciąłem domownikom całkowicie dostęp do internetu poprzez router.
A to w dzisiejszych czasach jak brak żywności 
Za wskazówkę dziękuję i na pewno ją zastosuje w stosownym momencie.
1. Nie wiem czy to dobry pomysł definiować typ "bridge" w sekcji "interface" skoro jest już w sekcji "device"
Czyli cała sekcja interface jest zbędna?
2. Twój device nazywa się "guest" a Ty w sekcji interfejsu wybierasz "@gretap"
#config device
#option name 'guest'
#option type 'bridge'
#list ports '@guest'
#list ports 'lan4'
A to ma tak wyglądać?
Teraz mam inną zabawę, chociaż nie jest mi do śmiechu. Muszę ożywić Belkina 3200 a nie idzie mi najlepiej.
jakim strofującym tonem ?
@imkebe dał wędkę a rybkę trzeba sobie samemu złowić w zależności jaką dasz zanętę
Ty naprawdę nie wiesz o co chodzi w konfiguracjach sieci, czy zgrywasz się dla żartów?
Przeanalizuj to co napisałem. Po kolei, może zrozumiesz:
1. Nie wiem czy to dobry pomysł definiować typ "bridge" w sekcji "interface" skoro jest już w sekcji "device"
Moje zdanie wcale nie oznacza, że masz usunąć całą sekcję 'interface'. Gdzie to wyczytałeś w tym zdaniu.
W Twoim konfigu było:
#config device
#option name 'guest'
#option type 'bridge'
skoro w sekcji device masz typ "bridge" to po co jeszcze raz robisz tutaj:
#config interface 'guest'
#option proto 'dhcp'
#option type 'bridge'
z mojego zdania wcale nie wynika to co napisałeś:
Czyli cała sekcja interface jest zbędna?
trochę jakbyś mi imputował coś czego nie napisałem.
dalej...
2. Twój device nazywa się "guest" a Ty w sekcji interfejsu wybierasz "@gretap"
W Twoim konfigu było:
config device
#option name 'guest'
#option type 'bridge'
#list ports '@gretap'
skoro w sekcji device podpiąłeś alias do portu gretap bo taki masz w konfigu
#config interface 'gretap'
#option proto 'gretap'
#option peeraddr '10.9.0.1'
#option ipaddr '10.9.0.2'
...'
to znaczy, że w konfigu urządzenia 'guest" już jest gretap oraz radio.
a skoro urządzenie o nazwie guest zawiera w sobie gretap i wifi to w sekcji interface miałeś zamiast
#option device '@gretap'wybrać
option device 'guest'i to wynikało z drugiego mojego zdania.
W Twoim przypadku będzie to wyglądać:
#config device
#option name 'guest'
#option type 'bridge'
#list ports '@gretap'
#list ports 'lan4'
...
#config interface 'guest'
#option device 'guest'
#option proto 'dhcp'
A jakbyś trochę lepiej nazywał pewne rzeczy to szybciej doszedłbyś do prawidłowych konfigów.
Nazwy mogą być dowolne, ale jeżeli w sekcji device wstawiasz opcję "type 'bridge'" to w nazwie dobrze dać "name 'br-guest'"
I wtedy od razu widzisz, że nowy interfejs jest bridgem zawierającym w sobie inne interfejsy.
A tak to nie widzisz i łatwo można się zgubić....
Na początku postu przepraszam za swoje "nieogarnięcie" ale nie potrafię rozkminić takiego tematu.
Mam nadzieję, że mnie mar_w nie "skrytykuje"
Sieć gościnna na porcie LAN4 i Wi-Fi ma dostęp do internetu.
Natomiast lan po urucomieniu sieci gościnnej nie ma dostępu do Internetu. Traci go po skonfigurowaniu połączenia poprzez gretap.
Sieć gościnna działa poprzez wireguard i adresacja poprzez gretap - tak dla klarownowści opisu.
Jest to router będący klientem WG
Co w firewall'u jest nie tak bo zakładam, że to to błędne wpisy tutaj powodują tutaj takie jaja.
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option src 'wan'
option target 'ACCEPT'
option proto 'udp'
option dest_port '55055'
option name 'wireguard'
config zone
option name 'wg'
list network 'wg0'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config forwarding
option src 'wg'
option dest 'lan'
config forwarding
option src 'lan'
option dest 'wg'
config forwarding
option src 'wg'
option dest 'wan'
config forwarding
option src 'wan'
option dest 'wg'
config zone
option name 'guest'
list network 'guest'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config forwarding
option src 'lan'
option dest 'guest'
config forwarding
option src 'guest'
option dest 'wan'
config forwarding
option src 'wan'
option dest 'guest'Zapewne mam coś namieszane w forwardingu pomiędzy strefami, ale nie mam koncepcji.
Na początku postu przepraszam za swoje "nieogarnięcie" ale nie potrafię rozkminić takiego tematu.
Mam nadzieję, że mnie mar_w nie "skrytykuje"Sieć gościnna na porcie LAN4 i Wi-Fi ma dostęp do internetu.
Natomiast lan po urucomieniu sieci gościnnej nie ma dostępu do Internetu. Traci go po skonfigurowaniu połączenia poprzez gretap.
...
Jest to router będący klientem WG
....
tu nie chodzi o to czy ktoś Ciebie skrytykuje tylko o to, że robiłeś jakoś chaotycznie mając gotowy przepis od @imkebe
1. Skoro jesteś peerem-klientem WG to nie musisz otwierać portu na WAN (bo nie jesteś serwerem, żeby robić takie rzeczy). Niby nie zaszkodzi ale recenzenci mają więcej niepotrzebnej analizy Twojego konfigu.
2. A to że LAN traci dostęp do Internetu może być spowodowane tym, że w tunelu gretap przechodzą ramki warstwy 2 i pewnie zamieniają Ci trasę domyślną dla całego routera.
3. Dodatkowo nie masz maskarady w tunelu i jeżeli pakiety z sieci LAN wyjdą przez tunel gdzieś do serwera WG to on nie będzie wiedział gdzie odesłać, bo adresów sieci LAN za Twoim peerem-klientem WG zapewne nie ma w swojej tablicy routingu.
sprawdź, bo być może dałeś ciała na routingu a nie firewallu
ale na tym peerze-kliencie WG tylko sieć gościnna (na wi-fi i LAN4) ma iść poprzez WG i gretap.
Natomiast LAN 1-3 ma działać na normalnej adresacji i wychodzić na świat klasycznie.
Może muszę ustawić na interfejsie LAN gateway i DNS, albo skonfigurować VLAN-y?
Będąc podłączonym do sieci gościnnej nie da się wejść na LAN, czyli guest jest odizolowany od lan w obecnej konfiguracji.
Może tak być, ale jak dla mnie nie musi być guest izolowany od LAN.
no właśnie o tym pisałem, że jak zestawiasz tunel WG to jeszcze nic się nie dzieje, ale jak wchodzi gretap z ramkami dhcp z jakiegoś zdalnego routera DHCP to Twoja trasa domyślna na routerze pewnie zmienia się na tą nową trasę domyślną.
o ile interfejs "guest" na routerze może być obsłużony przez nową trasę do Internetu, to już LAN-owcy nie są zdolni do komunikacji z Internetem, bo z punktu widzenia drugiej końcówki tunelu, te adresy są mu nieznane.
Skoro LAN-owcy muszą wychodzić klasycznym WAN-em to nie możesz dać maskarady na tunelu tylko bawić się routingiem.
Zrób tak. Na interfejsie "guest" routera daj statyczny adres IP z sieci zdalnego serwera DHCP z maską, bez bramy i bez DNS.
Router nie będzie łapał nowej trasy domyślnej, ale klienci podpięci pod port LAN4 i Wifi dostaną tą trasę od zdalnego serwera DHCP bo będą w tej samej sieci "guest" i dla nich ma być pobieranie adresów i tras po DHCP.
Router jako taki, nadal będzie miał Internet z klasycznego WAN-a bo będzie miał tylko jedną trasę domyślną przez WAN.
No i wziął i poładował 
(naprawił po polsku). 
@mar_w, wielkie dziękuję dla Ciebie.
Wygląda na to, że jest OK. Ale zabawy robiłem na testowym routerze, gdzie za źródło internetu służyła komórka poprzez tethering USB, na BTS-ie o średnich parametrach - chociaż na działanie, poza prędkością nie ma to żadnego wpływu.
Jutro sprawdzę na innym roterze i dam znać czy mi to działa.
Prawdę powiedziawszy w życiu bym nie wpadł na to, że serwer DHCP na jednym końcu tunelu, obsługujący sieć gościnną ma jakikolwiek wpływ na działanie serwera DHCP odpowiadającego za adresację LAN-u.
Skoro gretap wykorzystuje adresację wireguarda, i jest to przecież logicznie wyizolowana sieć - jako tunel, to założyłem, że nie może mieć to żadnego znaczenia dla działania lanu po jednej czy drugiej stonie tunelu.
Raz jeszcze bardzo Ci dziękuję za pomoc
Nie ma za co. no tak to działa ,
bo jeżeli adres tunelu "gretap" na routerze otrzymywałeś dynamicznie po DHCP to również przez ten interfejs był ustawiany główny gateway na całym routerze-kliencie WG i nadpisywana była cała trasa domyślna, bo gretap jest częścią routera a router domyślnie ma jedną tablicę routingu.
A teraz jak masz statyczny adres na "gretap" w routerze to on nie kwiczy, że chce dostać adres i dzięki temu router nie dostaje również trasy domyślnej bo i po co, skoro ma klasycznego WAN-a.
Natomiast klienci Wifi i LAN4 tego "guesta" wołają o adres i za pomocą tunelu dostają adres i trasę z dalekiej końcówki i tą daleką końcówką wychodzą do Internetu
...
Prawdę powiedziawszy w życiu bym nie wpadł na to, że serwer DHCP na jednym końcu tunelu, obsługujący sieć gościnną ma jakikolwiek wpływ na działanie serwera DHCP odpowiadającego za adresację LAN-u.
Tu mylisz pojęcia. Serwer DHCP na końcu tunelu nie ma wpływu na działanie serwera DHCP na LAN-ie.
Serwer DHCP na LAN-ie działa dobrze, daje adresy swoim klientom LAN-owym, daje im trasę domyślną przez siebie samego, ale to tamten serwer nadpisywał trasę domyślną na routerze a to nie oznacza, że ma wpływ na działanie lokalnego serwera DHCP.
Jakby go zatrzymywał lub zmieniał na routerze plik /etc/config/dhcp to można tak mówić, że ma wpływ na lokalny serwer DHCP. Ale tak nie robił
bo jeżeli adres tunelu "gretap" na routerze otrzymywałeś dynamicznie po DHCP to również przez ten interfejs był ustawiany główny gateway na całym routerze-kliencie WG i nadpisywana była cała trasa domyślna, bo gretap jest częścią routera a router domyślnie ma jedną tablicę routingu.
A teraz jak masz statyczny adres na "gretap" w routerze to on nie kwiczy, że chce dostać adres i dzięki temu router nie dostaje również trasy domyślnej bo i po co, skoro ma klasycznego WAN-a.
Natomiast klienci Wifi i LAN4 tego "guesta" wołają o adres i za pomocą tunelu dostają adres i trasę z dalekiej końcówki i tą daleką końcówką wychodzą do Internetu
Wracam do tematu po tygodniu. Nie po to aby szukać konkretnych rozwiązań w tej chwili ale dla zdobycia nowej wiedzy.
@mar_w, sęk w tym, że nie korzystałem i na chwilę obecną nie korzystam z DHCP na interfejsie "gretap".
Mam spięte dwa routery poprzez "gretap" i strony tego tunelu są zaadresowane ip używanym przez wireguard.
Podobnie jak jest to opisane na początku tematu przez @imkebe, chociaż on pisał o połączeniu kilku likalizacji.
Swoją drogą też się zastanawiałem jak połączyć wiecej niż dwie lokalizacje przy wykorzystaniu wg i gretap ale żadnych testów nie robiłem.
Po sprawdzeniu działania sieci gościnnej i LAN na kliencie wg internet do LAN powrócił, czyli niby osiągnąłem to co chciałem jednak nie wszystkie urządzenia były w stanie osiągnąć adres ip w sieci gościnnej nieależnie czy to po wifi czy po kablu, tak więc będę pewnie jeszcze w tym grzebał.
...
@mar_w, sęk w tym, że nie korzystałem i na chwilę obecną nie korzystam z DHCP na interfejsie "gretap".
Mam spięte dwa routery poprzez "gretap" i strony tego tunelu są zaadresowane ip używanym przez wireguard.
Podobnie jak jest to opisane na początku tematu przez @imkebe, chociaż on pisał o połączeniu kilku likalizacji.
dobra, dobra, strony tunelu gretap muszą być przypięte do interfejsów które mają adresy i widzą siebie wzajemnie.
Gretap przypinasz do adresów WG, ale zauważ, że gretap ma również swój adres IP. Może nie tyle sam gretap co kolejny interfejs np. "guest" który jest podlinkowany do gretap np. "@tun10"
Bez sensu jest tworzyć tylko interfejs "tun10" protokołem gretap, bez kolejnego interfejsu, który musi wisieć na tym gretapie ale z innym adresem niż tunel-nośnik.
Jak byś ukrył węzły sieci bez tego dodatkowego interfejsu? Na początku napisałem to skrótem myślowym, ale wiadomo o co chodzi i dlaczego tak a nie inaczej
@imkebe też tak zrobił. Adresy WG to sieć 192.168.50.0/24 natomiast adresy Guest które wiszą na protokole gretap to sieć 192.168.5.0/24 (to widać na serwerze DHCP bo tam jest adres statyczny, a klient pobiera po dhcp bo ma option proto dhcp (https://eko.one.pl/forum/viewtopic.php? … 72#p235972)
...
Po sprawdzeniu działania sieci gościnnej i LAN na kliencie wg internet do LAN powrócił, czyli niby osiągnąłem to co chciałem jednak nie wszystkie urządzenia były w stanie osiągnąć adres ip w sieci gościnnej nieależnie czy to po wifi czy po kablu, tak więc będę pewnie jeszcze w tym grzebał.
Nie wiem co to znaczy, że nie wszystkie urządzenia były w stanie osiągnąć adres ip. Czyli część urządzeń mogła, a cześć nie mogła, bo tak by wynikało z Twojego opisu.
To musisz zbadać tych podejrzanych klientów
Jeżeli mam działające połączenie wireguard o nazwie wg0, które funkcjonuje na routerach z openwrt
i chciałbym na kolejnej parze routerów (w tych samych lokalizacjach) uruchomić kolejne połaczenie wireguard o nazwie wg1
to czy to ma prawo działać?
1. Czy porty używane przez wg0 i wg1 powinny być inne?
2. Czy lepiej, żeby te kolejne routery były połaczone poprzez WAN i miały swoja adresację na LAN-ie (opcja A)
czy lepiej, żeby były połączone poprzez LAN i były "zwykłymi AP-ekami" (opcja B)? (przypuszczam, że zależy to od tego co sobie wybiorę)
3. Czy może być z jednej strony opcja A z drugiej opcja B?
4. Przy opcji A muszę na routerach nadrzędnych (brzegowych) ustawić routing statyczny i przekierować porty używane przez wg1 a na routerach końcowych tylko ustawić regułę w firewallu dla wireguard, czy zrobić coś jeszcze?
Rozumiem że robisz projekt do szkółki na zaliczenie, bo nikt nie pyta o taką ekwilibrystykę w praktycznych rozwiązaniach.
Zazwyczaj w szkółce robi się bezsensowne rzeczy, bo nie mają pomysłu na lepsze zadania a trzeba jakoś wypełnić godziny lekcyjne
1. Skoro to jest kolejna para routerów z niezależnym wyjściem w świat to mogą operować na tym samym porcie bo będą miały inny IP_Publiczny.
A jeżeli ta kolejna para wychodzi z tego samego IP to musi być inny port dla drugiego tunelu.
Masz parę IP:port
Jeżeli zmienia się pierwszy człon to nie musisz zmieniać drugiego członu.
Jeżeli nie zmienia się pierwszy człon to musisz zmienić ten drugi.
To nie było trudno wymyśleć.
2. Jak ustawisz tak będziesz miał
3. J.w.
4. Zależy jak podłączone są te routery w pkt.1
A tak w ogóle już łączyłeś sieci w innym temacie:
https://eko.one.pl/forum/viewtopic.php? … 15#p262115
Ogólnie to tam miałeś przykłady gdy serwer jest hostem w LAN1 i gdy klient też jest hostem ale w innym LAN2
Zdaje sobie sprawę, że zasadność takiego rozwiązania z praktycznego punktu widzenia jest bez sensu.
I zgadzam się z Twoją opinią, że należy takie próby traktować jako szkolne ćwiczenia na zaliczenie
Natomiast od czasu do czasu trzeba utrwalić nawet bardzo skromne wiadomości (czytaj moje) w zakresie konfigurowania wireguard/GRE czy bardziej precyzyjne wiadomości o działaniu sieci.
Moje pytanie związane jest z faktem, że mam skonfigurowane połączenie podobnie jak w temacie tylko obecnie na dwóch lokalizacjach. Jednak okresowo dla testów coś klikam i do zestawiania tunelu wykorzystuje połączenie LTE poprzez tethering USB co zaczyna mi ciążyć. Dlatego aby nie popsuć obecnego wg0 i i wyeliminować GSM chcę stworzyć wg1 ale na dedykowanym sprzęcie.
Teoretycznie mógłbym to zrobić na obecnej konfiguracji sprzętowej ale obawiam się, że coś namieszam - jak to ja
i nawet to co działa się posypie
Dlatego najpierw musisz mieć konkretne założenia:
- czy serwer WG i klient WG są za NATem, lub jedno z nich jest za NATem lub żadne nie jest za NATem bo są bramami.
I już masz 4 kombinacje które diametralnie zmieniają sytuację.
- gdy są za NATem to mogą być podłączone do swojego portu WAN lub do LAN.
Kolejna różnica w konfiguracji....
- czy chcesz dostęp tylko po adresach WG czy również między sieciami LAN1 <-> LAN2
- a co z GRE? Czy ma być dopięty do tunelu jako TUN czy TAP ?
To tylko wstęp do Twojego zapytania
Najlepiej jakbyś sobie narysował ten konfig podobnie do tego co podałem w linku w #90 bo sam napisałeś że mógłbyś coś namieszać, a tu łatwo o pomyłkę...
Kontynuacja "szkolnego zadania". Wstępne ustawienia podane na rysunku.
Router R1 ma swój serwer wireguard wg0 (na czas testów można go wyłączyć) żeby nie mieszał w działaniu serwera wireguard wg1
uruchomionego na routerze R2.
Router R2 połączony z R1 poprzez LAN więc zwykły akcess point. Na R1 włączona maskarada na LAN-ie.
1. W związku z tym czy na R2 powinienem ustawiać reguły ruchu sieciowego i / lub przekazywanie portów w odniesieniu do wg1 czyli port 50255?
Zakładam, że nie bo nie używamu na tym routerze WAN-u więc firewall nie ma tutaj zastosowania?
2. Co powinienem zrobić w R1:
- ustawić regułę ruchu sieciowego dla wg1
- czy wystarczy właczyć tylko przekazaywanie portów dla wg1?
Na chwilę obecną próbuję osiągnąć działające połączenie wireguard wg1 pomiędzy R2 (poprzez R1) a R3.
Komunikacja pomiędzy klientami LAN 1 (R1+R2) i LAN 2(R3) ma być możliwa
GRE i sieci gościnnej na chwilę obecną do tego nie mieszajmy bo w tym zakresie nic się nie zmieniło względem wcześniejszych założeń.
Pewnie ustawienia firewalla w R1 będą istotne, ponieważ jest tam również drugi serwer wireguard wg0, który ma się łączyć z routerem R4 (klient wg0) ale nie umieszczałem go na schemacie dla klarowności rysunku.
0. włączyć maskaradę na lanie r2
1. na r1 ma być przekietowanie portu 50255 na r2
Coś mam nadal namieszane , nie pinguje się wireguard wg1.
R1 network - przekaźnik wg1 - LAN1 DHCP serwer
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdf6:6aea:db50::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option device 'wan'
option proto 'pppoe'
option username 'użytkownikl'
option password 'hasło'
option ipv6 'auto'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
config interface 'wg0'
option proto 'wireguard'
option private_key 'klucz prywatny'
option listen_port '55055'
list addresses '10.9.0.1/24'
option mtu '2800'
config wireguard_wg0
option public_key 'klucz'
option route_allowed_ips '1'
option persistent_keepalive '25'
option description 'openwrt'
list allowed_ips '10.9.0.2/32'
list allowed_ips '192.168.9.0/24'
list allowed_ips '10.9.0.6/24'
list allowed_ips '192.168.3.0/24'
list allowed_ips '10.9.0.4/32'
list allowed_ips '192.168.7.0/24'
list allowed_ips '192.168.2.0/24'
list allowed_ips '10.9.0.5/32'
list allowed_ips '192.168.5.0/24'
list allowed_ips '10.9.0.7/32'
list allowed_ips '10.9.0.8/32'
list allowed_ips '10.9.0.9/32'
list allowed_ips '192.168.8.0/24'
config wireguard_wg0
option public_key 'klucz'
option description 'Tplink1043'
option persistent_keepalive '25'
option route_allowed_ips '1'
list allowed_ips '10.9.0.6/24'
list allowed_ips '192.168.3.0/24'
config wireguard_wg0
option public_key 'klucz'
option route_allowed_ips '1'
list allowed_ips '10.9.0.2/32'
list allowed_ips '192.168.9.0/24'
option persistent_keepalive '25'
option description 'openwrt_totolink'
option disabled '1'
config wireguard_wg0
option public_key 'KEY'
option route_allowed_ips '1'
list allowed_ips '10.9.0.3/32'
option persistent_keepalive '25'
option description 'android'
config wireguard_wg0
option description 'openwrt_3600'
option route_allowed_ips '1'
option persistent_keepalive '25'
option public_key 'klucz'
list allowed_ips '10.9.0.4/32'
list allowed_ips '192.168.7.0/24'
option disabled '1'
config wireguard_wg0
option public_key 'klucz'
list allowed_ips '10.9.0.5/32'
option route_allowed_ips '1'
option persistent_keepalive '25'
option description 'NUKcomputer'
option disabled '1'
config wireguard_wg0
option public_key 'klucz'
option description 'toshiba_windows'
list allowed_ips '10.9.0.7/32'
option route_allowed_ips '1'
option persistent_keepalive '25'
config interface 'gretap'
option proto 'gretap'
option ipaddr '10.9.0.1'
option tunlink 'wg0'
option mtu '1560'
option peeraddr '10.9.0.6'
config device
option name 'br-guest'
option type 'bridge'
list ports 'lan4'
list ports '@gretap'
config interface 'guest'
option proto 'static'
option ipaddr '172.16.0.1'
option netmask '255.255.255.0'
option device 'br-guest'R1 firewall
onfig defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option masq '1'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option output 'ACCEPT'
option masq '1'
option mtu_fix '1'
option input 'ACCEPT'
option forward 'ACCEPT'
config forwarding
option src 'lan'
option dest 'wan'
config zone
option name 'wg'
list network 'wg0'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'guest'
list network 'guest'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config rule
option src 'wan'
option target 'ACCEPT'
option proto 'udp'
option dest_port '55055'
option name 'wireguard_wg0'
config forwarding
option src 'lan'
option dest 'wg'
config forwarding
option src 'wg'
option dest 'lan'
config forwarding
option src 'wg'
option dest 'wan'
config forwarding
option src 'wan'
option dest 'wg'
//
... ... ...
//
[b]config redirect
option target 'DNAT'
list proto 'udp'
option src 'wan'
option src_dport '50255'
option dest_port '50255'
option name 'wireguard_wg1'
option dest_ip '192.168.1.120'[/b]R2 network - sewrwer wg1 - LAN1
onfig interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option packet_steering '1'
option ula_prefix 'fd59:180c:f133::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
[b]
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.1.120'
option gateway '192.168.1.1'
[/b]
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
[b]
config interface 'wg1'
option proto 'wireguard'
option private_key 'key'
list addresses '10.10.0.1/24'
option listen_port '50255'
config wireguard_wg1
option route_allowed_ips '1'
option persistent_keepalive '25'
option public_key 'KEY'
option description 'R6220_client'
list allowed_ips '192.168.8.0/24'
list allowed_ips '10.10.0.2/32'
[/b]
config interface 'gretap'
option proto 'gretap'
option ipaddr '10.10.0.1'
option tunlink 'wg1'
option mtu '1560'
option peeraddr '10.10.0.2'
config device
option name 'br-guest'
option type 'bridge'
list ports 'lan4'
list ports '@gretap'
config interface 'guest'
option proto 'static'
option ipaddr '172.16.0.1'
option netmask '255.255.255.0'
option device 'br-guest'R2 firewall
onfig defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option masq '1'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option output 'ACCEPT'
option masq '1'
option mtu_fix '1'
option input 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wg'
list network 'wg1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config forwarding
option src 'wg'
option dest 'lan'
config forwarding
option src 'lan'
option dest 'wg'
config zone
option name 'guest'
list network 'guest'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config forwarding
option src 'guest'
option dest 'lan'
config forwarding
option src 'lan'
option dest 'guest'
config forwarding
option src 'guest'
option dest 'wg'R3 network - klient wg1 - serwer DHCP LAN 2
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option packet_steering '1'
option ula_prefix 'fd47:8cf3:ecf6::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
[b]
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.8.1'
[/b]
config device
option name 'br-guest'
option type 'bridge'
list ports '@gretap'
list ports 'lan4'
config interface 'guest'
option device 'br-guest'
option proto 'static'
option ipaddr '172.16.0.100'
option netmask '255.255.255.0'
option gateway '172.16.0.1'
config interface 'gretap'
option proto 'gretap'
option peeraddr '10.10.0.1'
option ipaddr '10.10.0.2'
option tunlink 'wg1'
option mtu '1560'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
config interface 'wan'
option proto 'dhcp'
option device 'usb0'
[b]
config interface 'wg1'
option proto 'wireguard'
option private_key 'key'
list addresses '10.10.0.2/24'
config wireguard_wg1
option public_key 'key'
option endpoint_host 'moje IP'
option persistent_keepalive '25'
option description 'R6220'
list allowed_ips '10.10.0.1/32'
list allowed_ips '192.168.1.0/24'
list allowed_ips '192.168.9.0/24'
option endpoint_port '50255'
[/b]R3 firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option output 'ACCEPT'
option masq '1'
option mtu_fix '1'
option input 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wg'
list network 'wg1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'guest'
list network 'guest'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option src 'wan'
option target 'ACCEPT'
option proto 'udp'
option dest 'wg'
option name 'wireguard1'
option src_port '50255'
option dest_port '50255'
config forwarding
option src 'lan'
option dest 'wg'
config forwarding
option src 'wg'
option dest 'lan'
config forwarding
option src 'wg'
option dest 'wan'
config forwarding
option src 'wan'
option dest 'wg'
config forwarding
option src 'guest'
option dest 'wan'
//
... ... ...
//Nie podałeś ani kluczy ani adresów. Nie można zweryfikować czy chociaż by połączenie po wg zrobiłeś poprawnie. Skoro nie chcesz tego podać to sam zweryfikuj czy nie pomyliłeś kluczy i czy forwarding działa.
Adresacja wireguard'a jest podana a klucze powinny być OK ale jeszcze raz sprawdzę.
Jak w code pogrubić tekst, to zaznacze te fragmenty z adresacją?
A obawiam się, że ten forwarding mam spierdzielony.
Adresacji endpointa nie podałeś do którego się próbujesz dobić.
w endpoint jest moje stałe publiczne IP
Ja ci wierzę, ale posprawdzać wszystko w takim razie musisz sam.
Strony Poprzednia 1 2 3 4 5 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → Przepychanie/most przez VPN
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc