siradlib Geschrieben 12. Dezember 2008 Teilen Geschrieben 12. Dezember 2008 Hallo, zunächst: Ich bin ziemlicher Anfänger, was iptables angeht, also lacht mich bitte nicht aus. ;-) ich habe zwei interne Netze konfiguriert- zwischen diesen Netzen macht ein Linux-Router (Debian) Masquerading: "innen" "außen" 192.168.3.1-eth1 --> NAT --> 192.168.0.50-eth0 --> Restnetz In diesem "äußeren Netz"/Restnetz (hinter eth0) sitzt z.B. auch ein Internetrouter. Das klappt soweit ganz gut, ich kann vom Netz 192.168.3.x aus ins Internet. Jetzt habe ich im Netz 192.168.0.0 in paar Drucker, auf die ich aus dem 192.168.3.0-Netz gerne über IPP (oder SMB) zugreifen möchte. Leider klappt z.B. schon ein simples "ping 192.168.0.48" nicht (wobei 192.168.0.48 so ein Drucker ist). Auch habe ich im internen Netz 192.168.3.0 einen Drucker, auf das ich gerne aus dem Netz 192.168.0.0 zugreifen möchte. (Falls es einfacher ist, kann ich den Drucker aus dem Netz 192.168.3.0 nach 192.168.0.0 umlegen.) Hat jemand eine Ahnung warum und gibt mir Tipps? Was mache ich falsch? Geht das so überhaupt? Sinn der ganzen Übung ist es, DHCP-Antworten aus dem äußeren Netz (192.168.0.x) nicht ins innere (192.168.3.x) kommen zu lassen- für das innere Netz soll nämlich ein eigener DHCP-Server verwendet werden und Geräte des Netzes 192.168.3.0 sollen keine Antworten von einem DHCP-Server im Netz 192.168.0.0 bekommen. Mein kleines iptables-Skript: # !/bin/sh iptables --flush iptables -t nat --flush iptables --delete-chain iptables -t nat --delete-chain # enable masquerading iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -j ACCEPT # block dhcp offers from the outside iptables -A INPUT -i eth0 -p udp --dport 67:68 --sport 67:68 -j DROP # FTP through NAT modprobe ip_conntrack_ftp iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT Interfaces: eth0 Link encap:Ethernet HWaddr 00:0C:29:EC:81:2D inet addr:192.168.0.50 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:feec:812d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:366904 errors:0 dropped:0 overruns:0 frame:0 TX packets:183703 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:340159697 (324.4 MiB) TX bytes:40015784 (38.1 MiB) Interrupt:169 Base address:0x1400 eth1 Link encap:Ethernet HWaddr 00:0C:29:EC:81:37 inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:feec:8137/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:92336 errors:0 dropped:0 overruns:0 frame:0 TX packets:245388 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14241616 (13.5 MiB) TX bytes:309458987 (295.1 MiB) Interrupt:177 Base address:0x1480 eth1:1 Link encap:Ethernet HWaddr 00:0C:29:EC:81:37 inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:177 Base address:0x1480 eth1:2 Link encap:Ethernet HWaddr 00:0C:29:EC:81:37 inet addr:192.168.0.55 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:177 Base address:0x1480 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:62 errors:0 dropped:0 overruns:0 frame:0 TX packets:62 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5803 (5.6 KiB) TX bytes:5803 (5.6 KiB) Route: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface bizhubc450.acad 192.168.0.55 255.255.255.255 UGH 0 0 0 eth1 192.168.3.0 * 255.255.255.0 U 0 0 0 eth1 192.168.2.0 * 255.255.255.0 U 0 0 0 eth1 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 default 192.168.0.9 0.0.0.0 UG 0 0 0 eth0 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Demigod Geschrieben 12. Dezember 2008 Teilen Geschrieben 12. Dezember 2008 Hi, vielleicht solltest du dir mal die generelle Funktionsweise eines NAT angucken. Es ist zwar schon was her und ich bin auch kein FiSi aber soweit ich weiss, ersetzt der NAT die interne Adresse bei dir 192.168.3.x mit seiner öffentlichen IP Adresse im Netz 192.168.0.x. Dadurch wirst du deinen Drucker nie mit der IP-Adresse 192.168.3.x erreichen sondern nur über deine öffentliche IP-Adresse. Diese anforderung musst du dann in deinem privaten Netz auf das jeweilige Gerät weiterleiten. Wenn das nicht stimmt, korrigiert mich bitte ;-) Gruß Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
siradlib Geschrieben 12. Dezember 2008 Autor Teilen Geschrieben 12. Dezember 2008 Soweit hatte ich die Funktionsweise von NAT bisher auch verstanden: Die IP-Adressen im inneren Netz werden durch die IP-Adresse des externen Interfaces des NAT-Routers und eines Ports (> 1024) ersetzt. Passiert nicht auf dem umgekehrten Weg (also von außen übers NAT nach innen) das Umgekehrte, d.h. die (externe) IP des NAT-Routers wird (mit Hilfe der Portnummer) auf der "inneren" Seite wieder in die ursprüngliche IP zurückgewandelt? Soweit sollte das ja alles kein Problem sein- das Problem tritt dann auf, wenn ein Gerät "außen" von sich aus einen Host hinter dem NAT kontaktieren möchte. Insofern vermute ich hier das Problem. Vermute ich richtig? Und wenn ja, was kann ich tun? Brauche ich vielleicht eine völlig andere Konstruktion? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.disk Geschrieben 12. Dezember 2008 Teilen Geschrieben 12. Dezember 2008 Wiese benutzt Du überhaupt NAT? Das geht doch auch alles schön sauber mit routing... NAT wegen DHCP brauchst Du nicht. DHCP funktioniert mit Broadcasts. Da Du zwei verschiedene Netze hast gelangt keine DHCP-Anfrage vom einem ins andere Netz. Falls das haben wölltest brauchst einen DHCP-Relay auf Deinem Router. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
siradlib Geschrieben 12. Dezember 2008 Autor Teilen Geschrieben 12. Dezember 2008 (bearbeitet) dr. disk, Danke für Deine Antwort- Du hast natürlich recht! :old Da NAT jetzt aber zu laufen scheint und weiter keine Probleme macht, buche ich es mal unter "Zusatznutzen". Mein Problem der nicht erreichbaren Hosts (vom Netz 192.168.3.0 ins Netz 192.168.0.0) habe ich ganz einfach durch eine zusätzliche Netzwerkkarte gelöst (unter VMWare Server einfach "dazugeklickt"). Jetzt scheint es zu funktionieren. Wenn jetzt der DHCP-Server nach dem Einschalten im Netz 192.168.0.0 wirklich nicht stört, bin ich glücklich. Ich habe jetzt folgende Karten im Router: eth0: Netz 192.168.0.0, Leitung zum Gateway (inkl. "störendem" DHCP-Server) eth1: Netz 192.168.3.0 und 192.168.168.2.0, interne Netze eth2: Netz 192.168.0.0, interne Drucker im Netz 192.168.0.0 eth1 und eth2 sitzen auf derselben physikalischen Karte, eth0 ist die Verbindung zum Gateway. Routing: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.3.0 * 255.255.255.0 U 0 0 0 eth1 192.168.2.0 * 255.255.255.0 U 0 0 0 eth1 [I]192.168.0.0 * 255.255.255.0 U 0 0 0 eth1[/I] 192.168.0.0 * 255.255.255.0 U 0 0 0 eth2 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 default 192.168.0.9 0.0.0.0 UG 0 0 0 eth0 Irgendwie hab ich das seeeehr seltsam gelöst, fällt mir gerade auf: Nach einem ifdown eth0 habe ich trotzdem noch eine Verbindung zum Gateway, was ja eigentlich nicht sein sollte. Oder? Andererseits sollte mir mein Router trotzdem die DHCP-Broadcasts blockieren, also wäre ich zufrieden. Ist vielleicht jemand so nett, eine bessere,elegantere Lösung zu skizzieren? Vielen Dank! Oh, noch eine Frage: Woher kommt denn in der Routingtabelle die kursive Zeile? Meine /etc/interfaces defeiniert nämlich keine IP im Netz 192.168.0.0 auf eth1- oder irre ich mich? # The loopback network interface auto lo iface lo inet loopback # aeusseres Interface - zum Internet auto eth0 iface eth0 inet static address 192.168.0.50 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.0.9 # inneres Interface - zum internen Netz auto eth1 iface eth1 inet static address 192.168.3.1 netmask 255.255.255.0 broadcast 192.168.3.255 network 192.168.3.0 auto eth1:1 iface eth1:1 inet static address 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255 network 192.168.2.0 auto eth2 iface eth2 inet static address 192.168.0.55 netmask 255.255.255.0 broadcast 192.168.0.255 network 192.168.0.0 Bearbeitet 12. Dezember 2008 von siradlib zusätzliche Frage ergänzt Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Demigod Geschrieben 12. Dezember 2008 Teilen Geschrieben 12. Dezember 2008 Versuch es doch erstmal theorethisch. Cisco Packet Tracer Dort findest du den Packet-Tracer. Der Vorteil an diesem Programm ist, dass es dir auch eventuelle Konfigurationsfehler anzeigt. Ausserdem kannst du sehen wo deine Packete genau stecken bleiben. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Maddog Geschrieben 20. Dezember 2008 Teilen Geschrieben 20. Dezember 2008 Was mir an deinem IPTables script auffällt ist das du keine Standart Rulez gesetzt hast Der code ist halt etwas Quick Hack..Man kann das natürlich alles besser aufbauen und z.B auch eigene Chains setzen. # !/bin/sh iptables -F iptables -t INPUT -P drop iptables -t FORWARD -P drop echo "1" > /proc/sys/net/ipv4/ip_forward iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT #Erlaube Traffic von "Innen" nach "außen aber nicht umgekehrt" iptables -A FORWARD -i eth1 -j ACCEPT # SSH zur Firewall freigeben iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i eth1 ----dport 22 -j ACCEPT #Drucker im "Internen Netz" freigeben #Kannst auch den Port für den Drucker Freigeben wenns z.B nur IPP ist dann halt # --dport 67:68 / Sonst gibst du halt alle Ports für den Drucker frei iptables -t FORWARD -i eth1 -d IPADRR_PRINTER Das ist Falsch::: # block dhcp offers from the outside iptables -A INPUT -i eth0 -p udp --dport 67:68 --sport 67:68 -j DROP die Chain Input ist NUR für Traffic der für den Firewall Host bestimmt ist! Der der DHCP Server "außen" ist müsste das wenn schon in die FORWARD Chain rein. NAT hab ich rausgelassen da du ja schließliche keine Pakete verändern willst Ansonsten hier haste einen guten Link Linux-Kompendium: Linux-Firewall mit IP-Tables ? Wikibooks, Sammlung freier Lehr-, Sach- und Fachbücher Gruß Maddog Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Cires87 Geschrieben 20. Januar 2009 Teilen Geschrieben 20. Januar 2009 Hallo, ich versuche gerade auch im Packet Tracer zwei Netze per NAT zu trennen. Allerdings mit sehr wenig Erfolg Wäre vielleicht jemand so nett, kurz das im Packet Tracer zu realisieren und irgendwo hochzuladen? Wäre mir wirklich eine große Hilfe wenn ich mir das mal anschauen könnte. Vielen Dank! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Crash2001 Geschrieben 20. Januar 2009 Teilen Geschrieben 20. Januar 2009 Das wäre aber eh NAT Overloading und nicht reines NAT. Beim reinen NAT gäbe es für jede interne Adresse eine externe. Schau mal hier. Ob NAT Overloading aber im Packet Tracer funktioniert, weiss ich nicht. [...]Da NAT jetzt aber zu laufen scheint und weiter keine Probleme macht, buche ich es mal unter "Zusatznutzen". [...]Einen wirklichen zusätzlichen Nutzen sehe ich da in keinster Weise - eher eine ziemliche Beschränkung. Der einzige Vorteil ist gleichzeitig auch der grösste Nachteil von PAT (aka NAT overloading) - nämlich dass kein Rechner (ohne Einrichtung einer Weiterleitung von einem Port aussen auf einen Port innen) von aussen direkt erreichbar ist. Das Problem hättest du nicht, wenn du einfach RIP (bzw RIPv2, falls C(L)IDR gewünscht ist) benutzen würdest. Ein Nachteil würde dir dadurch auch nicht entstehen. [edit] Oooh - ich seh grad, dass der gequotete Post oben ja schon wieder über einen Monat alt ist. [/edit] Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lupo49 Geschrieben 21. Januar 2009 Teilen Geschrieben 21. Januar 2009 Da NAT jetzt aber zu laufen scheint und weiter keine Probleme macht, buche ich es mal unter "Zusatznutzen". Was für ein Zusatznutzen entsteht, wenn ich zwei lokale Netze, anstatt über normales Routing via NAT verbinde? (Außer keine direkte Erreichbarkeit von Hosts und anderen Sachen via keine Broadcasts usw.) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.