Skocz do zawartości
Zamknięcie Forum PC LAB

Szanowny Użytkowniku,

Informujemy, że za 30 dni tj. 30 listopada 2024 r. serwis internetowy Forum PC LAB zostanie zamknięty.

Administrator Serwisu Forum PC LAB - Ringier Axel Springer Polska sp. z o.o. z siedzibą w Warszawie: wypowiada całość usług Serwisu Forum PC LAB z zachowaniem miesięcznego okresu wypowiedzenia.

Administrator Serwisu Forum PC LAB informuje, że:

  1. Z dniem 29 listopada 2024 r. zakończy się świadczenie wszystkich usług Serwisu Forum PC LAB. Ważną przyczyną uzasadniającą wypowiedzenie jest zamknięcie Serwisu Forum PC LAB
  2. Dotychczas zamowione przez Użytkownika usługi Serwisu Forum PC LAB będą świadczone w okresie wypowiedzenia tj. do dnia 29 listopada 2024 r.
  3. Po ogłoszeniu zamknięcia Serwisu Forum od dnia 30 października 2024 r. zakładanie nowych kont w serwisie Forum PC LAB nie będzie możliwe
  4. Wraz z zamknięciem Serwisu Forum PC LAB, tj. dnia 29 listopada 2024 r. nie będzie już dostępny katalog treści Forum PC LAB. Do tego czasu Użytkownicy Forum PC LAB mają dostęp do swoich treści w zakładce "Profil", gdzie mają możliwość ich skopiowania lub archiwizowania w formie screenshotów.
  5. Administrator danych osobowych Użytkowników - Ringier Axel Springer Polska sp. z o.o. z siedzibą w Warszawie zapewnia realizację praw podmiotów danych osobowych przez cały okres świadczenia usług Serwisu Forum PC LAB. Szczegółowe informacje znajdziesz w Polityce Prywatności

Administrator informuje, iż wraz z zamknięciem Serwisu Forum PC LAB, dane osobowe Użytkowników Serwisu Forum PC LAB zostaną trwale usunięte ze względu na brak podstawy ich dalszego przetwarzania. Proces trwałego usuwania danych z kopii zapasowych może przekroczyć termin zamknięcia Forum PC LAB o kilka miesięcy. Wyjątek może stanowić przetwarzanie danych użytkownika do czasu zakończenia toczących się postepowań.

krzysik

Forumowicze
 Pokaż profil  Zobacz aktywność

  • Liczba zawartości

    8

  • Rejestracja

  • Ostatnia wizyta

Odpowiedzi dodane przez krzysik

  1. Napisano

    re: zen3.

    Dziękuję za podpowiedź.

    Po instalacji gcc (pkg install lang/gcc) i próbie wykonania make install komunikat jaki dostaję niestety jest taki sam: sh: cc: not found   :(

    Wziąłem się za poradniki do których podałeś mi linki. Przy instalacji skryptu dochodzę do momentu: kldload nvidia-modeset. I dostaję kolejny błąd:

    kldload: an error occurred while loading the module. Please check dmesg(8) for more details. 

    echo 'linux_load="YES"' >> /boot/loader.conf
echo 'nvidia-modeset_load="YES"' >> /boot/loader.conf
echo 'nvidia_load="YES"' >> /boot/loader.conf
kldload linux
pkg install nvidia-driver
mkdir -p /usr/local/etc/X11/xorg.conf.d
printf 'Section "Device" \n Identifier "NVIDIA Card" \n VendorName "NVIDIA Corporation" \n Driver "nvidia" \n EndSection' > /usr/local/etc/X11/xorg.conf.d/driver-nvidia.conf
kldload nvidia-modeset
kldload nvidia
    
 

  2. Napisano

    Witam,

    Zainstalowałem FreeNAS-11.3-U5 na FreeBSD 11.3-RELEASE-p14 amd64. Z zainstalowanym Emby serwer. Żeby transkodować wideo włożyłem kartę GTX 1660 super. Pobrałem sterownik ze strony https://www.nvidia.pl/Download/driverResults.aspx/184675/pl

    Tu zaczynają się dla mnie schody, jestem zielony z systemów linux :( .

    Czy ktoś mógłby mi krok po kroku pokazać jak zainstalować sterownik karty graficznej w tym systemie ? 

    Pobrałem sterownik, rozpakowałem spakowany plik. Na pierwszym kroku dostaje błąd przy poleceniu "make install". 

    sh: cc: not found
make: "/usr/share/mk/bsd.compiler.mk" line 147: Unable to determine compiler type for CC=cc.  Consider setting COMPILER_TYPE.

    Zainstalowałem pakiet gcc (pkg install gcc). Błąd cały czas ten sam.

  3. Napisano

    Już mnie oświeciło ;)

    Źle adresowałem serwer i klientów.

    server.conf

    server-bridge 192.168.3.170 255.255.255.0 192.168.3.175 192.168.3.179
ifconfig 192.168.3.170 255.255.255.0
client-to-client

    Teraz chodzą pingi z sieci lokalnej do serwera i na odwrót.

    Pozostał problem skonfigurowania drugiego rutera na openwrt. Niestety tu pomimo zmiany adresu klienta VPN na 192.168.3.176 nadal pingi nie chodzą.

     

    Dziwne bo pomimo tego, że połączył się z serwerem VPN 192.168.3.170 nie odebrał żadnego pakietu.

    Status tap0 na Openwrt.

    tap0      Link encap:Ethernet  HWaddr 16:59:6E:D2:7F:87
         inet addr:192.168.3.176  Bcast:192.168.3.255  Mask:255.255.255.0
         inet6 addr: fe80::1459:6eff:fed2:7f87/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
         TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:100
         RX bytes:0 (0.0 B)  TX bytes:746 (746.0 B)

    Jakieś sugestie ?

  4. Napisano

    Witam,

    Dziękuję za wsparcie duchowe - Certyfikaty pokonane :) klienci się autoryzują.

    Niestety sieci LAN nie "gadają ze sobą".

    Na tą chwilę sprawa wygląda następująco:

    Serwer na Debianie

    server.conf

    #tomato home
dev tap

proto udp                       
port 1144                       

cipher AES-256-CBC              


server-bridge 10.9.8.1 255.255.255.0 10.9.8.5 10.9.8.7
client-to-client

...

     

    Klient 1 (tomato na ASUSIE) LAN 192.168.3.0 <--> VPN 10.9.8.5

    Klient 2 (openwrt na ASUSIE) LAN 192.168.3.0 <--> VPN 10.9.8.6

     

    Po połączeniu klientów w logach serwera dostaję:

    Tue Jun  2 18:40:31 2020 OpenVPN 2.4.7 x86_64-pc-linux-gnu [sSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
Tue Jun  2 18:40:31 2020 library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10
Tue Jun  2 18:40:31 2020 NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previou$
Tue Jun  2 18:40:31 2020 Diffie-Hellman initialized with 2048 bit key
Tue Jun  2 18:40:31 2020 ROUTE_GATEWAY 51.68.136.1
Tue Jun  2 18:40:31 2020 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Tue Jun  2 18:40:31 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.3.0
Tue Jun  2 18:40:31 2020 TUN/TAP device tap0 opened
Tue Jun  2 18:40:31 2020 TUN/TAP TX queue length set to 100
Tue Jun  2 18:40:31 2020 /sbin/ip link set dev tap0 up mtu 1500
Tue Jun  2 18:40:31 2020 /sbin/ip addr add dev tap0 10.9.8.1/24 broadcast 10.9.8.255
Tue Jun  2 18:40:31 2020 Could not determine IPv4/IPv6 protocol. Using AF_INET
Tue Jun  2 18:40:31 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Tue Jun  2 18:40:31 2020 UDPv4 link local (bound): [AF_INET][undef]:1144
Tue Jun  2 18:40:31 2020 UDPv4 link remote: [AF_UNSPEC]
Tue Jun  2 18:40:31 2020 MULTI: multi_init called, r=256 v=256
Tue Jun  2 18:40:31 2020 IFCONFIG POOL: base=10.9.8.5 size=3, ipv6=0
Tue Jun  2 18:40:31 2020 ifconfig_pool_read(), in='tomato,10.9.8.5', TODO: IPv6
Tue Jun  2 18:40:31 2020 succeeded -> ifconfig_pool_set()
Tue Jun  2 18:40:31 2020 IFCONFIG POOL LIST
Tue Jun  2 18:40:31 2020 tomato,10.9.8.5
Tue Jun  2 18:40:31 2020 Initialization Sequence Completed
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 TLS: Initial packet from [AF_INET]5.184.73.79:18804, sid=83ae2bcc 3c8e947c
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 VERIFY OK: depth=1, CN=forest
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 VERIFY OK: depth=0, CN=open_wrt
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 peer info: IV_VER=2.4.7
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 peer info: IV_PLAT=linux
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 peer info: IV_PROTO=2
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 peer info: IV_NCP=2
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 peer info: IV_LZ4=1
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 peer info: IV_LZ4v2=1
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 peer info: IV_LZO=1
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 peer info: IV_COMP_STUB=1
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 peer info: IV_COMP_STUBv2=1
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 peer info: IV_TCPNL=1
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1589', remote='link-mtu 1574'
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher BF-CBC'
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Tue Jun  2 18:40:47 2020 5.184.73.79:18804 [open_wrt] Peer Connection Initiated with [AF_INET]5.184.73.79:18804
Tue Jun  2 18:40:47 2020 open_wrt/5.184.73.79:18804 MULTI_sva: pool returned IPv4=10.9.8.6, IPv6=(Not enabled)
Tue Jun  2 18:40:48 2020 open_wrt/5.184.73.79:18804 PUSH: Received control message: 'PUSH_REQUEST'
Tue Jun  2 18:40:48 2020 open_wrt/5.184.73.79:18804 SENT CONTROL [open_wrt]: 'PUSH_REPLY,route 10.9.8.1 255.255.255.0,route-gateway 10.9.8.1,ping 10,ping-restart 120,ifconfig 10.9.8.6 255.255.255.0,peer-id 0,ci$
Tue Jun  2 18:40:48 2020 open_wrt/5.184.73.79:18804 Data Channel: using negotiated cipher 'AES-256-GCM'
Tue Jun  2 18:40:48 2020 open_wrt/5.184.73.79:18804 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Jun  2 18:40:48 2020 open_wrt/5.184.73.79:18804 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Jun  2 18:40:49 2020 open_wrt/5.184.73.79:18804 MULTI: Learn: 16:36:0b:69:60:66 -> open_wrt/5.184.73.79:18804
Tue Jun  2 18:40:50 2020 open_wrt/5.184.73.79:18804 Can't learn 05:36:0b:69:60:66: network is a multicast address
Tue Jun  2 18:41:02 2020 open_wrt/5.184.73.79:18804 MULTI: Learn: 1e:b4:cb:07:ed:2d -> open_wrt/5.184.73.79:18804
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 TLS: Initial packet from [AF_INET]31.60.135.177:31159, sid=a2a1b696 ca0bc74f
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 VERIFY OK: depth=1, CN=forest
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 VERIFY OK: depth=0, CN=tomato
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 peer info: IV_VER=2.4.3
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 peer info: IV_PLAT=linux
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 peer info: IV_PROTO=2
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 peer info: IV_NCP=2
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 peer info: IV_LZ4=1
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 peer info: IV_LZ4v2=1
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 peer info: IV_LZO=1
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 peer info: IV_COMP_STUB=1
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 peer info: IV_COMP_STUBv2=1
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 peer info: IV_TCPNL=1
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1589', remote='link-mtu 1573'
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher BF-CBC'
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Tue Jun  2 18:41:38 2020 31.60.135.177:31159 [tomato] Peer Connection Initiated with [AF_INET]31.60.135.177:31159
Tue Jun  2 18:41:38 2020 tomato/31.60.135.177:31159 MULTI_sva: pool returned IPv4=10.9.8.5, IPv6=(Not enabled)
Tue Jun  2 18:41:39 2020 tomato/31.60.135.177:31159 PUSH: Received control message: 'PUSH_REQUEST'
Tue Jun  2 18:41:39 2020 tomato/31.60.135.177:31159 SENT CONTROL [tomato]: 'PUSH_REPLY,route 10.9.8.1 255.255.255.0,route-gateway 10.9.8.1,ping 10,ping-restart 120,ifconfig 10.9.8.5 255.255.255.0,peer-id 1,ciph$
Tue Jun  2 18:41:39 2020 tomato/31.60.135.177:31159 Data Channel: using negotiated cipher 'AES-256-GCM'
Tue Jun  2 18:41:39 2020 tomato/31.60.135.177:31159 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Jun  2 18:41:39 2020 tomato/31.60.135.177:31159 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Jun  2 18:41:39 2020 tomato/31.60.135.177:31159 MULTI: Learn: 00:00:1b:05:54:a0 -> tomato/31.60.135.177:31159
Tue Jun  2 18:41:39 2020 tomato/31.60.135.177:31159 MULTI: Learn: 9c:a3:a9:10:47:55 -> tomato/31.60.135.177:31159
Tue Jun  2 18:41:40 2020 tomato/31.60.135.177:31159 MULTI: Learn: 08:60:6e:bc:37:f0 -> tomato/31.60.135.177:31159
Tue Jun  2 18:41:40 2020 tomato/31.60.135.177:31159 MULTI: Learn: 00:27:22:d8:3c:44 -> tomato/31.60.135.177:31159

     

    Z tego co rozumiem to klienci wymieniają się z serwerem adresami MAC więc już prawie mam to co chcę... ale. Teraz utknąłem od 2 dni.

     

    Przy ustawieniu klienta (tomato VPN 10.9.8.5) z opcją "Server is on the same subnet" przekazuje serwerowi adresy MAC-i. Pingi nie chodzą do serwera z ani z serwera do klienta.

     

    Klienta openwrt VPN 10.9.8.6 nie ustawiam w tryb "Server is on the same subnet" bo nie ma tam takiej opcji w ustawieniach. Zakładam, że jest ona domyślna bo też przekazuje MAC-i do serwera. Pingi tak jak w przypadku tomato nie chodzą od klienta do serwera ani z serwera do klienta.

    Klienci tez nie pingują się pomiędzy sobą ani adresami VPN (10.9.8.5<-->10.9.8.6) ani po sieci LAN np. (192.168.3.50<-->192.168.3.60)

     

    Nie do końca rozumiem sposób działania połączenia VPN w trybie mostu. Wydawało mi się, że jak przyłącze dwóch klientów (dwie części tej samej sieci LAN) do serwera VPN (tap) to wszystko samo ruszy. Czytałem poradniki które znalazłem ale nie ogarniam. Tryb mostu miał zastępować "kabel" ale chyba nie do końca tak to jest :)

    Jeżeli ktoś ma jeszcze do mnie trochę cierpliwości to proszę o wskazówki.

  6. Napisano

    Faktycznie namieszałem z tymi adresami na tunelu. Jestem początkujący, przeczytałem, że skoro tap to warstwa2 to adresy takie same jak dla sieci lokalnej ;(

    Zmieniłem IP na tap0 (10.9.8.1) i tap1 (10.9.8.2)

     

    

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 10.9.8.1  netmask 255.255.255.0  broadcast 10.9.8.255
       inet6 fe80::ccec:b8ff:fe3e:cb59  prefixlen 64  scopeid 0x20<link>
       ether ce:ec:b8:3e:cb:59  txqueuelen 100  (Ethernet)
       RX packets 2  bytes 108 (108.0 B)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 10  bytes 796 (796.0 B)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 10.9.8.2  netmask 255.255.255.0  broadcast 10.9.8.255
       inet6 fe80::204d:66ff:fe2f:c7de  prefixlen 64  scopeid 0x20<link>
       ether 22:4d:66:2f:c7:de  txqueuelen 100  (Ethernet)
       RX packets 0  bytes 0 (0.0 B)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 13  bytes 1006 (1006.0 B)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

     

    Niestety nadal ping wykonywany z serwera VPN (debian) na 10.9.8.1 czy 10.9.8.2 nie chodzi :(

    Co do serwera na tomato to może nie dokładnie to opisałem. Tomato to klienci w sieci lokalnej, serwer VPN na Debianie.

  8. Napisano

    Witam wszystkich.

    Czy to możliwe aby postawić działający tunel warstwy 2 dla klientów z wewnętrznym IP ? Chodzi o to, żeby komputery z sieci A i B widziały się nawzajem i rozsyłały broadcasty.

    Sieć A:

    ruter Asus N66U tomato (openVPN client tap0)

    WAN 192.168.66.3 --> modem LTE (lan192.168.66.1 i wan - zmienne IP)

    LAN 192.168.3.120

     

    Sieć B:

    ruter Asus N66U tomato (openVPN client tap1)

    WAN 192.168.1.1 --> modem LTE (lan192.168.1.1 i wan - zmienne IP)

    LAN 192.168.3.2

    vpn_schemat.jpg

    schemat sieci

     

    zewnętrzne IP VPS Debian buster (openVPN server)

     

    Od 3 dni walczę i utknąłem :) CO mam zrobione:

    klient VPN sieci A i B łączy się do Debiana.

     

    /etc/openvpn/tap0.conf

    dev tap0
port 1144  #<=Port na ktorym bedzie dzialal nasz serwer
   proto udp
ifconfig  192.168.3.220 255.255.255.0 #<=adres ip na ktory bedziemy sie logowali klientem
   #keepalive 10 120
cipher AES-256-CBC
   status /tmp/openvpn-status.log
ping 15
      ping-restart 45
      ping-timer-rem
   verb 3
   secret /etc/openvpn/static.key #<=klucz autoryzacji polaczenia
   inactive 3600
push "ping 10"
push "ping-restart 60"
push "route 192.168.3.0 255.255.255.0" #<= Ta opcja odpowiada za routing serwer siec lokalna

     

    /etc/openvpn/tap1.conf

    dev tap1
port 1145  #<=Port na ktorym bedzie dzialal nasz serwer
   proto udp
ifconfig  192.168.3.221 255.255.255.0 #<=adres ip na ktory bedziemy sie logowali klientem
   #keepalive 10 120
cipher AES-256-CBC
   status /tmp/openvpn-status2.log
ping 15
      ping-restart 45
      ping-timer-rem
   verb 3
   secret /etc/openvpn/static.key #<=klucz autoryzacji polaczenia
   inactive 3600
push "ping 10"
push "ping-restart 60"
push "route 192.168.3.0 255.255.255.0" #<= Ta opcja odpowiada za routing serwer siec lokalna

     

    tap0 i tap1 w ifconfig

     

    tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.3.220  netmask 255.255.255.0  broadcast 192.168.3.255
       inet6 fe80::40f5:40ff:fe89:1ed8  prefixlen 64  scopeid 0x20<link>
       ether 42:f5:40:89:1e:d8  txqueuelen 100  (Ethernet)
       RX packets 45  bytes 4150 (4.0 KiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 6  bytes 516 (516.0 B)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.3.221  netmask 255.255.255.0  broadcast 192.168.3.255
       inet6 fe80::ccfb:c0ff:fef0:7e16  prefixlen 64  scopeid 0x20<link>
       ether ce:fb:c0:f0:7e:16  txqueuelen 100  (Ethernet)
       RX packets 0  bytes 0 (0.0 B)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 6  bytes 516 (516.0 B)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

     

    Sieci się nie widzą,

    nie pingują się z lokalnych komputerów np (192.168.3.10 do 192.168.3.20)

    nie pingują do tap0 i tap1 np 192.168.3.10 do 192.168.3.220

    nie pingują pomiędzy tap0 do tap1 192.168.3.220 do 192.168.3.221

     

    Używałem też brctl do zmostkowania tap0 i tap1, niestety bez efektu.

    Czy może mi ktoś podpowiedzieć co zrobić żeby połączyć sieci Ai B - żeby swobodnie śmigały między nimi pakiety. Czy to w ogóle wykonalne w tym przypadku ?

    pozdrawiam,

×
×
  • Dodaj nową pozycję...