Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#1  2019-08-28 21:15:32

  remi - amputować akrobatów

remi
amputować akrobatów
Zarejestrowany: 2011-05-27

NetworkManager oraz Logi systemowe: różne dane dot. DNS/nameserver.

Witam serdecznie.

Kilka tygodni temu, około miesiąca temu, na jednym z komputerów, który przeznaczony został do różnych testów, zmieniłem sposób w jaki konfigurowane było połączenie internetowe. Dotychczas, wyglądało to w ten sposób: [puszka ISP » router » komputer]. Po wspomnianej reorganizacji, odłączony został router. W celu uzyskania danych konfiguracyjnych, takich jak adres IP etc., wykorzystywany jest protokół DHCP. (Ponadto, w systemie zainstalowany oraz stosowany jest pakiet NetworkManager). To tyle tytułem wstępu.

W ostatnim czasie, zauważyłem pewne różnice, rozbieżności. Najbardziej narzucają się takie, które w nadmiarze pojawiają się w pliku /var/log/kern.log (poniżej, znajduje się tylko jeden przykład, a takich wpisów jest o wiele więcej):

Kod:

Aug 28 17:03:09 t4 NetworkManager[966]: <info>  [1567004589.3931]   server identifier 172.18.0.22
Aug 28 17:03:09 t4 NetworkManager[966]: <info>  [1567004589.3931]   lease time 1800
Aug 28 17:03:09 t4 NetworkManager[966]: <info>  [1567004589.3931]   nameserver '1.2.3.4'
Aug 28 17:03:09 t4 NetworkManager[966]: <info>  [1567004589.3931]   nameserver '5.6.7.8'

Powyższe informacje, nie zawierają danych dot. m.in. adresu IP, domyślnej trasy czy maski podsieci, ponieważ - według mnie - są nieistotne w odniesieniu do pytania, które chcę zadać. Poza tym myślę, że nie zawsze brak dodatkowych informacji pociąga za sobą spadek wartości czy obniża poziom opisywanej kwestii etc. (Przepraszam za to chwilowe odejście od tematu...)

A więc, kiedy router był podłączony (vide w/w konfiguracja sprzed opisanej zmiany), w logach systemowych pojawiały się, powiedzmy, poprawne dane, tj. adres IP (np. 192.168.1.10), DNS (np. darmowe serwery należące do OpenDNS). Proszę wybaczyć brak takowych logów, ale na chwilę obecną, nie jestem w stanie ich dostarczyć — czekam na nowy router.

Teraz ad rem: sytuacja zmieniła się diametralnie, kiedy router został odłączony. Pomimo ustawienia w programie NetworkManager, w zakładce [Ustawienia IPv4] dostępnej via "Modyfikuj połączenia..." (opcji, osiągalnej np. poprzez ikonkę programu, umiejscowionej na panelu etc.) serwerów DNS, wyniki są diametralnie różne!

W przypadku NetworkManager'a, sprawdzenie ustawionych adresów DNS, poprzez opcję "Informacje o połączeniu" (pojawia się nowe okno, zawierające podstawowe dane etc.) wskazuje dokładnie te, które zostały ustawione w sposób opisany wyżej. (Potwierdzeniem działania oraz poprawnej konfiguracji, jest znany komunikat ze strony welcome.opendns.com: "Welcome to OpenDNS! Your Internet is safer, faster, and smarter because you’re using OpenDNS. Thank you!").

Pomimo wspomnianych faktów, w logach systemowych zapisywane są informacje, zawierające kompletnie inne adresy (zob. w/w fragment pliku /var/log/kern.log). To, co zdumiewa i zastanawia najbardziej, jest fraza 'NetworkManager' zawarta w logach systemowych, które dodatkowo zawierają adresy różniące się od tych ustawionych w tym samym programie (a wcześniej, również w router'rze)! Czyli mamy sytuację, w której logi odnoszące się do aplikacji, zawierają inne dane od tych ustawionych bezpośrednio w tym programie. (Być może wszystko jest w porządku a ja czegoś nie rozumiem i się mylę?)

Podsumowując: czy jest to normalne, że logi systemowe (dotyczące 'NetworkManager') zawierają inne adresy od tych ustawionych w tym właśnie programie? Mam jeszcze takie pytanie: czym jest [server identifier 172.18.0.22] (to wyrażenie pojawia się w logach).

Zdaję sobie sprawę, że wśród Was jest wielu zwolenników usunięcia NetworkManager'a na rzecz chociażby pliku /etc/network/intefaces w celu konfiguracji sieci etc. Z drugiej jednak strony, mam praktycznie gotowy profil AppArmor dla NetworkManager'a, co w połączeniu z opcjami dot. "Hardeningu", które oferuje systemd (wymienić tu można np. 'Protect{System,Home}=') może stać się odpowiedniejszym rozwiązaniem.

Proszę wybaczyć ten przydługi post, ale spieszyłem się i nie byłem w stanie zredagować tekstu.

Pozdrawiam serdecznie.

Ostatnio edytowany przez remi (2020-05-30 15:43:00)


Łam ZAsady! wYjąTkÓw jest wIęcej.

Offline

 

#2  2019-08-29 00:34:28

  hi - Zbanowany

hi
Zbanowany
Zarejestrowany: 2016-03-24

Re: NetworkManager oraz Logi systemowe: różne dane dot. DNS/nameserver.

niezłe jaja

https://wiki.debian.org/WiFi/HowToUse

ten NetworkManager  jest wam potrzebny jak kula u nogi po co się pytam?

Kod:

cat /etc/network/interfaces
# loopback
auto lo
iface lo inet loopback

# lan
allow-hotplug enp0s25
iface enp0s25 inet static
    address 192.168.1.110
    netmask 255.255.255.0
    gateway 192.168.1.1

# wlan
allow-hotplug wlan0
iface wlan0 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    gateway 192.168.1.1
    wpa-ssid xxxx
    wpa-psk xxxx

pieprzone dziurawe dnsy to się chyba robi tak:

Kod:

cat /etc/resolv.conf 
nameserver 192.168.1.1

Kod:

cat /etc/arpon.sarpi 
192.168.1.1     xx:xx:xx:xx:xx:xx

Kod:

arp -a
(192.168.1.1) at xx:xx:xx:xx:xx:xx [ether] PERM on wlan0

Kod:

nikt@debian:~$ dns-check='dig debug.opendns.com txt'
bash: dns-check=dig debug.opendns.com txt: nie znaleziono polecenia
nikt@debian:~$ dig debug.opendns.com txt

; <<>> DiG 9.11.5-P4-5.1+b1-Debian <<>> debug.opendns.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61246
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debug.opendns.com.        IN    TXT

;; ANSWER SECTION:
debug.opendns.com.    0    IN    TXT    "server r3.wrw1"
debug.opendns.com.    0    IN    TXT    "flags 40020 0 70 180000000000000000007950800000000000000"
debug.opendns.com.    0    IN    TXT    "originid 0"
debug.opendns.com.    0    IN    TXT    "actype 0"
debug.opendns.com.    0    IN    TXT    "source xx.xx.xx.xx:xxxxx"
debug.opendns.com.    0    IN    TXT    "dnscrypt enabled (716D496B684B3766)"

;; Query time: 18 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: czw sie 29 00:47:57 CEST 2019
;; MSG SIZE  rcvd: 271

pewnie dużo więcej na to doszczętnie dziurawe guano jakim jest dns trzeba...

aha i nie polecam żadnej usługi dns stawiać na maszynie hosta to jest tak jak się wystawić na kulę w łep dosłownie, to gówno jest tak robaczywe, że wymaga specjalnej troski z oddzielnego fw

Ostatnio edytowany przez hi (2019-08-29 01:25:22)


"Są drogi, którymi nie należy podążać, armie, których nie należy atakować, fortece, których nie należy oblegać, terytoria, o które nie należy walczyć, zarządzenia, których nie należy wykonywać" Sun Tzu

Offline

 

#3  2019-08-29 12:09:25

  remi - amputować akrobatów

remi
amputować akrobatów
Zarejestrowany: 2011-05-27

Re: NetworkManager oraz Logi systemowe: różne dane dot. DNS/nameserver.

Cześć hi.

Dziękuję za odpowiedź. Jeśli chodzi o NetworkManager, to myślę, że masz całkowitą rację (w ciągu ostatnich tygodni, przekonałem się o tym niemal całkowicie). Z tego właśnie powodu, powstał profil AppArmor, czy dodane zostały wspomniane opcje systemd — aby w jakimś stopniu uczynić tę - jak to ująłeś - kulę lżejszą. Kulę, której zwykle nikt nie zauważa, obok której większość przechodzi obojętnie.

Mam rozumieć, że sugerujesz zastąpienie, bądź usunięcie w/w programu i skupienie się na konfiguracji np. via /etc/network/interfaces? (Natomiast, z daemon'a ArpON, oczywiście zamkniętego w klatce, korzystam od dłuższego czasu. To naprawdę ciekawe narzędzie). Z kolei DNSCrypt-proxy jest zainstalowany, ale... na innym komputerze, do którego w chwili obecnej, nie mam dostępu i szczerze mówiąc, nie wiem, kiedy to się zmieni. (Co prawda, mam kilka pytań odnośnie konfiguracji, ale tę kwestię poruszę już w innym temacie).

Za link dot. WiFi dziękuję, ale na chwilę obecną jest praktycznie bezużyteczny. Ponadto, nie ma "żadnej usługi dns na maszynie hosta (...)".

Czy ktoś z Was, ma jeszcze jakąś teorię, porady, uwagi etc., nt. sytuacji opisanej w pierwszym poście?

Pozdrawiam.


Łam ZAsady! wYjąTkÓw jest wIęcej.

Offline

 

#4  2019-08-29 20:29:53

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: NetworkManager oraz Logi systemowe: różne dane dot. DNS/nameserver.

Po DHCP dostajesz też DNSy dostawcy.
Pewnie te przetwarza NM.

Jeżeli dla wygody leniuszka trzymasz DHCP  na komputerach. to pytanie, kto kontroluje router, z którymi te  komputery gadają?
Na routerze sobie w takim przypadku ustaw co trzeba, żeby nie było kłopotów.
Jeżeli masz na routerze np OpenWRT, to będzie łątwiej, jeśli router ma w brzuchu własny system, to może troszkę trudniej,
ale generalnie nawet mydelniczkę można w miarę sensownie skonfigurować i ustawić w niej odpowiednie DNSy.

NM z jego domyślnymi akcjami i wiecznymi błędami jest w takiej sieci potrzebny dla zabicia czasu, jak się nudzisz, i chcesz sobie znaleźć jakiś problem do zabawy.

Przy okazji musisz się szybko nacieszyć DHCP, w IPv6 nie jest ten protokół w ogóle potrzebny, system wymieni z sąsiednimi urządzeniami pakiety ICMPv6 i w ciągu 5 sekund kernel sam sobie skonfiguruje sieć w trybie autokonfiguracji.
Wykorzysta do tego protokół RA.

Ostatnio edytowany przez Jacekalex (2019-08-29 20:35:16)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#5  2019-08-30 16:24:25

  hi - Zbanowany

hi
Zbanowany
Zarejestrowany: 2016-03-24

Re: NetworkManager oraz Logi systemowe: różne dane dot. DNS/nameserver.

remi napisał(-a):

Z kolei DNSCrypt-proxy jest zainstalowany, ale... na innym komputerze, do którego w chwili obecnej, nie mam dostępu i szczerze mówiąc, nie wiem, kiedy to się zmieni. (Co prawda, mam kilka pytań odnośnie konfiguracji, ale tę kwestię poruszę już w innym temacie).

Kod:

root@OpenWrt:~# cat /etc/config/dnscrypt-proxy 
config dnscrypt-proxy ns1
    option address '127.0.0.1'
    option port '5353'
    option resolver 'cisco'

Kod:

root@OpenWrt:~# cat /etc/config/dhcp 

config dnsmasq
    option domainneeded '1'
    option boguspriv '1'
    option filterwin2k '0'
    option localise_queries '1'
    option rebind_protection '1'
    option rebind_localhost '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option nonegcache '0'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option nonwildcard '1'
    option localservice '1'
    option noresolv '1'
    list server '127.0.0.1#5353'
    list server '/pool.ntp.org/208.67.222.222'

...

Kod:

root@OpenWrt:~# dig debug.opendns.com txt

; <<>> DiG 9.11.9 <<>> debug.opendns.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24665
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debug.opendns.com.        IN    TXT

;; ANSWER SECTION:
debug.opendns.com.    0    IN    TXT    "server r3.wrw1"
debug.opendns.com.    0    IN    TXT    "flags 40020 0 70 180000000000000000007950800000000000000"
debug.opendns.com.    0    IN    TXT    "originid 0"
debug.opendns.com.    0    IN    TXT    "actype 0"
debug.opendns.com.    0    IN    TXT    "source xx.xx.xx.xx:xxxxx"
debug.opendns.com.    0    IN    TXT    "dnscrypt enabled (716D496B684B3766)"

;; Query time: 8 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 30 17:08:08 CEST 2019
;; MSG SIZE  rcvd: 271

nie zapomnij załączyć demona ntp i w rc.local wrzucić z opóźnieniem demona dnscryptproxy albo po prostu restarta (gryzie się z dnsmasqiem, znany i odwieczny problem dnscryptowego demona :)

to jest cały rocket science dnscrypta, prosto i bezpiecznie (przede wszystkim z dobrze zapiętymi dnsami lokalnie (arpon) uniemożliwia w większości przypadków atak MITM a na to cholerstwo jestem uczulony)

Ostatnio edytowany przez hi (2019-08-30 18:12:09)


"Są drogi, którymi nie należy podążać, armie, których nie należy atakować, fortece, których nie należy oblegać, terytoria, o które nie należy walczyć, zarządzenia, których nie należy wykonywać" Sun Tzu

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Nas ludzie lubią po prostu, a nie klikając w przyciski ;-)