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

rgl napisał(-a):
A 192.168.1.10 co powinien zrobić po otrzymaniu np zapytania DNS? Czy przypadkiem nie zapytać w internecie przez ten sam router?

@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

Jacekalex napisał(-a):
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ć.

@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

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

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

arecki napisał(-a):
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.

@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 … _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

morfik napisał(-a):
Zaorani z podstaw sieci? xD

Czemu użyłeś liczby mnogiej?

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

morfik napisał(-a):
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

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

bryn1u napisał(-a):
@Arecki
Oj tam, nikt Ci nic nie ujmuje, po prostu wyprzedzil odpowiedz :D I rowniez dziekuje za rozwiazanie problemu.

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

arecki napisał(-a):
morfik napisał(-a):
Zaorani z podstaw sieci? xD
Czemu użyłeś liczby mnogiej?

A no bo chłop pyta i nikt nie potrafi udzielić odpowiedzi na zdaje się bardzo podstawowe pytanie. xD

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.

rgl napisał(-a):

#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.

Jacekalex napisał(-a):

#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.

arecki napisał(-a):

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.

arecki napisał(-a):

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.

morfik napisał(-a):

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

bryn1u - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

morfik napisał(-a):

Kod:

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

arecki - Użytkownik

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

bryn1u napisał(-a):

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

morfik - Cenzor wirtualnego świata

Re: Prerouting Itables - dziwne zachowanie i blokada portow.

arecki napisał(-a):

morfik napisał(-a):

Stopka forum