Onderwerp: ip routen locatie A naar B

Oorspronkelijk geplaatst door visser

Veel lezen & proberen ;-) En maak een tekeningetje voor je zelf.

Begin met één IP adres wat je van en via B naar A wilt routeren.
Maak op de A server een extra loopback (lo1) met dit IP adres.
(hier doe ik de aanname dat je die ip adressen direct op de tunnel-server gaat gebruiken, niet nog op een andere machine van locatie A)

Op de B server zet je een statische route voor dit IP adres door het tunnel interface.
Is de instelling van je provider zodanig dat die verwacht dat alle adressen van de B server "op het ethernet" zitten ?
Zo ja, dan zou het kunnen dat je ook proxy arp aan moet zetten op het ethernet interface van die server.

Nu je zo ver bent, kan het nog niet werken, maar kun je al iets testen.
Verkeer van "buiten" moet nu naar server B , en dan via de tunnel naar server A gaan.
Probeer dat, en kijk met tcpdump (of tethereal) of dat tot zover lukt.

Wat nog niet goed gaat, is dat antwoord verkeer van dat IP adres op server A niet via de tunnel terug gaat.

Dat moet je nog op server A oplossen.

Je kunt dat, zo te zien, puur met ip route oplossen.
http://linux-ip.net/html/routing-rpdb.html
je maakt een extra routing table aan, waarbij de default route van deze table naar de tunnel wijst.
En je zorgt dat verkeer afkomstig van het lo1 interface (of op basis van source ip) deze niet-default route table gebruikt.

Je hebt, denk ik, totaal geen NAT nodig in dit verhaal. Alleen tegen de tijd dat de hele zaak zover werkt moet je kijken of ICMP berichten van "server B" niet het (private) IP adres van het tunnel interface gebruiken. (server B zal nl. icmp fragmentation needed gaan terugsturen bij pakketten groter dan de tunnel MTU).

Verder moet je natuurlijk in je iptables voldoende open hebben staan om dit te laten werken.
De tunnel zelf is aan de buitenkant alleen maar GRE (protocol 47).

In tegenstelling tot de tunnel setup heb ik niet meteen een cut&paste klaar voorbeeldje van de multiple-route table setup.
Genoeg "min of meer vergelijkbare" dingen om te weten dat dit de richting is, maar het lees,google, test en probeer werk voor dit specifieke scenario moet je hier zelf doen.
Wat je wilt bereiken is dat verkeer op server A van- en naar IP adressen op server A die van "locatie B" afkomstig zijn, via de GRE tunnel naar locatie B gestuurd wordt, en niet "direct" naar buiten.
Als je verkeer met adressen van locatie B op locatie A 'direct' naar buiten stuurt is dat feitelijk IP spoofing, en een goede ISP zal dat blokkeren.

Met de loopback moet ik hierbij nog een speciefieke netmask doen of gewoon 255.0.0.0 laten?

Oorspronkelijk geplaatst door daiman

Met de loopback moet ik hierbij nog een speciefieke netmask doen of gewoon 255.0.0.0 laten?

Wat je echt vooral moet doen is tijd, en een beetje geld, investeren in meer kennis.
Dit is toch je baan, of is het alleen een doorgeschoten hobby ?
Koop bijvoorbeeld Computer Networks van Andrew Tanenbaum, TCP/IP Illustrated vol 1 van W. Richard Stevens, of 'Interconnections 2nd edition' van Radia Perlman.
Of liefst allemaal , en lees ze.

Het netmask bepaalt welke (andere) adressen allemaal op dat interface zitten.
Stel, jouw IP adres wat je op locatie A op loopback1 zet is 30.1.2.3 .
Met een netmask 255.0.0.0 zal de server op locatie A *Alle* adressen met 30.x.x.x als lokaal op dat loopback interface zien.
En die adressen dus niet (meer) elders kunnen bereiken, want hij heeft ze zelf al.

Op een 'gewoon' loopback interface zit 127.0.0.1 met netmask 255.0.0.0 omdat ALLE 127.x.x.x adressen 'loopback' (als in 'deze computer') zijn.

Maar je kunt dus ook een loopback x interface maken met een 'echt' ip adres, wat dan niet gekoppeld is aan de ene of de andere fysieke ethernet kaart, maar gewoon van 'deze computer' is en bereikt kan worden als naburige hosts een route voor dat adres hebben naar die computer. (en die route heeft dan een IP adres wat wel op een fysiek interface zit als next hop).

Als je precies één adres op loopback1 zet, dan heeft dat het netmask 255.255.255.255 .
Ik denk dat ik uberhaupt elk adres wat je op deze manier naar de andere server brengt een eigen loopback zou geven; Maar je kunt adressen die 'goed vallen' met een wat ruimer netmask bij elkaar hebben op een interface.

Oorspronkelijk geplaatst door visser

Wat je echt vooral moet doen is tijd, en een beetje geld, investeren in meer kennis.
Dit is toch je baan, of is het alleen een doorgeschoten hobby ?
Koop bijvoorbeeld Computer Networks van Andrew Tanenbaum, TCP/IP Illustrated vol 1 van W. Richard Stevens, of 'Interconnections 2nd edition' van Radia Perlman.
Of liefst allemaal , en lees ze.

Het netmask bepaalt welke (andere) adressen allemaal op dat interface zitten.
Stel, jouw IP adres wat je op locatie A op loopback1 zet is 30.1.2.3 .
Met een netmask 255.0.0.0 zal de server op locatie A *Alle* adressen met 30.x.x.x als lokaal op dat loopback interface zien.
En die adressen dus niet (meer) elders kunnen bereiken, want hij heeft ze zelf al.

Op een 'gewoon' loopback interface zit 127.0.0.1 met netmask 255.0.0.0 omdat ALLE 127.x.x.x adressen 'loopback' (als in 'deze computer') zijn.

Maar je kunt dus ook een loopback x interface maken met een 'echt' ip adres, wat dan niet gekoppeld is aan de ene of de andere fysieke ethernet kaart, maar gewoon van 'deze computer' is en bereikt kan worden als naburige hosts een route voor dat adres hebben naar die computer. (en die route heeft dan een IP adres wat wel op een fysiek interface zit als next hop).

Als je precies één adres op loopback1 zet, dan heeft dat het netmask 255.255.255.255 .
Ik denk dat ik uberhaupt elk adres wat je op deze manier naar de andere server brengt een eigen loopback zou geven; Maar je kunt adressen die 'goed vallen' met een wat ruimer netmask bij elkaar hebben op een interface.

Dit is gewoon een beetje als hobby,
Zou je hiervoor misschien iets kant en klaars kunnen maken dus eventueel welke commands ik moet doen.
Hiervoor wil ik best wel voor betalen indien nodig.

Oorspronkelijk geplaatst door daiman

Dit is gewoon een beetje als hobby,
Zou je hiervoor misschien iets kant en klaars kunnen maken dus eventueel welke commands ik moet doen.
Hiervoor wil ik best wel voor betalen indien nodig.

Hm, het is een beetje pech voor je, maar ik post hier op WHT ook uit (een combinatie) van hobbyisme, beetje verveling, afleiding en misschien wel wat publiek nut.
Een volledig uitgewerkt en getest voorbeeld kost me wat meer tijd dan ik bereid ben te besteden ; _zo_ hard verveel ik me ook weer niet, en mijn day job is druk genoeg (en comfortabel genoeg qua salaris) dat ik hier even geen advies klusje zoek.

Nu ja, ook voor een toch wel serieuze hobby (min. twee servers , 100+ ip adressen, dat is meer dan een 'ik en mijn broertje en onze hond website') kan het geen kwaad om je als beheerder wat in te werken in de techniek.

pak dus mijn posting van 29/12 , zet
ifconfig lo:1 10.10.20.1/32 up
(met een ip adres van locatie B in plaats van 10.10.20.1) op de server A

en
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

En met de route op server B, kijk dan met tcpdump of je verkeer voor dat IP adres op A ziet aankomen.

En dan dus nog wat werken met een routing table om de antwoorden ook via de tunnel te laten lopen.

als ik ping zie ik verkeer aankomen op de server B

18:27:26.859210 IP 213.xxx.xxx.xxx > 210.1.58.27: GREv0, length 88: IP 192.168.2.2 > 192.168.2.1: ICMP echo request, id 33035, seq 5, length 64

nu ga ik proberen om de packets te forwarden naar server A

Oorspronkelijk geplaatst door daiman

als ik ping zie ik verkeer aankomen op de server B

18:27:26.859210 IP 213.xxx.xxx.xxx > 210.1.58.27: GREv0, length 88: IP 192.168.2.2 > 192.168.2.1: ICMP echo request, id 33035, seq 5, length 64

nu ga ik proberen om de packets te forwarden naar server A

Misschien was het je al gelukt, maar ik verveelde me voldoende om het even te bouwen...

Tunnel staat, route op locatie A voor de andere IP adressen wijst door de tunnel, nu de IP adressen die van locatie A op server B staan:

ip -4 addr add 172.16.1.1/32 dev lo label lo:1
ip -4 addr add 172.16.1.2/32 dev lo label lo:2

(dus twee adressen op lo:1 en lo:2)

Dit werkt al voor inkomend verkeer, dat gaat door de tunnel weer terug.
Maar verkeer wat vanaf lo:1 opgezet wordt, moet ook weer door de tunnel.

op server B
ip route list table all (gewoon nuttig commando)
ip route add a.b.c.148/30 dev tunnel src a.b.c.150 table 10

(a.b.c.148 /30 : tunnel subnet bij mij, dev tunnel = tunnel naam (default gre0) , src is src ip op tunnel aan de kant van server B)

ip route add default via a.b.c.149 table 10

ip route add 127.0.0.0/8 dev lo table 10
ip route add 172.16.1.1 dev lo:1 table 10
ip rule add from 172.16.1.1 table 10
ip rule add from 172.16.1.2 table 10

(test)
ping -I 172.16.1.1 194.109.6.66 (= xs4all dns)

Met de sniffer moet je zien dat deze ping op server B via de gre tunnel naar buiten gaat.

Ik had de moed maar opgegeven het was na een tijdje niet gelukt.
En uit het bovenstaande begrijp ik een deel al niet want ik ben een beetje de formatie kwijt tussen server a en b

server A is de server waar ip's op zijn.
deze heeft tunnel ip: 192.168.2.2
en wil ik met publiek ip: 210.xxx.xxx.26
ik laat de tunnel lopen naar ip op server B: 210.xxx.xxx.27
lo:1 = 210.xxx.xxx.26

server B is dan de server waar de ip's vandaan komen:
deze heeft tunnel ip: 192.168.2.1

Hoe moet ik dit dan nu doen?

Visser al erg bedankt voor je inzet en hulp hierbij!

Oorspronkelijk geplaatst door daiman

Ik had de moed maar opgegeven het was na een tijdje niet gelukt.
En uit het bovenstaande begrijp ik een deel al niet want ik ben een beetje de formatie kwijt tussen server a en b

server A is de server waar ip's op zijn.
deze heeft tunnel ip: 192.168.2.2
en wil ik met publiek ip: 210.xxx.xxx.26
ik laat de tunnel lopen naar ip op server B: 210.xxx.xxx.27
lo:1 = 210.xxx.xxx.26

server B is dan de server waar de ip's vandaan komen:
deze heeft tunnel ip: 192.168.2.1

Hoe moet ik dit dan nu doen?

Visser al erg bedankt voor je inzet en hulp hierbij!

Je moet dus eerst die GRE tunnel weer hebben werken (posting 28-12 10:32)
Op server B, waar dus nog IP's over zijn, zet je een route voor die IPs naar de tunnel.

NB: ik zou hiervoor wel 'vrije' IPs gebruiken, niet juist het 'eigen' adres van server B.

Op server B:
ip route <ip wat naar A moet>/32 via 192.168.2.2 dev tunnel0
(even kijken wat de naam van de tunnel is. Gre0 ? )

Op server A (waar een IP van server B erbij komt)

Zie mijn posting van 14-1 00:16 ; die 172.16.1.1 waren mijn voorbeelden van adressen
ip -4 addr add 172.16.1.1/32 dev lo label lo:1
ip -4 addr add 172.16.1.2/32 dev lo label lo:2

(naam van tunnel device opzoeken)
ip route add 192.168.2.0/30 dev tunnel src 192.168.2.2 table 10

ip route add default via 192.168.2.1 table 10

(weer met 172.161.1 en 1.2 als voorbeelden van adressen die ja van server B naar A brengt)

ip route add 127.0.0.0/8 dev lo table 10
ip route add 172.16.1.1 dev lo:1 table 10
ip rule add from 172.16.1.1 table 10
ip rule add from 172.16.1.2 table 10

(test)
ping -I 172.16.1.1 194.109.6.66 (= xs4all dns)

Dit zou het volgens mij moeten doen. Tussendoor goed met tcpdump kijken of stappen werken.
Kun je door de tunnel pingen, worden adressen van B via de tunnel naar A gebracht, gaan antwoorden van A door de tunnel weer naar buiten, en tenslotte of verkeer wat vanuit A gestart wordt (vanaf die adressen die van server B zijn) ook via de tunnel loopt.

visser hardstikke bedankt!
Het is nu succesvol gelukt en ik heb een hoop van je geleerd

Oorspronkelijk geplaatst door daiman

visser hardstikke bedankt!
Het is nu succesvol gelukt en ik heb een hoop van je geleerd

Graag gedaan.
Ter herinnering (en ook voor meelezers) nog wel mijn waarschuwing dat dit niet het soort oplossing is waar je productie (cq betalende klanten) achter wilt hangen;
De beschikbaarheid en kwaliteit van de tunnel verbinding hangt af van *beide* datacenters en het internet pad ertussen, en daar heb je geen zicht op.
Daarnaast kunnen mensen die achter een domme firewall(admin) zitten, of dat zijn, last hebben van het feit dat de MTU van de tunnel kleiner is dan de "standaard" 1500 bytes en dat path mtu discovery daarvoor icmp terugstuurt.

Kortom, leerzaam project, een demonstratie dat je netwerktechnisch veel kunt doen met Linux, wellicht goed genoeg voor je hobby, maar "tunnel over internet" en "website met goede connectiviteit" blijven gewoon twee begrippen die niet bij elkaar horen.