Cześć

Mam dziwaczny problem z routingiem Ipv6.

Tunel Ipv6 tunnelbroker (HE.net)
Konfiguracja:

network.henet=interface
network.henet.proto='6in4'
network.henet.metric='1024'
network.henet.peeraddr='216.66.80.162'
network.henet.ip6addr='2001:479:70:2cf::2/64'
network.henet.tunnelid='NUMER_TUNELU'
network.henet.username='USERNAME'
network.henet.password='PASSWORD'
network.henet.ip6prefix='2001:479:71:2cf::/64'
network.henet.delegate='1'

Próbuję z kompa (który adresy dostał z autokonfiguracji SLAAC) puścić pinga:

ping6 ifconfig.io -c1
PING ifconfig.io (2a06:98c1:3120::b) 56 data bytes

--- ifconfig.io ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Firewall wyraźnie przepuszcza pakiet, ostatni łańcuch, przez który wędrował pakiet to srcnat: .

trace id 7cfc0391 inet routerek mangle_postrouting packet: iif "br-lan" oif "6in4-henet" ether saddr 68:05:ca:2c:6d:cf ether daddr 38:94:ed:f8:7b:2c ip6 saddr 2001:479:71:2cf:cf1f:27ca:5b72:4fd3 ip6 daddr 2a06:98c1:3120::b ip6 dscp cs0 ip6 ecn not-ect ip6 hoplimit 63 ip6 flowlabel 519881 ip6 nexthdr ipv6-icmp ip6 length 64 icmpv6 type echo-request icmpv6 code no-route icmpv6 parameter-problem 131073 @th,64,96 0xa87f9f66000000002c680500 
trace id 7cfc0391 inet routerek mangle_postrouting verdict continue 
trace id 7cfc0391 inet routerek mangle_postrouting policy accept 

Pojawia się jednak w tym komunikacje nftables dziwaczny parametr:

code no-route

WTF?

Rzeczywiście, routing nie funguje:

# Router ###  12:04  Router : /etc/config/local 

 root ~> ip route get 2a06:98c1:3120::b 
ip: RTNETLINK answers: Network unreachable

Co ciekawe, routing jest ustawiony prawidło:

# Router ###  12:10  Router : /etc/config/local 

 root ~> ip -family inet6 route show | grep -v -e anycast -e multicast
default from 2001:479:70:2cf::/64 dev 6in4-henet  metric 1024 
default from 2001:479:71:2cf::/64 dev 6in4-henet  metric 1024 
2001:479:70:2cf::/64 dev 6in4-henet  metric 1024 
2001:479:71:2cf::/64 dev br-lan  metric 1024 
unreachable 2001:479:71:2cf::/64 dev lo  metric 2147483647 
fd2c:9fd7:c7c1::/64 dev br-lan  metric 1024 
unreachable fd2c:9fd7:c7c1::/48 dev lo  metric 2147483647 
fe80::/64 dev eth0  metric 256 
fe80::/64 dev br-lan  metric 256 
fe80::/64 dev phy1-ap0  metric 256 
fe80::/64 dev wan  metric 256 
fe80::/64 dev phy0-ap0  metric 256 
fe80::/64 dev 6in4-henet  metric 256 

W poprzednim routerze taka konfiguracja działała bez problemu, a w obecnym (Netgear R6260) nagle wyszła taka promocja, diabli wiedzą czemu.

PS.
Curl:

curl -6 -Iv https://ifconfig.io/ip
* Host ifconfig.io:443 was resolved.
* IPv6: 2a06:98c1:3121::b, 2a06:98c1:3120::b
* IPv4: (none)
*   Trying [2a06:98c1:3121::b]:443...
* connect to 2a06:98c1:3121::b port 443 from 2001:479:71:2cf:cf1f:27ca:5b72:4fd3 port 44156 failed: Przekroczony czas oczekiwania na połączenie
*   Trying [2a06:98c1:3120::b]:443...
* connect to 2a06:98c1:3120::b port 443 from 2001:479:71:2cf:cf1f:27ca:5b72:4fd3 port 43512 failed: Przekroczony czas oczekiwania na połączenie
* Failed to connect to ifconfig.io port 443 after 266374 ms: Couldn't connect to server
* Closing connection
curl: (28) Failed to connect to ifconfig.io port 443 after 266374 ms: Couldn't connect to server

Tradycyjnie nftables twierdzi, że to nie jego wina, żeby go nie bić

trace id 5289bfa8 inet routerek accept_to_wan rule oifname "6in4-henet" counter packets 2101 bytes 278652 accept comment "!fw4: accept 6in4 IPv6 traffic" (verdict accept)
trace id 5289bfa8 inet routerek mangle_postrouting packet: iif "br-lan" oif "6in4-henet" ether saddr 68:05:ca:2c:6d:cf ether daddr 38:94:ed:f8:7b:2c ip6 saddr 2001:479:71:2cf:ae9a:5556:cbb4:48b0 ip6 daddr 2a06:98c1:3120::b ip6 dscp cs0 ip6 ecn not-ect ip6 hoplimit 63 ip6 flowlabel 498284 ip6 nexthdr tcp ip6 length 36 tcp sport 42486 tcp dport 443 tcp flags == syn tcp window 42700 
trace id 5289bfa8 inet routerek mangle_postrouting verdict continue 
trace id 5289bfa8 inet routerek mangle_postrouting policy accept 

Żeby w Linuxie routing nie działał, to widzę pierwszy raz w życiu.

Pozdro

Cześć

Maszynka Netgear R6260 dotarła i działa dosyć grzecznie.

Przyszedł czas, aby reaktywować domowy serwerek jabbera.

Do tej pory używałem iptables i do jabbera miałem takie reguły:

IPv4:

iptables -A INPUT ! -i lo -p tcp -m multiport --dports 5269 -m connlimit --connlimit-upto 10 --connlimit-mask 0 --connlimit-saddr -m hashlimit --hashlimit-upto 10/min --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name xmpp -j ACCEPT
iptables -A INPUT ! -i lo -p tcp -m multiport --dports 5222 -m connlimit --connlimit-upto 10 --connlimit-mask 0 --connlimit-saddr -m hashlimit --hashlimit-upto 10/min --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name xmppclient -j ACCEPT

Ipv6:

ip6tables -A INPUT ! -i lo -p tcp -m multiport --dports 5269 -m connlimit --connlimit-upto 10 --connlimit-mask 0 --connlimit-saddr -m hashlimit --hashlimit-upto 10/min --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name xmpp6 -j ACCEPT
ip6tables -A INPUT ! -i lo -p tcp -m multiport --dports 5222 -m connlimit --connlimit-upto 10 --connlimit-mask 0 --connlimit-saddr -m hashlimit --hashlimit-upto 10/min --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name xmppclient6 -j ACCEPT

Próbowałem już kilka razy przepisać te reguły na nftables, ale bez sukcesu.
Jakieś sugestie?

Cześć

Jak w Netgearze WNDR4300v1 -  Openwrt 23.05 ustawić w plikach konfiguracyjnych wjazd do SSH przez WAN?
Mam na myśli obraz z domyślnym nftables...

Pytam, bo po ostatniej  awarii Vectry w mojej okolicy siadł nie tylko modem vectry ale także mój router stał się nagle i niespodziewanie acces-pointem (skutek pioruna w okolicy).
Wjazd do niego jest przez wifi, usb i WAN, ale switch LAN nie działa.
Czy z trybie failsafe jest wjazd przez WAN?
Gdzie wjazd ustawić w konfigu, żeby to przetrwało aktualizację obrazu Openwrt.

Pozdro

Cześć

Jakiś tydzień temu, w czasie wielkiej burzy, piorun zahaczył o lokalną sieć Vectry.

Popaliło w dzielnicy troszkę urządzeń, u mnie poszedł "router z Vectry - Ubee, ale przeszło też na Netgeara - spalony sam switch LAN, WAN, Wifi i USB działają, zdechła też karta sieciowa na płycie mojego kompa.
W kompie nie problem, wsadziłem inną sieciówkę, ale Netgear nie ma lan, także musiałem zapiać mojego "acces pointa Netgear" i komputer do nowego "routera", tym razem jest to Technicolor CGA 2121,

Z tym "routerem" a raczej mydelniczką CGA 2121, jest następujący problem.
Po włączeniu tego routera, zarówno komputer i netgear ciągną publiczne adresy z DHCP, Linux używa dhcpcd, netgear używa udhcp.
I po pobraniu adresu niby wszystko jest ok, przez jakiś czas, po czym mydelniczka w różnych odstępach czasu gubi połączenie z bramą routingu.
DHCPCD od razu nie reaguje, bo ma dzierżawę DHCP 28800 sekund, wiec niby wszystko jest w porządku, ale połączenia internetowego nie ma w ogóle na komputerze.

ip route show
default via 95.160.240.1 dev intel proto dhcp src 95.160.253.1xx metric 1024
95.160.240.0/20 dev intel proto dhcp scope link src 95.160.253.1xx metric 1024

ping -c50 95.160.240.1
PING 95.160.240.1 (95.160.240.1) 56(84) bytes of data.
From 95.160.253.1xx icmp_seq=1 Destination Host Unreachable
From 95.160.253.1xx icmp_seq=2 Destination Host Unreachable
From 95.160.253.1xx icmp_seq=3 Destination Host Unreachable
From 95.160.253.1xx icmp_seq=4 Destination Host Unreachable
....

Co ciekawe, raczej nie jest winny to kabel, tylko sprawa mydelniczki, bo np na komputerze net zdechł, ale netgear jeszcze internet ma, albo na netgearze już nie ma netu a na komputerze dalej działa.
To by wskazywało na winę mydelniczki a nie jakiegoś urządzenia powyżej mydelniczki.
Mydelniczka Technicolor CGA 2121 pracuje w trybie mostu (bridge).

Żeby naprawić taką sytuację wystarczy wyłączyć mydelniczkę CGA 2121 na 10 sekund z prądu, po czym włączyć ponownie.
Można też zabić proces dhcpcd w Linuxie, żeby wstał od nowa, jeśli nie zauważy utraty połączenia.
Niby prosta procedura, ale wykonywanie takiej procedur 6,7 albo i 11 razy dziennie jest dosyć denerwujące.

Taki pytanie w związku z tym? czy lepiej wnioskować o wymianę mydelniczki na inną, czy pożegnać Vectrę i poszukać innego dostawcy internetu.
Biorąc pod uwagę, że w 2023 roku zużyłem coś około 3000 GB transferu, a np w Oragne na kartę jest do zgarnięcia około 5400 GB na rok, wybór robi się coraz szerszy.
Modemy 5 G też na razie są drogie, ale też będą taniały.

Czy Vectra w mojej okolicy zacznie kiedyś działać po ciosie pioruna, nie jestem do końca pewien, natomiast zgłaszanie wadliwego działania internetu przez mydelniczkę jest ponad moje nerwy, korespondowałem tydzień z pomocą techniczną operatora i doszedłem do wniosku, ze Virtualna Konsultantka jest chyba jedyną "kompetentną" w całej tej firmie, korespondencja  mailowa z adresem kontakt@vectra.pl pokazał katastrofalny poziom pracowników Vectry, po prostu epidemię głupoty na poziomie opisanym przez sławnego naukowca:

Pozdrawiam

Cześć

Ipv6 mam w ramach interfejsu 6in4-henet.

Na routerze Ipv6 chodzi prawidłowo:

# OpenWRT ###  09:36  Router : ~ 

# root ~> ping6 -c1 google.com
PING google.com (2a00:1450:401b:810::200e): 56 data bytes
64 bytes from 2a00:1450:401b:810::200e: seq=0 ttl=121 time=14.238 ms

--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 14.238/14.238/14.238 ms

ale z  komputera już nie

ping6 -c1 google.com
PING google.com(waw07s06-in-x0e.1e100.net (2a00:1450:401b:80e::200e)) 56 data bytes
From 2001:470:71:11::1 (2001:470:71:11::1) icmp_seq=1 Destination unreachable: Port unreachable

--- google.com ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Routing na obu urządzeniach się zgadza, adresy komputer dostaje przez autokonfigurację bezstanową

# ip -6 r s 
2001:470:71:11::/64 dev net proto kernel metric 256 pref medium
fd2c:9fd7:c7c1::/64 dev net proto kernel metric 256 pref medium
fe80::/64 dev net proto kernel metric 256 pref medium
default via fe80::a263:91ff:fe7d:585a dev net proto ra metric 1024 expires 1454sec mtu 1280 hoplimit 64 pref medium

Na OpenWRT 21.02 z iptables wszystko brykało poprawnie w takiej samej konfiguracji.

Po wyłączeniu firewalla przez

/etc/init.d/firewall stop

Ipv6 działa normalnie.

Podobno OpenWRT to jest Linux.

We wszystkich znanych mi  serwerowo-desktopowych Linuksach jest mechanizm sprawdzania integralności zainstalowanych pakietów.
np w Debianie jest to debsums:
https://manpages.debian.org/bullseye/de … .1.en.html
W moim ulubiony Gentoo jest to qcheck:
https://wiki.gentoo.org/wiki/Q_applets# … 8qcheck.29

Jak się zowie podobny mechanizm w OpenWRT?

O rkhuntera nie pytam, bo on nie sprawdza sum wszystkich zainstalowanych pakietów,
tymczasem w bazach Debiana  /var/lib/dpkg/info czy w Gentoo /var/db/pkg są sumy kontrolne wszystkich zainstalowanych pakietów, nawet skryptów powłoki instalowanych oficjalną drogą.

Pozdro