Onderwerp: ip routen locatie A naar B

Goedenavond,

Ik zit momenteel met een probleem.
Ik heb 2 servers op verschillende locatie's

Maar op locatie A kan ik geen ip adressen meer verkrijgen omdat ik er geen meer kan aanvragen.
Maar op locatie B heb ik nog een stuk of 100 adressen vrij.
Wat ik nu wil is de adressen van locatie B routen naar locatie A zodat ik de server op locatie A ip adressen kan laten uitdelen.

Hoe kan ik dit nou het beste aanpakken.
Even ter informatie: Ik gebruik op beide servers Centos.

Alvast bedankt,
Daiman

Uh... dit wil je echt? Nou ja, je zou een VPN tunnel kunnen openzetten met NAT conversie.
Niet echt een optie natuurlijk in praktijk, maar het werkt wel

Oorspronkelijk geplaatst door daiman

Goedenavond,

Ik zit momenteel met een probleem.
Ik heb 2 servers op verschillende locatie's

Maar op locatie A kan ik geen ip adressen meer verkrijgen omdat ik er geen meer kan aanvragen.
Maar op locatie B heb ik nog een stuk of 100 adressen vrij.
Wat ik nu wil is de adressen van locatie B routen naar locatie A zodat ik de server op locatie A ip adressen kan laten uitdelen.

Hoe kan ik dit nou het beste aanpakken.
Even ter informatie: Ik gebruik op beide servers Centos.

Alvast bedankt,
Daiman

Zorgen dat je toch op locatie A meer adressen kan krijgen, of gewoon minder leveren op locatie A en meer leveren op locatie B.

In theorie kun je met een tunnel of andersoortig VPN constructie adressen van locatie B op locatie A laten uitkomen.

Echter, verkeer loopt dan van bezoeker naar locatie B, gaat (in een tunnel) weer over internet naar locatie A en komt dan pas op de server.
(en retour verkeer gaat vice-versa).
De beschikbaarheid van sites op locatie A die van deze getunnelde adressen gebruik maken is dan óók nog afhankelijk van locatie B en het pad tussen A en B.

Wat daarnaast een vervelend probleem kan zijn is dat de maximale MTU size vanwege de tunnel header wat kleiner wordt dan de 'normale' 1500 bytes.
In combinatie met nitwits die firewall beheerder spelen en alle icmp verkeer blokkeren geeft dat heel lastig te troubleshooten problemen vanwege path mtu discovery.

In plaats van een (publiek internet) tunnel een private interconnect bestellen (met normale mtu size en behoorlijke garanties) tussen de twee locaties lost wel een paar van die problemen op, maar die business case zul je wel niet uit komen.

Ja het zou heel handig zijn om dit op locatie A te hebben omdat we toch daar adressen nodig hebben.
En als ik dan eventueel zo'n VPN tunnel zou doen welke software zou je mij aanraden?
En zouden dan porten open gezet kunnen worden zodat dat ip beschikbaar is?

Dit doet het goed: http://openvpn.net/

Oorspronkelijk geplaatst door daiman

Ja het zou heel handig zijn om dit op locatie A te hebben omdat we toch daar adressen nodig hebben.
En als ik dan eventueel zo'n VPN tunnel zou doen welke software zou je mij aanraden?
En zouden dan porten open gezet kunnen worden zodat dat ip beschikbaar is?

Aangezien het toch om internet verkeer gaat, geeft ipsec of andere tunnel/vpn protocollen met encryptie geen meerwaarde.
(tenminste, ik neem aan dat het pad tussen locatie A en B even betrouwbaar of onbetrouwbaar is als het pad van bezoekers naar A of B.).

Dan zou ik denk ik gewoon een GRE tunnel bouwen (modprobe gre , ip tunnel add name mode gre .... )
De software ('ip') en de gre module zit al in je server normaal gesproken. Verder heb je wat bouwwerk met iptables om het juiste verkeer de tunnel in te duwen, en zorgen dat retourverkeer ook weer via de tunnel loopt.

Maar echt, dit is "leuk om te leren hoe IP en wat geavanceerder routing werkt", maar dit soort oplossingen is puur _bagger_ als je hiermee betalende klanten wilt bedienen. En, gezien je vragen, denk ik dat je wel even bezig bent om het werkend te krijgen. Wel goed om te leren, overigens.
Of, zoals ik mensen in een ander forum wel eens lees "ik moedig al mijn concurrenten aan om dit te doen"

Als beide locaties van dezelfde provider zijn zou je kunnen vragen om een (vlan) koppeling tussen beide locaties. Veel providers (bijv. Leaseweb) leveren dit tegen een schappelijke prijs. Bij sommige is het zelfs gratis onderdeel van de dienstverlening. Als zo'n koppeling niet beschikbaar is zou je ook iets met een tunnel kunnen doen maar dat zou ik zoals visser ook zegt niet aan betalende klanten als oplossing bieden. Als je gebrek heb aan ip adressen kan je ook overstappen op ipv6

Oorspronkelijk geplaatst door redbeenl

Als je gebrek heb aan ip adressen kan je ook overstappen op ipv6

Dat lost je probleem niet op als je eind klanten geen ipv6 hebben, websites op ipv6 only draaien heeft geen nut want er is misschien maar 2% van de ISP's die al dual stack levert.

Dat klopt, vandaar de

Tot de tijd dat iedereen ipv6 heeft is een transparante koppeling de enige mogelijke oplossing wat mij betreft.

Inmiddels ben ik al een stuk verder door jullie hulp.
locatie A heeft lokaal ip 10.0.2.1
locatie B heeft 10.0.1.1 die bind is met 210.1.xxx.xxx

ik kan nu onderling pingen via locatie A naar B pingen lukt en ook vanaf B naar A.
Nu loop ik tegen het volgende.
Ik wil de ip die ik gebonden heb met locatie B dus 210.1.xxx.xxx in DMZ of alle porten forwarden.
Nu heb ik gezocht en kwam op het volgende uit
iptables -t nat -A PREROUTING -i <Public-IFace> -p gre -d <VPN-Public-IP> -j DNAT --to-destination <VPN-DMZ-IP>
iptables -t nat -A PREROUTING -i <Public-IFace> -p tcp --sport 1024:65535 -d <VPN-Public-IP> --dport 1723 -j DNAT --to-destination <VPN-DMZ-IP>

maar moet dit op locatie B VPN-Public-IP dit zijn: 10.0.2.1 VPN-DMZ-IP: 210.1.xxx.xxx

alvast bedankt

Oorspronkelijk geplaatst door daiman

Inmiddels ben ik al een stuk verder door jullie hulp.
locatie A heeft lokaal ip 10.0.2.1
locatie B heeft 10.0.1.1 die bind is met 210.1.xxx.xxx

ik kan nu onderling pingen via locatie A naar B pingen lukt en ook vanaf B naar A.
Nu loop ik tegen het volgende.
Ik wil de ip die ik gebonden heb met locatie B dus 210.1.xxx.xxx in DMZ of alle porten forwarden.
Nu heb ik gezocht en kwam op het volgende uit
iptables -t nat -A PREROUTING -i <Public-IFace> -p gre -d <VPN-Public-IP> -j DNAT --to-destination <VPN-DMZ-IP>
iptables -t nat -A PREROUTING -i <Public-IFace> -p tcp --sport 1024:65535 -d <VPN-Public-IP> --dport 1723 -j DNAT --to-destination <VPN-DMZ-IP>

maar moet dit op locatie B VPN-Public-IP dit zijn: 10.0.2.1 VPN-DMZ-IP: 210.1.xxx.xxx

alvast bedankt

Zo werkt het niet.
Je bent nu alleen protocol GRE aan het nat-ten.

Je moet eerst/ook een tunnel bouwen; Die gebruikt typisch GRE als protocol. (hoewel ip in ip ook kan).

w.x.y.z. : remote publiek ip adres
a.b.c.d : ip adres waarmee de server naar buiten gaat richting die remote server

modprobe gre
echo 1 >/proc/sys/net/ipv4/ip_forward
ip tunnel add mijntunnel mode gre remote w.x.y.z local a.b.c.d ttl 64
ip link set mijntunnel multicast on
ip link set mijntunnel up
ip addr add dev tvtunnel local 192.168.2.1 peer 192.168.2.2/30 dev mijntunnel

En op de remote server hetzelfde, maar met de adressen van tunnel endpoints en de ip adressen op de tunnel andersom.
Nu moet je kunnen pingen van 192.168.2.1 naar 192.168.2.2 .
Een tunnel is een point to point verbinding, net alsof je bijvoorbeeld een PPP sessie hebt.
(of een echte seriele lijn op een router, zoals POS of een E3)

Dan moet je nog op de 'heen' server routes voor de adressen die door de tunnel moeten zetten.
En op de ontvangende server moet je goed zorgen dat verkeer wat over de tunnel binnenkomt, ook weer door de tunnel terug gaat.
Let op dat je op de ontvangende server niet de default route door de tunnel (kunt) sturen, en normale adressen die er wel horen wel normaal naar buiten moeten gaan.
De adressen op de ontvangende server moet je nog ergens aan hangen, dat kan denk ik het beste aan een paar extra loopbacks.
Tenzij je de server puur als 'router' gebruikt en de adressen die binnenkomen laat doorrouteren naar andere servers op die locatie.
En in je firewall rules heb je nu ook verkeer wat door je FORWARD chain moet, want je bent nu echt aan het routeren.

Als je provider overigens (zoals redbeenl suggereerde) voor weinig een transparante ethernet link kan leveren tussen de locaties ben je daarmee heel veel beter af dan met een tunnel.

visser: bedankt dit werkt al een heel eind.
Ik kan onderling pingen.

Maar hoe kan ik die met de iptables het beste gaan doen?

Oorspronkelijk geplaatst door daiman

visser: bedankt dit werkt al een heel eind.
Ik kan onderling pingen.

Maar hoe kan ik die met de iptables het beste gaan doen?

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.

Hou er bij deze opzet ook rekening mee dat veel controlpanels niet (of niet goed) functioneren achter NAT.

Oorspronkelijk geplaatst door redbeenl

Hou er bij deze opzet ook rekening mee dat veel controlpanels niet (of niet goed) functioneren achter NAT.

Vast, maar in dit tunnel model is geen sprake van NAT.
De enige rfc1918 adressen hier zijn de tunnel interface adressen, maar het 'doel' adres is gewoon publiek.
Ik verwacht eigenlijk niet dat de tunnel adressen ergens zichtbaar worden.
Zou dit toch nog een probleem zijn dan zal daiman nog een paar van z'n (publieke) adressen op de tunnel moeten zetten.