ventle Skrevet 7. desember 2012 Del Skrevet 7. desember 2012 (endret) Kort forklart: - Jeg har en server, med fem nettverksporter, p4p1, eth0, eth1, eth2 og eth3 - En pc, windowsbasert, koblet til eth0 - En RAID-kontroller/NAS, koblet til eth3 - p4p1 er koblet til internett - pc'en er koblet til internett vha iptables-regler - pc'en skal også kunne koble seg til RAID-kontrolleren, her sliter jeg litt og trenger hjelp/tips. Skjematisk fremstilt: PC'en har statisk IP 192.168.0.100, nettmaske 255.255.255.0, gateway 192.168.0.1 RAID-kontrolleren har statisk IP 192.168.3.10, nettmaske 255.255.255.0, gateway 192.168.3.1 Oppsett for nettverksportene på serveren kan oppsummeres med innholdet i /etc/network/interfaces: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto p4p1 iface p4p1 inet dhcp auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 auto eth1 iface eth1 inet static address 192.168.1.1 netmask 255.255.255.0 auto eth2 iface eth2 inet static address 192.168.2.1 netmask 255.255.255.0 auto eth3 iface eth3 inet static address 192.168.3.1 netmask 255.255.255.0 IPtables oppsett: Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 2462 1085K ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 5 260 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh 2 120 ACCEPT icmp -- any any 192.168.0.0/16 anywhere icmp echo-request state NEW,RELATED,ESTABLISHED 1 52 ACCEPT tcp -- any any 192.168.0.0/16 anywhere state NEW,RELATED,ESTABLISHED 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:openvpn 0 0 ACCEPT all -- tun+ any anywhere anywhere 643 170K DROP all -- any any anywhere anywhere Chain FORWARD (policy ACCEPT 11 packets, 520 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- eth2 p4p1 192.168.2.0/24 anywhere ctstate NEW 17103 9406K ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 1054 58838 ACCEPT all -- eth0 p4p1 192.168.0.0/24 anywhere ctstate NEW 0 0 ACCEPT all -- eth1 p4p1 192.168.1.0/24 anywhere ctstate NEW 0 0 ACCEPT tcp -- any eth3 anywhere 192.168.3.0/24 state NEW,RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT 501 packets, 1430K bytes) pkts bytes target prot opt in out source destination Routing tabell på serveren Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default [fra ISP] 0.0.0.0 UG 0 0 0 p4p1 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0 46.9.13.0 * 255.255.255.0 U 0 0 0 p4p1 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth1 192.168.2.0 * 255.255.255.0 U 0 0 0 eth2 192.168.3.0 * 255.255.255.0 U 0 0 0 eth3 Og til sist er IP-forwarding naturligvis aktivert. Fra serveren får jeg til å pinge RAID-kontrolleren, men ikke fra PC'en, det er vel noe lurt oppsett ett eller annet sted jeg må endre, men hva? Endret 7. desember 2012 av ventle Lenke til kommentar
ChrisCo Skrevet 7. desember 2012 Del Skrevet 7. desember 2012 Den servern din, er det også en router? Den mest opplagte grunnen jeg kan se i farta, er at PC'en din og RAID-kontrolleren er på forskjellige subnett (192.168.0.0/24 og 192.168.3.0/24). Da må trafikken kjøres gjennom en router for at du skal få kommunikasjon på tvers av subnett. Beste alternativet er å sette alle i samme subnett, f.eks 192.168.0.x Et annet alternativ er å endre subnettmasken til f.eks /21 (255.255.248.0). Da er alle IP adresser fra 192.168.0.1 - 192.168.7.254 i samme subnett og problemet skal være løst. Og du har også mye rom for utvidelse og et hav av ledige host-adresser (2046). Jeg ville heller ha delt opp i mindre subnett (/24 - /29) hvis du ikke vil ha alle i samme subnett. Da kan du fremdeles bruke 192.168.0.0 nettet til alle enheter, uten at de er i samme subnett.... Christian Lenke til kommentar
ventle Skrevet 7. desember 2012 Forfatter Del Skrevet 7. desember 2012 (endret) Serveren er også router ja, reglene i iptables skal ta seg av den jobben. Har endret litt på disse siden de sto i feil rekkefølge og det ikke var definert noen regel for pakker som kom fra .3.0-nettet til .0.0-nettet: Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 7 488 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh 0 0 ACCEPT icmp -- any any 192.168.0.0/16 anywhere icmp echo-request state NEW,RELATED,ESTABLISHED 0 0 ACCEPT tcp -- any any 192.168.0.0/16 anywhere state NEW,RELATED,ESTABLISHED 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:openvpn 0 0 ACCEPT all -- tun+ any anywhere anywhere 0 0 DROP all -- any any anywhere anywhere Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- eth2 p4p1 192.168.2.0/24 anywhere ctstate NEW 0 0 ACCEPT all -- any eth3 anywhere 192.168.3.0/24 ctstate NEW,RELATED,ESTABLISHED 0 0 ACCEPT all -- any eth0 anywhere 192.168.0.0/24 ctstate NEW,RELATED,ESTABLISHED 0 0 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- eth0 p4p1 192.168.0.0/24 anywhere ctstate NEW 0 0 ACCEPT all -- eth1 p4p1 192.168.1.0/24 anywhere ctstate NEW Chain OUTPUT (policy ACCEPT 5 packets, 652 bytes) pkts bytes target prot opt in out source destination Og her er forøvrig reglene i NAT-tabellen, de glemte jeg i forrige innlegg Chain PREROUTING (policy ACCEPT 189 packets, 19218 bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 7 packets, 490 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 166 9664 MASQUERADE all -- any p4p1 anywhere anywhere Har satt videre nettmaske (.248.0) på pc og RAID-kontroller, det er vel i praksis det samme som å sette dem på samme subnet? Får feilmeldingen "Destination host unreachable" når jeg prøver å pinge RAID-kontrolleren. Prøvde å aktivere Masquerade for pakker som skal ut på eth3 i NAT-tabellen, uten at det gjorde noen forskjell. Endret 7. desember 2012 av ventle Lenke til kommentar
ChrisCo Skrevet 8. desember 2012 Del Skrevet 8. desember 2012 Du bruker jo fremdeles /24 maska ser jeg i tabellene.. Siden du har endret til /21 i adressene, så må du også endre i /21 i tabellene for at det skal bli riktig.. Christian Lenke til kommentar
ventle Skrevet 8. desember 2012 Forfatter Del Skrevet 8. desember 2012 Fungerer fortsatt ikke. Sikker på at jeg kan/skal ha videre nettmaske sett fra serverens side? Virker ikke som om serveren er særlig glad i å ha flere nettverksporter på samme subnet, og at den ikke ser forskjell på de to reglene hvis jeg setter nettmaske til /21 (begge vises som 192.168.0.0/21)... Lenke til kommentar
Penguin Skrevet 8. desember 2012 Del Skrevet 8. desember 2012 Om jeg forstår oppsettet ditt riktig (etter brorparten av en flaske rødvin), så trenger du kun iptables for å NATte trafikken din ut på internett. For ruting mellom de interne nettene dine (som alle er /24) trenger du kun: echo 1 > /proc/sys/net/ipv4/ip_forward pluss at alle hoster peker på ubuntuboksens interfaceadresse på respektive nett som sin gw. For å NATte trafikk fra alle nettene dine ut: iptables --table nat --append POSTROUTING --out-interface p4p1 -j MASQUERADE iptables --append FORWARD --in-interface eth0 -j ACCEPT iptables --append FORWARD --in-interface eth1 -j ACCEPT iptables --append FORWARD --in-interface eth2 -j ACCEPT Dette var i alle fall gyldig syntax engang.... Lenke til kommentar
Penguin Skrevet 8. desember 2012 Del Skrevet 8. desember 2012 Om jeg forstår oppsettet ditt riktig (etter brorparten av en flaske rødvin), så trenger du kun iptables for å NATte trafikken din ut på internett. For ruting mellom de interne nettene dine (som alle er /24) trenger du kun: echo 1 > /proc/sys/net/ipv4/ip_forward pluss at alle hoster peker på ubuntuboksens interfaceadresse på respektive nett som sin gw. For å NATte trafikk fra alle nettene dine ut: iptables --table nat --append POSTROUTING --out-interface p4p1 -j MASQUERADE iptables --append FORWARD --in-interface eth0 -j ACCEPT iptables --append FORWARD --in-interface eth1 -j ACCEPT iptables --append FORWARD --in-interface eth2 -j ACCEPT Dette var i alle fall gyldig syntax engang.... Og by the way. All hostene dine skal ha samme maske som serverens interfaceadresser (255.255.255.0) om intensjonen er at ubuntuboksen skal være ruter. Noe er skrudd med postingen til forum fra ff 15.0.1 Lenke til kommentar
Zenit Skrevet 8. desember 2012 Del Skrevet 8. desember 2012 (endret) Du skal ikke trenge å endre på subnet-oppsettet hvis IP-forwarding er riktig aktivert. Her er ikke netfilter (iptables) involvert så fremt du ikke begynner å sette regler med filtrering og NAT. Ruting-tabellen virker ok og FORWARDING har policy ACCEPT, som er et bra utgangspunkt for videre testing. NAT-regelen din ser riktig ut og er bare på det eksterne interfacet. Derfor sjekker du først output av: cat /proc/sys/net/ipv4/ip_forward Du bør også dobbeltsjekke at gw og netmask er satt riktig på begge maskiner. Hvis du tester med ping, pass på at windows sin brannmur ikke blokkerer dette, for det kan hende at pakkene kommer frem selv om du ikke får svar. Generelt ønsker man først å teste uten aktive brannmurregler langs hele forbindelsen. For videre feilsøking kan du gjøre noe sånt: På ubuntu-server: sudo tcpdump -ni eth0 icmp På RAID-controlleren sender du så en ping-pakke: ping -c1 -w1 192.168.0.100 Første output av tcpdump kan du poste her. Det skal kun være et par linjer. Om du ønsker at begge maskinene skal være på samme subnet på eth0 og eth3, bør du sette opp en bridge. Det er en mulighet som forenkler oppsettet ditt. Å ha samme nettverk på flere porter blir ellers bare kluss. Edit: skrivefeil og presisering Endret 9. desember 2012 av Zenit Lenke til kommentar
ventle Skrevet 9. desember 2012 Forfatter Del Skrevet 9. desember 2012 Jess, tilbake til strammere nettmasker (/24) over hele fjøla, dvs slik jeg hadde det fra start av, og fjerning av de forward-reglene jeg hadde lagt inn i iptables gjorde susen. Takk for hjelpen Bridging ser dog ut som ett besnærende tema, særlig ettersom jeg også holder på å sette opp OpenVPN i bridge-mode, så det skal jeg dykke ned i i mårra... Lenke til kommentar
ventle Skrevet 11. desember 2012 Forfatter Del Skrevet 11. desember 2012 Bridging er oppe og går og var forsåvidt lekende lett å sette opp. PC, server og RAID-kontroller er på samme subnet og snakker fint sammen. Har dog en liten hikke i forhold til OpenVPN. har satt opp OpenVPN i bridge-mode og prøvd å koble meg til utenfra med to forskjellige pc'er, en med Windows (XP) og en med Linux (Lubuntu 11.10). Linux-maskinen er forøvrig en virtuell pc i VMWare om det har noen betydning. Fra Windows-maskinen virker alt som det skal, og jeg får tilgang til både serveren, og pc'en og RAID-kontrolleren. OpenVPN-klienten har fått IP-adresse på samme subnet som de andre på det private nettet (192.168.0.0/24). Fra Linux-maskinen får jeg tilgang til serveren, men tilsynelatende ikke pc'en og RAID-kontrolleren (ping resulterer i Destination host unreachable), men de blir likevel listet opp når jeg kjører nmap -sP 192.168.0.0/24. Er det noe jeg må gjøre i oppsettet på Linux-klienten? Det har automatisk blitt lagt til en route til 192.168.0.0/24 på VPN-devicen (tap0). Lenke til kommentar
ventle Skrevet 11. desember 2012 Forfatter Del Skrevet 11. desember 2012 Glem det, ser ut til at det er nettverksoppsettet på den virtuelle maskinen som har blitt fubar. Mulig det ikke var en kjempegod ide å bare kopiere en virtuell maskin fra en pc til en annen... Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå