Gå til innhold

[Løst] Ubuntu: route trafikk mellom nettverksporter


Anbefalte innlegg

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:

post-78758-0-56466000-1354892285_thumb.jpg

 

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 av ventle
Lenke til kommentar
Videoannonse
Annonse

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

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 av ventle
Lenke til kommentar

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

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

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

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 av Zenit
Lenke til kommentar

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

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

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 konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...