Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Witam!
Wiem że szukaj i że google... ale szukałem i nie mogę sie doszukać odpowiedzi.
Problem wygląda następująco...
---net---eth0(publiczne IP)----serwer---eth1(wewnętrzne IP 192.168.0.1)-|---(wew. IP 192.168.0.2)serwer www
|
|------(wew. IP) 192.168.0.3 klient
czyli mam serwerek pelniący funcje routerka eth0 ma publiczne IP oraz eth1 z wew. IP w sieci wewnętrznej mam serwer www i przekierowanie portów z publicznego ip na 192.168.0.2 wszystko smiga jak jestem gdzieś w świecie. Gdy próbuje otworzyć stronke www podajac publiczny ip odwolujacy się do werwera www na komputerze wewnątrz sieci stronka się nie ładuje.
Czytałem wiele postów a rozwiązania nie znalazłem...
google mówią:
Jeśli wykonujesz przekazywanie portów (portforwarding) do tej samej sieci, musisz upewnić się że zarówno przyszłe pakiety jak i odpowiedzi na nie przejdą przez maszynę prowadzącą NAT (tak, by mogły być zmodyfikowane). Kod odpowiedzialny za NAT blokuje obecnie (od 2.4.0-test6) wychodzące przekierowane pakiety ICMP które produkowane są w momencie gdy pakiety po przejściu przez NAT wychodzą z tego samego interfejsu na którym dotarły, ale maszyna do której są skierowane nadal stara się odpowiedzieć bezpośrednio do klienta (który nie rozpozna odpowiedzi).
Klasycznym przykładem jest próba dostępu przez personel wewnętrzny do 'publicznego' serwera WWW, który tak naprawdę przesłonięty jest przez DNAT z publicznego adresu (1.2.3.4) na adres sieci wewnętrznej (192.168.1.1), tak jak poniżej:
# iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp --dport 80 -j DNAT --to 192.168.1.1
Jednym ze sposobów jest utrzymywanie wewnętrznego serwera DNS który zna prawdziwe (wewnętrzne) adresy IP publicznego serwera WWW i przekazuje wszystkie inne wywołania do zewnętrznego serwera DNS. Oznacza to że logowanie dostępu na twoim serwerze WWW wskaże adresy IP z sieci wewnętrznej poprawnie.
Innym sposobem jest zapewnienie, by maszyna prowadząca NAT mapowała również źródłowy adres IP na jej własny, dla połączeń tego typu, ogłupiając ten serwer i sprawiając by odpowiadał przez nią. W tym przykładzie, wykonujemy co następuje (zakładając że wewnętrzny adres IP komputera prowadzącego NAT to 192.168.1.250):
# iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 -p tcp --dport 80 -j SNAT --to 192.168.1.250
Ponieważ reguła PREROUTING jest uruchamiana pierwsza, pakiety będą od razu skierowane do wewnętrznego serwera WWW: możemy stwierdzić które wywołania pochodzą z sieci wewnętrznej sprawdzając źródłowe adresy IP.
z tego wniosek ze po zastosowaniu regul:
# iptables -t nat -A PREROUTING -d publicznyIP -p tcp --dport 80 -j DNAT --to 192.168.0.2
# iptables -t nat -A POSTROUTING -d 192.168.0.2 -s 192.168.0.0/24 -p tcp --dport 80 -j SNAT --to 192.168.0.1
co jednak nie skutkuje...
Ostatnio edytowany przez joebblack (2009-07-28 02:45:40)
Offline
ja w takich przypadkach robie przekierowanie przez xinetd lub apache proxy ...
Offline
Najprostszym rozwiązaniem IMHO bedzie przeniesienie serwera www do innej podsieci np 192.168.1.2, do eth1 przypisujesz dodatkowy adres ip np 192.168.1.1 i powinno dzialac bez SNAT.
Offline
ja wszystko rozumiem i sposoby powyzsze dopuszczam... mój problem jest dodatkowo skomplikowany ... otóż mam stara maszyne która kiedys była routerkiem ... i ona ten proces realizuje z pominieciem ww. sposobow i za diabła nie moge zwęszyć jak... xident to slepy trop, tablice routingu mam takie same ... konfiguracja iptables podobna.... ale nie pomaga...
Offline
przy przeniesieniu do innej podsieci ip tez moga byc problemy ... musialby byc vlan ...
dlaczego "xident to slepy trop"? ... jakby co przykladowy konfig masz - http://www.opcode.eu.org/sieci_komputerowe_uslugi/redirect-xinetd/
Offline
@bercik zaden vlan nie jest potrzebny. chodzi o to zeby serwer www i uzytkownicy z sieci lokalnej nie byli w jednej podsieci, wtedy pakiety bede przegodzic przez serwer ktory je zNATowal.
Ostatnio edytowany przez Libo (2009-07-29 14:56:15)
Offline
@Libo - wydaje mi sie ze bedzie problem z arp'em ... przynajmniej tak kiedys mialem przy dwoch sieciach ip w jednym LANie (http://forum.dug.net.pl/viewtopic.php?id=6398), ale moze NATowanie temu zapobiegnie
Offline
Strony: 1
Time (s) | Query |
---|---|
0.00012 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00137 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.133.133.39' WHERE u.id=1 |
0.00117 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.133.133.39', 1732463843) |
0.00041 | SELECT * FROM punbb_online WHERE logged<1732463543 |
0.00044 | SELECT topic_id FROM punbb_posts WHERE id=124069 |
0.00004 | SELECT id FROM punbb_posts WHERE topic_id=14677 ORDER BY posted |
0.00066 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=14677 AND t.moved_to IS NULL |
0.00007 | SELECT search_for, replace_with FROM punbb_censoring |
0.00178 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=14677 ORDER BY p.id LIMIT 0,25 |
0.00109 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=14677 |
Total query time: 0.00719 s |