WEB névfeloldás nem működi

Hálózatok általános

Sziasztok!
Mondanám, hogy kezdő vagyok, de ... majd kiderül.
Itthon ketyeg egy "otthoni" szerver már évek óta. Most éppen Debian 8.2 szolgálja a kéréseimet.
Alap kérések, nem kell sokra gondolni, torrent, web, ftp, ssh.
Történet:
Egy éve felraktam a 7.x verziót, akkor még roouter mögött volt a szerverem. Azóta megnőtt a net sebességem és a router már nem tudja kiszolgálni a sávszélességem. Feltettem a 7.8-at beállítottam rajt mindent. Kísérleteztem meg minden, szóval hazavágtam a rendszert. Feltettem a 8.2-t. Na itt kezdődött a gond.
Folyamatosan valami zabálta a procimat,(a net mindenhol tökéletesen működött) gondoltam rendszer le/fel. Amióta újrahúztam a rendszert valamiért nem működik a névfeloldás.
eth0 - ppp0 DigiNet
eth1 - belső lan hálózat, switchbe csatlakozik, pár gép, meg egy wifi.
Dnsmasq-t telepítettem, ossza az IP-ket.

/etc/network/if-pre-up.d/iptablest tartalma:
#!/bin/sh
# Masquerade
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

(Próbáltam sokféle beállítás, de eddig ennyi volt és működött)

/etc/dnsmasq tartalma:
interface=eth1
listen-address=127.0.0.1
domain=router.tsigu.hu
dhcp-range=192.168.0.100,192.168.0.120,12h

-meg pár fix IP kiosztás a gépeknek

/etc/sysctl.conf tartalma:
net.ipv4.ip_forward=1

/etc/resolv.conf tartalma:
nameserver 193.110.57.4
nameserver 193.110.56.8

Ezek a DIGI névszerverei.

Szóval a problémám, hogy nem jönnek be az weboldalak. De csak azóta, amióta legutoljára újraraktam a rendszert.
Érdekesség az egészben, hogy a telefonok, tv, számítógépek frissítik magukat, néhány weboldal (google.com, ker.elmuemaszenergiaszolgaltato.hu... ) bejön, viszont a speedtest.net, freemail.hu (ncore.nu ez a legnagyobb bajom) nem. Pingelni tudom az oldalakat:

root@Uj-szerver:~# ping freemail.hu
PING freemail.hu (195.228.245.1) 56(84) bytes of data.
64 bytes from freemail.hu (195.228.245.1): icmp_seq=1 ttl=247 time=3.81 ms
64 bytes from freemail.hu (195.228.245.1): icmp_seq=2 ttl=247 time=2.73 ms
64 bytes from freemail.hu (195.228.245.1): icmp_seq=3 ttl=247 time=2.68 ms
^X64 bytes from freemail.hu (195.228.245.1): icmp_seq=4 ttl=247 time=21.1 ms
^C
--- freemail.hu ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.687/7.605/21.185/7.853 ms

de a weboldalak nem jönnek be....

Örömmel veszek minden hozzászólást.
Köszönöm a segítséget!

  • 2304 megtekintés

( Mcsiv v | 2015. 12. 26., szo – 19:23 )

Szia,
A pppoe kapcsolat alapján, illetve a random bejön/nem jön be alapján az mtu-k környékén nézz szét (valószínüleg lanra a default 1500-as ttl van, miközben ez a digi irányába már nem fér be az extra pppoe keret miatt)

// Happy debugging, suckers
#define true (rand() > 10)

( Zs | 2015. 12. 26., szo – 19:24 )

Tipp: MTU probléma.
ppp konfigban az MTU-t vedd kisebbre.

Szia! Köszönöm! Utána néztem és egy oldal szerint a PPPOE kapcsolathoz az 1472 alatti beállítást ajánlják. Beállítottam 1440-re. Itt már elérem a goggle 8.8.8.8 névszerverét, viszont a DIGI-ét nem. Bármely beállítással sem érem el a DIGI-ét. Felhívtam az ügyfélszolgálatot és ott nincs gond a névfeloldással (hogy is lehetne, ha "kvázi" egy hálózaton ülnek vele).
Válaszolva iattilagy felvetésére is, nem tudok más szervert beállítani, mert akárhol adom meg pl: a google 8.8.8.8 névszerver útvonalat a DIGI kapcsolat létrejöttével azonnal felülíródik minden config fájl.
Egy jó parancs az MTU teszteléshez:

ping -Mdo -s 1440 8.8.8.8

Szia!

Köszönöm!!!

A Linuxos gépet "csak" gateway-nek használom, illetve ott fut a torrent, samba, ftp, web szerverek.
A mögötte lévő gépeken szoktam internetezni.

Megnéztem az általam próbált FORWARD-okat, de pont ezt nem találtam.
Számomra érhetetlen, ha eddig nem volt ilyen sor, akkor pont most miért kell (?), de most már megy.

Próbáltam már pár fórumban kérdezgetni, de valahogy ez a megoldás kimaradt.

Köszönöm, hogy ilyenkor még fenn voltál és segítettél!

Megyek, kivesézem a sor tartalmát egy szelet bejgli és egy pohár tej mellett...

A dnsmasq-on belül próbáltam a névszervert beállítani, de valamiért a ppp kapcsolat mindent felülír és csak azt használja. Már átírtam az /etc/ppp/ip-up.d ~/ip-down.d könyvtárban lévő fájlok resolv.conf fájlra vonatkozó tartalmát, de akkor is csak a DIGI saját névszerverét hajlandó használni.

Nem boldogulok az általad leírt FORWARD szabállyal. Már egy fél rúd bejglinél tartok. Annyit sikerült kiszednem a netből és a (általam használt) leírásból, hogy ez valamiféle MTU csökkentésként ténykedik...

Mára félreteszem a dolgot, és örülök, mint elsős a kisdobos nyakkendőnek...

Szia!
Kipróbáltam, így megtartja a resolv.conf a beírt google névszervereket, használja is.
Viszont, szerintem valahol máshol kell keresgetnem, nem a névfeloldásnál, mert a
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
sor nélkül nem működnek a linux utáni gépek internet elérése. :(
Majd este próbálkozom még, de most készülnöm kell a holnapi LAN partyra.

( Zs | 2015. 12. 26., szo – 23:24 )

Látom, megoldódott a probléma - ez jó. :-)
Azért leírom, hátha másnak jól jön: a forgalmat érdemes tcpdump alapokon is megnézni - szűrve az 53-as portra, hogy tényleg csak a DNS forgalom csomagjait lássuk. A problémát okozhatná tűzfal beállítás is, tehát ilyenkor érdemes megnézni, hogy:
- a kérés beesik a tűzfalra
- a kérést a tűzfal tovább tolja a net felé (és elköveti a NAT-olást is!)
- a válasz beesik a tűzfalra
- a választ a tűzfal visszaadja a kliensnek
Esetünkben az első két lépés jó lett volna - a válasz helyett viszont jött volna egy ICMP csomag, hogy tördelés szükséges. A fentebbi clamp-mss-to-pmtu pont ezt dolozza fel és tördeli újra a csomagot.

Egy dolog viszont nem tiszta... Ha van dnsmasq a tűzfalon, akkor arra ez a szabály - tudtommal - nincs hatással. Akkor ezt most hogy? Vagy a kliensen történt matatás a resolv.conf alatt és akkor nem a helyi dnsmasq volt szólongatva?

Ja igen, csakhogy a tcpdump parancs is meglegyen: :-)
tcpdump -n -i eth1 port 53

Szia!
Köszönöm, hogy foglalkozol a problémámmal.
A linux után már csak Win gépek vannak, mivel páromat nem tudtam átkonfigolni Linuxra.
Mára feladom a dolgot, de beillesztem a tcpdump válaszát.

root@Uj-szerver:~# tcpdump -n -i eth1 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
00:09:02.373865 IP 192.168.0.112.48092 > 192.168.0.1.53: 16474+ A? ns11.whois.co.kr. (34)
00:09:02.375762 IP 192.168.0.112.56005 > 192.168.0.1.53: 21404+ A? ns11.whois.co.kr. (34)
00:09:04.397887 IP 192.168.0.112.32997 > 192.168.0.1.53: 39310+ A? ns11.whois.co.kr. (34)
00:09:04.399585 IP 192.168.0.112.53615 > 192.168.0.1.53: 36471+ A? ns11.whois.co.kr. (34)
00:09:06.421911 IP 192.168.0.112.55162 > 192.168.0.1.53: 29963+ A? ns11.whois.co.kr. (34)
00:09:06.423607 IP 192.168.0.112.52989 > 192.168.0.1.53: 8344+ A? ns11.whois.co.kr. (34)
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
root@Uj-szerver:~#

Kellemes estét!

Ennek alapján az egyik belső gép - 192.168.0.112 - szeretné az ns11.whois.co.kr nevet feloldani, a kérést pedig a tűzfalnak - 192.168.0.1 - küldi. Válasz viszont nem megy.
Mivel ez a helyi dnsmasq-nak beeső kérés, érdemes megnézni, hogy a tűzfalon megy-e a névfeloldás, illetve azt is, hogy a belső hálóból a tűzfalra be van-e engedve az 53-as tcp+udp port?

( secretx v | 2015. 12. 27., v – 10:41 )

Szerintem az a gondod hogy a dnsmasq ahogy latom localhostra listenel.
Na ezt at kene irni a eth1 cimere szerintem.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Szia!

root@Uj-szerver:~# netstat -lpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:5000 0.0.0.0:* LISTEN 1359/rtorrent_user1
tcp 0 0 127.0.1.1:44331 0.0.0.0:* LISTEN 1465/java
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1096/smbd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 550/rpcbind
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 1072/perl
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 635/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 574/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 611/cupsd
tcp 0 0 0.0.0.0:55000 0.0.0.0:* LISTEN 1359/rtorrent_user1
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 909/exim4
tcp 0 0 0.0.0.0:52441 0.0.0.0:* LISTEN 559/rpc.statd
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1096/smbd
tcp 0 0 0.0.0.0:8895 0.0.0.0:* LISTEN 1465/java
tcp 0 0 0.0.0.0:23423 0.0.0.0:* LISTEN 1465/java
tcp 0 0 0.0.0.0:23424 0.0.0.0:* LISTEN 1465/java
tcp6 0 0 :::139 :::* LISTEN 1096/smbd
tcp6 0 0 :::111 :::* LISTEN 550/rpcbind
tcp6 0 0 :::80 :::* LISTEN 941/apache2
tcp6 0 0 :::53 :::* LISTEN 635/dnsmasq
tcp6 0 0 :::22 :::* LISTEN 574/sshd
tcp6 0 0 ::1:631 :::* LISTEN 611/cupsd
tcp6 0 0 ::1:25 :::* LISTEN 909/exim4
tcp6 0 0 :::445 :::* LISTEN 1096/smbd
tcp6 0 0 :::57885 :::* LISTEN 559/rpc.statd
udp 0 0 0.0.0.0:10000 0.0.0.0:* 1072/perl
udp 0 0 0.0.0.0:1900 0.0.0.0:* 1465/java
udp 0 0 0.0.0.0:38891 0.0.0.0:* 559/rpc.statd
udp 0 0 0.0.0.0:53 0.0.0.0:* 635/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 635/dnsmasq
udp 0 0 0.0.0.0:111 0.0.0.0:* 550/rpcbind
udp 0 0 0.0.0.0:631 0.0.0.0:* 612/cups-browsed
udp 0 0 192.168.0.255:137 0.0.0.0:* 1074/nmbd
udp 0 0 192.168.0.1:137 0.0.0.0:* 1074/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 1074/nmbd
udp 0 0 192.168.0.255:138 0.0.0.0:* 1074/nmbd
udp 0 0 192.168.0.1:138 0.0.0.0:* 1074/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 1074/nmbd
udp 0 0 0.0.0.0:716 0.0.0.0:* 550/rpcbind
udp 0 0 127.0.0.1:735 0.0.0.0:* 559/rpc.statd
udp 0 0 0.0.0.0:52962 0.0.0.0:* 586/avahi-daemon: r
udp 0 0 0.0.0.0:5353 0.0.0.0:* 586/avahi-daemon: r
udp6 0 0 :::35854 :::* 586/avahi-daemon: r
udp6 0 0 :::53 :::* 635/dnsmasq
udp6 0 0 :::40552 :::* 559/rpc.statd
udp6 0 0 :::111 :::* 550/rpcbind
udp6 0 0 :::716 :::* 550/rpcbind
udp6 0 0 :::5353 :::* 586/avahi-daemon: r
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 9552 1/init /run/systemd/private
unix 2 [ ACC ] SEQPACKET LISTENING 9574 1/init /run/udev/control
unix 2 [ ACC ] STREAM LISTENING 9577 1/init /run/systemd/journal/stdout
unix 2 [ ACC ] STREAM LISTENING 16524 1352/systemd /run/user/0/systemd/private
unix 2 [ ACC ] STREAM LISTENING 12714 1/init /var/run/avahi-daemon/socket
unix 2 [ ACC ] STREAM LISTENING 12717 1/init /var/run/dbus/system_bus_socket
unix 2 [ ACC ] STREAM LISTENING 12720 1/init /run/acpid.socket
unix 2 [ ACC ] STREAM LISTENING 12722 1/init /var/run/cups/cups.sock
unix 2 [ ACC ] STREAM LISTENING 12279 550/rpcbind /run/rpcbind.sock
unix 2 [ ACC ] STREAM LISTENING 15096 1074/nmbd /var/run/samba/nmbd/unexpected
root@Uj-szerver:~#

Nézem a többi bejegyzést...

tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 635/dnsmasq
tcp6 0 0 :::53 :::* LISTEN 635/dnsmasq
udp 0 0 0.0.0.0:53 0.0.0.0:* 635/dnsmasq
udp6 0 0 :::53 :::* 635/dnsmasq
Ezen sorok alapján a 635 pid-del futó dnsmasq bindel az 53-as portra mind tcp, mind udp alapokon, ráadásul teszi ezt mind IPv4, mind IPv6 alapokon.
Innen kezdve nem teljesen tiszta, hol is van a "bind = 127.0.0.1" és az "interface = eth1" opció... Mondjuk a cél IP-t még ellenőrizheti maga az alkalmazás is, de igazából nem tipikus - az interface ellenőrzés még kevésbé jellemző. Igazából értelmét sem látom, mert ha ezek a paraméterek megadhatóak, akkor érdemes valóban erre bindelni - de itt mintha nem így lenne!