Forum Debian Users Gang

bryn1u · 2016-12-17 11:43:45

Witam,

Cos dziwinie się zachowuje iptables, a dokladnie prerouting. Mam KVM, który jak widac jest znatowany. Jezeli nie ma regul prerouting tylko samo postrouting, dziala bez problemu. Problem pojawia się jak dodam tylko regulki prerouting. Jezeli przekieruje port 53 udp to nie moge pingowac domen, tylko samo ip, wszystko poziomu kvm guest. Po zablokowaniu 53 udp, wszystko dziala. To samo dzieje się z portem 80 tcp. Jezeli jest przekierowany to nie można się polaczyc z serverem http na kvm. O akutalizacji apt-get update już nie wspomne bo tez się wysypuje:

Kod:

root@proton:/home/proton# apt-get update
Błąd  http://ftp.fr.debian.org jessie InRelease
  
Błąd  http://ftp.fr.debian.org jessie-updates InRelease
  
Błąd  http://ftp.fr.debian.org jessie Release.gpg                          
  Nie udało się przetłumaczyć nazwy "ftp.fr.debian.org"
Błąd  http://ftp.fr.debian.org jessie-updates Release.gpg                  
  Nie udało się przetłumaczyć nazwy "ftp.fr.debian.org"
Błąd  http://security.debian.org jessie/updates InRelease                  
  
Błąd  http://security.debian.org jessie/updates Release.gpg                
  Nie udało się przetłumaczyć nazwy "security.debian.org"
Błąd  http://download.ispsystem.com base-jessie InRelease
  
Błąd  http://download.ispsystem.com 5.83-jessie InRelease
  
Błąd  http://download.ispsystem.com base-jessie Release.gpg
  Nie udało się przetłumaczyć nazwy "download.ispsystem.com"
Błąd  http://download.ispsystem.com 5.83-jessie Release.gpg
  Nie udało się przetłumaczyć nazwy "download.ispsystem.com"
Czytanie list pakietów... Gotowe
W: Nie udało się pobrać http://ftp.fr.debian.org/debian/dists/jessie/InRelease  

W: Nie udało się pobrać http://security.debian.org/dists/jessie/updates/InRelease  

W: Nie udało się pobrać http://ftp.fr.debian.org/debian/dists/jessie-updates/InRelease  

W: Nie udało się pobrać http://download.ispsystem.com/repo/debian/dists/base-jessie/InRelease  

W: Nie udało się pobrać http://download.ispsystem.com/repo/debian/dists/5.83-jessie/InRelease  

W: Nie udało się pobrać http://ftp.fr.debian.org/debian/dists/jessie/Release.gpg  Nie udało się przetłumaczyć nazwy "ftp.fr.debian.org"

W: Nie udało się pobrać http://ftp.fr.debian.org/debian/dists/jessie-updates/Release.gpg  Nie udało się przetłumaczyć nazwy "ftp.fr.debian.org"

W: Nie udało się pobrać http://security.debian.org/dists/jessie/updates/Release.gpg  Nie udało się przetłumaczyć nazwy "security.debian.org"

W: Nie udało się pobrać http://download.ispsystem.com/repo/debian/dists/base-jessie/Release.gpg  Nie udało się przetłumaczyć nazwy "download.ispsystem.com"

W: Nie udało się pobrać http://download.ispsystem.com/repo/debian/dists/5.83-jessie/Release.gpg  Nie udało się przetłumaczyć nazwy "download.ispsystem.com"

W: Nie udało się pobrać niektórych plików indeksu, zostały one zignorowane lub użyto ich starszej wersji.
root@proton:/home/proton#

Oczywiscie jeżeli zablokuje port 80 tcp to aktualizacja przebiega bez problemu.
Mam takie regulki jak ponizej. Wszystkie policy są accept. Oprocz tych ponizej nie mam zadnych.

Kod:

[root@mother ~]# iptables -S -t nat
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -p tcp -m tcp --dport 20 -j DNAT --to-destination 192.168.100.10:20
-A PREROUTING -p tcp -m tcp --dport 21 -j DNAT --to-destination 192.168.100.10:21
-A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.100.10:443
-A PREROUTING -p tcp -m tcp --dport 5555 -j DNAT --to-destination 192.168.100.10:5555
-A PREROUTING -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.100.10:53
-A PREROUTING -p tcp -m tcp --dport 1500 -j DNAT --to-destination 192.168.100.10:1500
-A PREROUTING -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.100.10:53
-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.100.10:80
-A POSTROUTING -s 192.168.100.0/24 -j MASQUERADE

Czy ktos wie czemu tak się dzieje ?
Z gory dziekuje,
Pozdrawiam,

Ostatnio edytowany przez bryn1u (2016-12-17 11:45:14)

Jacekalex · 2016-12-18 01:00:08

Pewnie FORWARD nie funguje, jak należy, albo ISP ma jakieś blokady,
wykrywające różne wartości TTL i wykonujące jakieś inne testy, jak u mnie.

Od dawna muszę z tego powodu wszystkie VM puszczać przez PROXY, bo nic innego nie pomaga.

Ostatnio edytowany przez Jacekalex (2016-12-18 01:02:38)

rgl · 2016-12-18 01:21:03

A 192.168.1.10 co powinien zrobić po otrzymaniu np zapytania DNS? Czy przypadkiem nie zapytać w internecie przez ten sam router?

bryn1u · 2016-12-18 14:00:36

[quote=rgl]A 192.168.1.10 co powinien zrobić po otrzymaniu np zapytania DNS? Czy przypadkiem nie zapytać w internecie przez ten sam router?[/quote]
@Jacek
Watpie, zeby w ovh tak robili tym bardziej, ze stoja tam prawie same hostingi na dedykach.

@rgl
Cos sugerujesz tylko nie bardzo wiem doczego zmierzasz. Kiedys mialem taka lub podobna konfiguracje i dzialalo. Jesli Ci chodzi o resolv.conf to jest taki sam na kvm guest co na hoscie.

Ostatnio edytowany przez bryn1u (2016-12-18 14:01:34)

Jacekalex · 2016-12-18 14:06:44

Jeżeli to hostingownia jak OVH, to spróbuj mostkowania interfejsów, a nie maskarady.
Musisz tylko dla VM-ki mieć publiczny adres IP, ale tam dają jakieś adresy failover, które możesz wykorzystać.

bryn1u · 2016-12-18 14:31:36

[quote=Jacekalex]Jeżeli to hostingownia jak OVH, to spróbuj mostkowania interfejsów, a nie maskarady.
Musisz tylko dla VM-ki mieć publiczny adres IP, ale tam dają jakieś adresy failover, które możesz wykorzystać.[/quote]
@Jacekalex

Czytam na forach podobne problemy i tez zwiazane dns'em. Wyglada jaby brakowalo jakich regulek.

Jacekalex · 2016-12-18 14:41:06

To wrzuć sobie na systemie głównym dnsmasq czy binda, niech pracuje jako lokalny DNS,
i sam gada z innymi serwerami, to zawsze pewniejsze rozwiązanie (i dużo szybsze),
niż kombinowanie, dlaczego pakiety UDP na port docelowy 53 z VM-ki się gdzieś gubią.

bryn1u · 2016-12-18 14:47:44

TCPdump pokazuje, jakby pakiety udp port 53 sie po prostu zapetlaly

arecki · 2016-12-18 15:28:30

Dodaj do obecnych regułek, których interfejsów mają dotyczyć (opcje -i, --in-interface i -o, --out-interface).

bryn1u · 2016-12-18 17:21:40

[quote=arecki]Dodaj do obecnych regułek, których interfejsów mają dotyczyć (opcje -i, --in-interface i -o, --out-interface).[/quote]
Niewiarygodne i to naprawde rozwiazalo problem. Moglbys mi teraz bardzo prosze to wytlumaczyc ? Nie rozumiem tego
Dlaczego przy takiej regule dziala:

Kod:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to 192.168.100.10:53

a przy takiej juz nie:

Kod:

iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 192.168.100.10:53

Przeciez przy prerouting ruch w tym przypadku leci na br0 a nie na eth0.

Ostatnio edytowany przez bryn1u (2016-12-18 17:22:14)

arecki · 2016-12-18 19:21:09

Ja tam nie widzę w #1 gdzie Ty masz tam br0.
Twój opis problemu w pierwszym poście jest dla mnie zbyt zagmatwany aby udzielić merytoryczną odpowiedź.
Opis problemu wskazał mi jedynie "na czuja", że pakiety zapętlają się gdzieś przez zbyt mało szczegółowe reguły filtrowania.
Jak chcesz szerszych wyjaśnień to opisz szczegółowo strukturę swojej sieci wtedy być może sam nawet znajdziesz miejsce "zapętlania" się pakietów.

bryn1u · 2016-12-18 20:13:23

[quote=arecki]Ja tam nie widzę w #1 gdzie Ty masz tam br0.
Twój opis problemu w pierwszym poście jest dla mnie zbyt zagmatwany aby udzielić merytoryczną odpowiedź.
Opis problemu wskazał mi jedynie "na czuja", że pakiety zapętlają się gdzieś przez zbyt mało szczegółowe reguły filtrowania.
Jak chcesz szerszych wyjaśnień to opisz szczegółowo strukturę swojej sieci wtedy być może sam nawet znajdziesz miejsce "zapętlania" się pakietów.[/quote]
@arecki

Ahh, widzisz bo napisalem dwa watki na forum dlatego w tym już nic nie wsponialem o br0. U mnie wyglada to tak:

Mam server dedykowany w OVH na ktorym jest postawiony i znatowany KVM Client.

Kod:

[root@ns3039183 ~]# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:25:90:55:fb:de brd ff:ff:ff:ff:ff:ff
    inet 91.121.78.120/24 brd 91.121.78.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:41d0:1:8378::/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::225:90ff:fe55:fbde/64 scope link 
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether fe:54:00:ca:b3:ef brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::8caa:8ff:feaa:1dbf/64 scope link 
       valid_lft forever preferred_lft forever
[root@ns3039183 ~]#

Stworzylem sobie jak widac wyzej mostek br0, dodalem mu statyczne ip. Nastepnie postawilem client kvm i tez dodalem mu statyczne ip, gdzie ip br0 jest brama dla client’a kvm.

Regulki:

Kod:

iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -o eth0 -j ACCEPT


iptables -t nat -A PREROUTING -p tcp --dport 21 -j DNAT --to 192.168.100.10:21
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.100.10:80
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to 192.168.100.10:443
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 5555 -j DNAT --to 192.168.100.10:5555
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 53 -j DNAT --to 192.168.100.10:53
iptables -t nat -A PREROUTING -p tcp --dport 1500 -j DNAT --to 192.168.100.10:1500
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to 192.168.100.10:53


iptables -t nat -A POSTROUTING -s 192.168.100.10 -o eth0 -j MASQUERADE

Stad moje pytanie dlaczego jak dodalem „-i” do reguly PREROUTING dla portu 53 udp, nagle z clienta kvm moge pingowac domeny i dziala. Jezeli usune „-i” automatycznie moge pingowac tylko po ip. To samo jest z portem 80 tcp.

Wedlug tego rysunku to z eth0 nie powinno miec duzo wspolnego. Skoro prerouting przerzuca najpierw ruch na br0 do ktorego jest podpiety client kvm. Albo ja czegos nie rozumiem
https://s24.postimg.org/scp8htdwj/firewall_iptables_przeplyw_pakietow.png

Ostatnio edytowany przez bryn1u (2016-12-18 20:51:42)

morfik · 2016-12-18 21:35:44

Zaorani z podstaw sieci? xD

Przykład adresacji:
Interfejs eth0 192.168.1.150
Interfejs br0 192.160.10.100/24
Interfejs maszyny wirtualnej vir0 192.168.10.10

Wysyłasz teraz zapytanie DNS z vir0 i jest tutaj ustawiany adres SRC 192.168.10.10 i DST 8.8.8.8 przykładowo. Adres DST jest spoza sieci 192.160.10.0/24, to idzie na default gateway, czyli adres IP interfejsu br0 (wirtualny interfejs hosta). Jako, że host ma dwa interfejsy, to by pakiety mogły między nimi zostać przesłane, wymagany jest NAT ale zanim do tego dojdzie, ten pakiet musi po opuszczeniu interfejsu vir0 wejść na interfejs br0. Jeśli teraz nie masz na zaporze żadnego "-i xxx" w NAT, to ten pakiet trafia ci w regułę to:192.168.10.10:53, czyli jest kierowany z powrotem do interfejsu z którego wyszedł, w efekcie nawet nie przechodzi przez br0, nie mówiąc już o opuszczeniu maszyny via eth0.

Tak wygląda wpis z tablicy conntrack'a:

Kod:

ipv4     2 udp      17 29 src=192.168.10.10 dst=8.8.8.8 sport=36571 dport=53 [UNREPLIED]
src=192.168.10.10 dst=192.168.10.10 sport=53 dport=36571 mark=512 zone=0 delta-time=0 use=2

Czyli wysłałeś zapytanie z interfejsu maszyny wirtualnej (192.168.10.10), do serwera DNS googla (8.8.8.8), pakiet został przepisany zgodnie z życzeniem to:192.168.10.10:53 i w efekcie masz pakiet o źródle i przeznaczeniu takim samym, a to chyba jest zrzucane z automatu xD

Ostatnio edytowany przez morfik (2016-12-18 21:37:38)

arecki · 2016-12-18 22:14:18

[quote=morfik]Zaorani z podstaw sieci? xD[/quote]
Czemu użyłeś liczby mnogiej?

bryn1u · 2016-12-18 22:20:25

[quote=morfik]Zaorani z podstaw sieci? xD

Przykład adresacji:
Interfejs eth0 192.168.1.150
Interfejs br0 192.160.10.100/24
Interfejs maszyny wirtualnej vir0 192.168.10.10

Wysyłasz teraz zapytanie DNS z vir0 i jest tutaj ustawiany adres SRC 192.168.10.10 i DST 8.8.8.8 przykładowo. Adres DST jest spoza sieci 192.160.10.0/24, to idzie na default gateway, czyli adres IP interfejsu br0 (wirtualny interfejs hosta). Jako, że host ma dwa interfejsy, to by pakiety mogły między nimi zostać przesłane, wymagany jest NAT ale zanim do tego dojdzie, ten pakiet musi po opuszczeniu interfejsu vir0 wejść na interfejs br0. Jeśli teraz nie masz na zaporze żadnego "-i xxx" w NAT, to ten pakiet trafia ci w regułę to:192.168.10.10:53, czyli jest kierowany z powrotem do interfejsu z którego wyszedł, w efekcie nawet nie przechodzi przez br0, nie mówiąc już o opuszczeniu maszyny via eth0.

Tak wygląda wpis z tablicy conntrack'a:

Kod:

ipv4     2 udp      17 29 src=192.168.10.10 dst=8.8.8.8 sport=36571 dport=53 [UNREPLIED]
src=192.168.10.10 dst=192.168.10.10 sport=53 dport=36571 mark=512 zone=0 delta-time=0 use=2

Czyli wysłałeś zapytanie z interfejsu maszyny wirtualnej (192.168.10.10), do serwera DNS googla (8.8.8.8), pakiet został przepisany zgodnie z życzeniem to:192.168.10.10:53 i w efekcie masz pakiet o źródle i przeznaczeniu takim samym, a to chyba jest zrzucane z automatu xD[/quote]
Podziekowac Ci dobry czlowieku. Tak dobrej odpowiedzi sie nie spodziewalem.

@Arecki
Oj tam, nikt Ci nic nie ujmuje, po prostu wyprzedzil odpowiedz :D I rowniez dziekuje za rozwiazanie problemu.

Pozdrawiam,

arecki · 2016-12-18 22:42:44

[quote=bryn1u]@Arecki
Oj tam, nikt Ci nic nie ujmuje, po prostu wyprzedzil odpowiedz :D I rowniez dziekuje za rozwiazanie problemu.[/quote]
Oj tam, oj tam, nie chodzi o to co kto mi ujmuje, ale o to co kto mi insynuuje.
I mimo, że mam Wielki szacunek (zapewne nie tylko ja) dla wiedzy Morfika, to nie uprawnia go do bezpodstawnych i buńczucznych opinii.
To tyle z mojej strony.

morfik · 2016-12-19 08:34:36

[quote=arecki][quote=morfik]Zaorani z podstaw sieci? xD[/quote]
Czemu użyłeś liczby mnogiej?[/quote]
A no bo chłop pyta i nikt nie potrafi udzielić odpowiedzi na zdaje się bardzo podstawowe pytanie. xD

Time (s)	Query
0.00010	SET CHARSET latin2
0.00004	SET NAMES latin2
0.00111	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.135.190.107' WHERE u.id=1
0.00072	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.135.190.107', 1732733322)
0.00055	SELECT * FROM punbb_online WHERE logged<1732733022
0.00103	DELETE FROM punbb_online WHERE ident='3.135.206.25'
0.00048	SELECT topic_id FROM punbb_posts WHERE id=307661
0.00006	SELECT id FROM punbb_posts WHERE topic_id=29241 ORDER BY posted
0.00057	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=29241 AND t.moved_to IS NULL
0.00005	SELECT search_for, replace_with FROM punbb_censoring
0.00108	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=29241 ORDER BY p.id LIMIT 0,25
0.00082	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=29241
Total query time: 0.00661 s

Forum Debian Users Gang

Ogłoszenie

#1 2016-12-17 11:43:45

bryn1u - Użytkownik

Prerouting Itables - dziwne zachowanie i blokada portow.

Kod:

Kod:

#2 2016-12-18 01:00:08

Jacekalex - Podobno człowiek...;)

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#3 2016-12-18 01:21:03

rgl - Nowy użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#4 2016-12-18 14:00:36

bryn1u - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#5 2016-12-18 14:06:44

Jacekalex - Podobno człowiek...;)

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#6 2016-12-18 14:31:36

bryn1u - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#7 2016-12-18 14:41:06

Jacekalex - Podobno człowiek...;)

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#8 2016-12-18 14:47:44

bryn1u - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#9 2016-12-18 15:28:30

arecki - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#10 2016-12-18 17:21:40

bryn1u - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

Kod:

Kod:

#11 2016-12-18 19:21:09

arecki - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#12 2016-12-18 20:13:23

bryn1u - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

Kod:

Kod:

#13 2016-12-18 21:35:44

morfik - Cenzor wirtualnego świata

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

Kod:

#14 2016-12-18 22:14:18

arecki - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#15 2016-12-18 22:20:25

bryn1u - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

Kod:

#16 2016-12-18 22:42:44

arecki - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

#17 2016-12-19 08:34:36

morfik - Cenzor wirtualnego świata

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

Stopka forum

Informacje debugowania