internet elérés másik subnetből

Linux-kezdő

Sziasztok !

Adott egy linuxos gép. Két hálókártya van benne. Az egyik hálózati kártya -eth0- az internet felé megy, onnan dhcp-ről kapja az ip címet.
A másik kártya -eth1- megy a belső háló felé. Arra DHCP-t szolgáltat. Az eth1 ip címe: 10.0.0.2
A feladat az lenne, hogy a 10.0.0.0/24 subneten ülő gépek elérhessék fullban az internetet, korlátozás nélkül.
Amit eddig csináltam:

iptables -F
iptables -X
echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -A INPUT -j ACCEPT
iptables -A OUTPUT -j ACCEPT
iptables -A FORWARD -s 10.0.0.2 -p tcp -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp -j DNAT --to-destination 192.168.1.98
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

A 192.168.1.98 az eth0, ez megy ki az internet felé. Ez a cím változik.
A belső hálón ülő gépek mind windows gépek. És nem működik. Tűzfalat még sohasem csináltam, elnézést a bénázásért.

Segítségeteket előre is köszönöm!

  • 2164 megtekintés

( ncc1701 | 2015. 01. 27., k – 10:08 )

Ez a két sor tuti nem kell bele:

iptables -A FORWARD -s 10.0.0.2 -p tcp -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp -j DNAT --to-destination 192.168.1.98

Inkább:
iptables -A FORWARD -i eth1 -j ACCEPT

Esetleg még egyszer a konfiguráció:

iptables:

#A = "10.0.0.2" eth1
#KULSO = "192.168.1.98" eth0

iptables -F
iptables -X
echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -A INPUT -j ACCEPT
iptables -A OUTPUT -j ACCEPT
iptables -A FORWARD -j ACCEPT
iptables -A FORWARD -i eth1 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

dhcpd:

subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.100 10.0.0.200;
option domain-name-servers 84.2.46.1;
option routers 10.0.0.2;
}

Az nslookup kimegy, az IE nem tud.

Hülye kérdés, de kliens gépen "ipconfig /flushdns" (vagy restart) volt közben? Különben cache-elte a "nincs ip"-t a címhez és ha ugyanazt próbálgatod, nem fog elindulni! (nem egyszer futottam már bele újra és újra :/ )
Az nslookup közvetlen nyúl a DNS-hez, de a kliens progik akkor is a belső cache-t kérdezik.

Annak elvileg jónak kellene lennie imho. Max nézz valami wiresharkot / tcpdumpot, hogy mi nem stimmel, mert ez már inkább exporer csesznek hangzik (proxy nincs beállítva? Vagy nem kéne legyen beállítva?)

A dnsmasq az egy integrált dhcp és dns szerver (meg még PXE, de az most itt nem érdekes), kicsi, könnyű, gyorsan beállítható, és pont ez a célterülete. Főleg olyannak, aki nem nagyon ért hozzá egyszerűbb, mint a fenti rendes isc dhcpd, meg mondjuk egy bind.

De azért ezt illett volna meggugliznod.

Ahhoz, hogy a helyzet változzon, próbálj kicsit gondolkozni is. Egyrészt nyilván be is kell állítani, másrészt meg mint említettem, abból amit írtál:

- ping megy -> routing / tűzfal jó lesz
- nslookup megy -> dns beállítások jók.
- explorer nem egy -> azzal lesz a baj.

Erre most feltettél a jelenleg már beállított dhcpd helyett egy másikat, és gondolom nem irányítottad rá a dnst.

Ehelyett ha megnéznéd, hogy mikor az exporer próbálkozik, akkor mi történik, az segítene a probléma feltárásában. Vagy pl ha megnéznél egy másik böngészőt. Vagy egy másik protokolt.

Megtörtént a dnsmasq beállítása, nslookup továbbra is jól működik. Feltettem a Firefoxot, azzal sem megy. A wireshark számomra értelmezhetetlen adatot ad. A vírusvédelmet, és a helyi tűzfalat leállítottam.

Ha közvetlenül feldugom az internetre, akkor viszont működik.
Hol nézzem az IE próbálkozását?

A wireshark értelmezhetetlen adatában ;) Esetleg a tcpdumpot a linuxon futtatva annak az értelmezhetetlen adatában :)

Első körben azt kellene látni, hogy a browser által generált forgalomban sikerül e feloldani neki a címet. Szűrhetsz mondjuk a dns protokolra, ahol ha azt látod, hogy megy ki forgalom a gép címéről a beállított dns fele (ami ugye ha most dnsmasq van, akkor 10.0.0.2, vagy mi). Ha ki sem megy, akkor valalmi nagyon furi van. Ha kimegy, de nincs válasz, akkor azt kéne kideríteni, hogy miért. Ezt hasonlóan kellene nézni a linuxos dobozon, csak tcpdumppal.

Esetleg rövidíteni, és a dnsmasqban bekapcsolni valami debug logot, és nézni, hogy mi történik a queryvel. (Ez tán a legegyszerűbb most).

Ha a névfeloldás sikerült, akkor azt kell megnézni a wiresharkban/tcpdumpban, hogy mi történik azzal a kapcsolattal, amit ennek hatására nyit a gép. Itt a forráscím az, amit a gép kapott, a cél meg amit a dns adott vissza. Meg kell nézni, hogy megy-e ki forgalom, jön-e vissza válasz, ha nem, akkor az hol akad el? Már eleve ki se ment a gépről, ki se ment a linuxról, kiment, de semmi válasz nem jött, jött válasz, de elakadt a linuxon. Ilyesmik

150 vpn mellett vagy csak nagyon szerencsés vagy, vagy nem vetted észre ;) (Vagy nem tunnelálgatsz eleget mindenféle szart :) )

Mindazonáltal én sem nagyon gondolnám itt, csak azért jött elő, mert a külső címből, ami szintúgy 192.168 egy kissé gyanús, hogy dupla nat / és vagy egyéb gonoszkodás van az uplinken.

( Zs | 2015. 01. 27., k – 12:51 )

A Linux Boxon keresztül történő forgalmazás esetén nem elegendő, hogy a tűzfal szabályok engedélyezzék a forgalmat, az Internet felé maszkoljanak - de az is kell, hogy a kernel úgy gondolja, hogy ő router funkciókat is ellát és a hozzá beeső csomagokat ha a címzett más, továbbítsa is! Erre az
echo "1" > /proc/sys/net/ipv4/ip_forward
paranccsal lehet rábeszélni. Tartósabb megoldás is van, de az disztro függő, ezzel együtt ajánlott annak a használata.
A hiba keresésnél a tcpdump is jó barát tud lenni, mert a négy alapdolog azonnal megnézhető:
- a klienstől egyáltalán beesik-e a kérdéses csomag?
- a klienstől megjött csomag kimegy-e a net felé és megtörténik-e a maszkolás?
- megjön-e a válasz a kérésre a net felől?
- a net felől érkező választ beengedi-e a tűfal és továbbítja-e a kliens felé?
Ha mindenre igen a válasz, akkor működik a rendszer - ez az ideális állapot. :-)
Ha bárhol nem a válasz, akkor viszont már az elakadás helyének ismeretében elég jól behatárolható, hogy hol kell keresni a hibát.

( mauser1 v | 2015. 01. 27., k – 13:50 )

echo "1" > /proc/sys/net/ipv4/ip_dynaddr