Dial-up modemes internet kapcsolat megosztása SuSE-n

SUSE Linux

Modemen csatlakozom az internethez, a gateway-ről működik is minden; viszont sehogyan sem tudom a közvetlen (proxy nélküli) internet elérést megoldani a belső hálózat gépei számára:

(Gateway gép: dial-up modem; iif (eth0): 192.168.0.1
belső háló: 192.168.0.0/24, most konkrétan a 192.168.0.3 IP című géprő próbálkozom)

1. A Susefirewall2 doksi szerint beállítottam ezeket a gateway gépen (/etc/sysconfig/Susefirewall2 fájlban a SmallHomeNetwork esetére):

FW_DEV_EXT="modem0"
FW_DEV_INT="eth0"
FW_ROUTE="yes"
FW_MASQUERADE="yes"
FW_MASQ_NETS="192.168.0.0/24"

2. Csekkoltam, hogy a /proc/sys/net/ipv4/ip_forward fájlban "1" érték van.

3. Ellenőriztem a default route-ot a gateway-en:

Destination Gateway Genmask Flags MSS Window irtt Iface
line-81-1.dial. * 255.255.255.255 UH 0 0 0 modem0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default line-81-1.dial. 0.0.0.0 UG 0 0 0 modem0

4. és a default route-ot a belső hálózati gépen:

Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

Látszólag minden rendben, mégsem érek el semmit az interneten a belső hálózati gépről; onnan még a ppp kapcsolatnak is csak a local vége pingelhető (a gateway-ről viszont mindkettő).

Amikor belülről próbálok valamit pingelni az interneten, akkor néhány ilyen bejegyzés keletkezik a gateway-en /var/log/warn fájlban:

Sep 21 00:40:38 yoda kernel: SFW2-FWDint-DROP-DEFLT IN=eth0 OUT=modem0 SRC=192.168.0.3 DST=115.16.15.138 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=33539 SEQ=61953

de válasz sosem jön.

Mi a csoda lehet az oka, hogy a belső hálózatról nem elérhető az internet?

( j_szucs | 2006. 09. 22., p – 10:32 )

Bump

---
If you have money, use Windows!
However, if you also have a brain, use Linux!

Tudja a csoda. A Yast-ban mindent feloldottam a tűzfal beállításoknál, amire lehetőség volt. Sőt, próbaképpen még ki is kapcsoltam a tűzfalat, de úgy se ment. Mondjuk, ezzel kapcsolatban előre voltak kétségeim: ha kikapcsolom a tűzfalat, akkor a masquerading se megy? Hogy van ez? Azt nem a tűzfal csinálja?

Amúgy az iptables tábláiba utálnék belemászni, meg nem is hiszem, hogy SuSE-n valóban tűzfalszakértőnek kellene lenni ahhoz, hogy valaki egy vacak modemes internet kapcsolatot megosszon. Úgyhogy egyelőre csak a yastban, meg a Susefirewall2 konfigfájljai környékén kutakodtam.

Mennyivel egyszerűbb az élet FreeBSD-n...

---
If you have money, use Windows!
However, if you also have a brain, use Linux!

( Macskajancsi | 2006. 09. 22., p – 20:26 )

"FW_MASQ_NETS="192.168.0.0/24"
A Bcast címet kell beírni. Ha az alhálózati maszk 255.255.255.0, akkor ez az érték helyesen:
"FW_MASQ_NETS="192.168.0.255/24"

Nem ez volt a baj.
A helyzet az, hogy az ember csak kattogtat mint egy hülye a yast "Tűzfal" szekciójában, aztán kiderül, hogy amit megadott, abból semmi sem került be az iptables tábláiba.
Tök üres maradt a "nat" tábla, és az ICMP csomagok elfogadásán (meg a default DROP policy-n) kívül nem volt semmi a "FORWARD" chain-ben.

Megoldásként első körben beírtam pár sort az ip-up.local-ba: 

iptables=/usr/sbin/iptables
grep=/usr/bin/grep
if [[ -z $($iptables -t nat -L | $grep MASQUERADE) ]]; then
  $iptables -t nat -A POSTROUTING -o modem0 -j MASQUERADE
  $iptables -I FORWARD -i modem0 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
  $iptables -I FORWARD -i eth0 -o modem0 -j ACCEPT
fi

Így már megy; de nem tudom nem kellene-e rajta finomítani (IP-spoofing, stb...).

---
If you have money, use Windows!
However, if you also have a brain, use Linux!

Volna itt még egy probléma: a tapasztalataim szerint a fentiek csak akkor működnek, ha a gateway gépen a "kinternet" ikonnal tárcsázok be.

Márpedig ehelyett rendszerint a belső hálózati gépről ssh-n keresztül a wvdial-al szoktam betárcsázni. Ilyenkor pedig valamiért a belső hálótól közvetlenül továbbra sem elérhető az internet (pedig a gateway-en van internet kapcsolat, és az iptables -L szerint a tűzfal parancsok is a helyükön vannak.)

Talán valami routing probléma? A kinternet csinál valamit, amit sima egy wvdial parancs nem?

Hogyan lehetne távolról, az ssh-n keresztül pontosan ugyanúgy betárcsázni, mint ahogy a kinternet teszi?

---
If you have money, use Windows!
However, if you also have a brain, use Linux!

Mégsincs megoldva: a fenti smpppd még párszor működött (méghozzá kiválóan: a kliensről betárcsázva még a gateway desktopján is mutatta kinternet ikon, hogy éppen van-e kapcsolat; sőt bontani is lehetett konzolból).
Aztán egyszer csak: "Error: permission denied: cannot create pid file" hibával mindig elakad; még a gép újraindítása után is.

Mi a halál van már megint?

Persze az smpppd-ifcfg man-ja szerint nem célszerű őt közvetlenül használni, viszont más nincs: a helyette ott javasolt ifup-ot root-ként kell futtatni; a kinternet csak a gateway Desktop-járól működtethető; qinternet meg nincs.

Úgyhogy egyelőre, kb 8 óra időbefektetés után meg vagyok lőve...

P.S.
Gondolom azért nem tud .pid fájlt készíteni, mert a /var/run nem world-writable, vagy valami (ami eddig az volt) hirtelen nem suid-root többé. De mi?
Ha viszont jogosultsági probléma, akkor hogyhogy az asztali kinternet ikonnal továbbra is be tudok tárcsázni normál júzerként?

---
If you have money, use Windows!
However, if you also have a brain, use Linux!

Pusztán a történeti hűség kedvéért: a vége az lett, hogy a belső hálózati gépről a root account-ra ssh-zok be, és így a root user futtatja az smpppd-ifcfg parancsot.
Kiválóan működik: így még a gateway asztalán lévő kinternet ikon is mutatja, hogy van-e éppen kapcsolat.

---
Mondjon le!