[Megoldva] Net csere óta error

Linux-kezdő

Nemrég lecseréltük az adsl-t kábalnetre, kaptunk egy routert a kábel
végére, ami nyilván NAT-ol. Egyéb okok miatt nem akarjuk az eddigi
topológiát felborítani, szimplán átkonfiguráltuk a net felőli
interfészt pppoe-ről statikus ip-re, és a router-kábelmodem készüléken
DMZ-be raktuk. Azóta furcsán jelenségek vannak: van net-nincs net,
udp-n van , tcp-n nincs, hasonlók.
Hogyan lehet kideríteni a topológia megpiszkálása nélkül, hogy
konkrétan a dupla NAT miatt vannak-e ezek a problémák?
[ Nagyon kezdő, szóval nem piszkálódni :-) ]

( andrej_ v | 2011. 04. 14., cs – 09:37 )

Kábelneten DHCP-zni illene, akkor is ha fix ip-t ad a szolgáltató. A másik amire gondolni tudok, az MTU probléma, mert DSL-en 1452-vel szoktak hasítani és nem 1500-al.

( pischta | 2011. 04. 14., cs – 10:17 )

Előfizettetek fix ip-re? Ha igen, akkor is javasolnám a DHCP-t. Ez a belső hálózatot nem változtatná meg, pont a NAT miatt.

( ammmma | 2011. 04. 14., cs – 11:18 )

ha cisco epc3925, vagy a voip nélküli párja, akkor kapcsold ki benne a tűzfalat.
(nekem hibernálásból visszajövet rendszerint félig, vagy semennyire nem volt delejem a világ felé, és ez megoldotta..)

( pezo v | 2011. 04. 14., cs – 20:44 )

subscribe,

továbbá vagy én értem félre, vagy az eddigi hozzászólók: a router LAN felőli lábán DHCP működik, ha egy eszköz (pl. notebook, pc, stb.) kap ip-t, akkor az kijut a netre (ennek a stabilitásáróól jelenleg nincs információ). Ebben a LAN-ban van a TV, meg néhány más olyan eszköz, ami a net leváltása óta került a helyszínre. Ebben a LAN-ban van továbbá egy fix ip-s linux, ez a fix LANip van a routerben DMZ-re állítva. Ennek a linuxnak a "túloldalán" van egy hálózat, amiben a használni kívánt számítógépek és eszközök csücsülnek. Ennek a topológiának kell változatlannak lennie egyéb okokból.
Az itteni eszközökkel van tapasztalat, ezeken bizonytalankodik a netkapcsolat.
Ki kellene szűrni, hogy
- a dupla NAT miatt van-e (szolgáltató)
- a linux (debian) átállításakor vétett hibák miatt van-e (adminisztrátor)
- egyéb okból van-e (fantázia)

Nekem távoli segítséggel elfogytak az ötleteim. Ezért került a téma ide.

Igazából netem az van csak azt kellene vizsgálnom valamilyen módon, hogy esetlegesen van-e olyan pillanat amikor megszakad. Továbbá a net csere óta a net felől ssh-n keresztül megszakadok, lan felől nem, viszont nem egyértelmű, hogy az üres járat miatt vagy net szakadás miatt mert eddig mindig akkor szakadt meg amikor nem használtam. Tehát ez lehet válasz is. Az én gyanúm az hogy DNS problémák lesznek, legalábbis a syslog szerint pl. ilyeneket kapok:
Apr 14 21:02:51 Gate named[1354]: error (network unreachable) resolving 'ns17.nstld.net/AAAA/IN': 2001:503:a83e::2:31#53
Apr 14 21:02:51 Gate named[1354]: error (network unreachable) resolving 'ns17.nstld.net/A/IN': 2001:503:a83e::2:31#53
Apr 14 21:02:53 Gate named[1354]: success resolving 'ns1.nic.hu/AAAA' (in 'nic.hu'?) after disabling EDNS
Apr 14 21:02:55 Gate named[1354]: error (network unreachable) resolving 'ns3.nic.hu/AAAA/IN': 2001:678:4::c#53

"LoginGraceTime 120 - 120s üresjárás után kapcsolatot bont."
Úgy érted, hogy 2 perc alatt nem tudsz sikeresen bejelentkezni? A man sshd_config alapján láthatod, hogy a LoginGraceTime nem arra való, ami most neked kellene.

A problémát valószínűleg az okozza, hogy a routerben alacsonyra van állítva a NAT timeout. Ha ezen nem tudsz változtatni, akkor az azon keresztülmenő forgalmon kell.

A ServerAliveInterval (ClientAliveInterval), TCPKeepAlive nagy valószínűséggel megoldja a az SSH-val kapcsolatos kérdést. Általánosságban a TCP-forgalomra pedig TCP keepalive (/proc/sys/net/ipv4/tcp_keepalive_*).

"Úgy érted, hogy 2 perc alatt nem tudsz sikeresen bejelentkezni? A man sshd_config alapján láthatod, hogy a LoginGraceTime nem arra való, ami most neked kellene."

Igen igazad van, valóban nem ez kell nekem.
Viszont az ssh most annyira nem is zavar inkább a fentebb leírtakra kellene orvosság.

( pezo v | 2011. 04. 17., v – 11:22 )

update:

helyszini tenykedes eredmenye: a nevfeloldas eleg gagyin mukodik, ha a linuxra bizzuk. Ha kulso nevszervert adunk meg, vagy a kabelmodem-routert, akkor elfogadhatobb.
Topologia:

-koax--[kabelmodem-router]---elsoLAN---[linux]----masodikLAN

Tehat ha a masodiklan-ban levo eszkozok a linux-ot hasznaljak DNS szerverkent, akkor a fenti loguzenetek hemzsegnek a syslogban, es docogosen jonnek be a weblapok (lathatoan az oldalbetoltes elejen talalja nehezen a fonalat a bongeszo - tehat nevfeloldas).

Ha a kabelmodem-router a DNS, akkor egesz hasznalhatoan megy.
Mas hibat nem tapasztaltam.

Linuxon probaltuk:
- bind9 csomag letorlese beallitofajlokkal egyutt, majd visszarakasa
- EDNS csomagmeret 512-re, kesobb 500-ra allitasa a bind9 named.conf-jaban
A resolv.conf-ban a szolgaltato DNS szerverei vannak beallitva.

Ezek nem oldottak meg a problemat.

Egyeb otlet?

Nos a változás annyi lett, hogy a /etc/init.d/bind9 -> RESOLVCONF=no átírva yes-re eredményt hozott és most már gyors a böngészés. Tehát most kifogástalanul működik.
Nos a syslog még most is tele van hányva a következőkkel:
Apr 18 11:51:03 Gate named[1444]: error (network unreachable) resolving '0.europe.pool.ntp.org/A/IN': 2001:dc3::35#53
Apr 18 11:51:04 Gate named[1444]: error (network unreachable) resolving 'a.ntpns.org/A/IN': 2001:500:e::1#53
Apr 18 11:51:04 Gate named[1444]: error (network unreachable) resolving 'b.ntpns.org/AAAA/IN': 2001:500:f::1#53
Apr 18 11:51:04 Gate named[1444]: error (network unreachable) resolving 'a.ntpns.org/A/IN': 2001:500:f::1#53
Apr 18 11:51:05 Gate named[1444]: error (network unreachable) resolving 'c.ntpns.org/A/IN': 2001:500:94:1::20#53
Apr 18 11:51:05 Gate named[1444]: error (network unreachable) resolving 'f.ntpns.org/AAAA/IN': 2001:500:94:1::20#53
Apr 18 11:51:05 Gate named[1444]: error (network unreachable) resolving 'ns4.p20.dynect.net/A/IN': 2001:500:90::100#53
Apr 18 11:51:05 Gate named[1444]: error (network unreachable) resolving 'ns4.p20.dynect.net/A/IN': 2001:500:94::100#53

Utána olvasással, állítólag az IPv6 miatt keletkeznek ilyen log-ok. Hogy ebből mi lehet az igazság azt nem tudom. Ki lehet kényszeríteni, hogy a linux IPv4-et használjon úgy, hogy a /proc/sys/net/ipv6/bindv6only értékét 0-ra kell állítani. Nekem nem hozta meg a hatást a probléma továbbra is fenn áll.