Routing VPN client bakom NAT (anonine / openvpn)

Permalänk

Routing VPN client bakom NAT (anonine / openvpn)

Hej.
Har stött på ett problem som jag inte verkar kunna lösa hur mkt jag än googlar.

Har en setup som ser ut som följande:

Internet Gatway/ Openwrt 192.168.x.x LAN sidan
Rasberry Pi client som kör Openvpn mot Anonine via tun0 som får ett ip på 10.0.x.x vanliga eth0 har 192.168.x.x

Rasberry pin kan koppla upp mot VPN en och nå internet och kör jag tracert osv så
går trafiken genom anonine.

Problemet är att jag vill nå RPIn från wan sidan med till ex mobilen eller från jobbet på en
specifik port tex 21. Om vpn är avslaget så är det en vanlig port forwarding i OpenWRT
men när RPI är ansluten genom VPN så kommer man inte åt resursen på RPIn.

Behöver jag öppna några portar i OpenWrt mot RPin för att vpn clienten ska ta emot trafik eller går det
ens nå datorn bakom vpn. I rpin är iptables helt avstängt vad jag vet.

Mvh Lennis

Permalänk
Medlem

Du vet inte med dig om ISP:en har blockerat VPN? (Typ som telia, alltele etc gör med mobiltelefonin för dom enklare abbonemangen)

Visa signatur

CPU: I7 4770K Grafik: Poseidon Platinum GeForce GTX 980Ti Moderkort: Asus Maximus VI Hero Z87 RAM: 16Gb Corsair Dominator Platinum CL9 Nätagg: Corsair HX1050 Gold SSD: Corsair Force GT 240Gb SSHD: Seagate Desktop 4TB Låda: Corsair Graphite 600T

Permalänk
Medlem

Det är för att RPi'n har en default route ut via VPN anslutningen. Du får asymetrisk routing. På RPi'n kan du lösa detta med en alternativ routing tabell.

echo 10 via-openwrt >> /etc/iproute2/rt_tables
ip route add default via 192.168.0.1 table via-openwrt
ip rule add from 192.168.0.2 lookup via-openwrt

Om .1 är din gw och .2 är din RPi.

Visa signatur

Cisco - Linux - VMWare
-- Citera mig om ni vill få återkoppling --

Permalänk
Skrivet av deegan:

Det är för att RPi'n har en default route ut via VPN anslutningen. Du får asymetrisk routing. På RPi'n kan du lösa detta med en alternativ routing tabell.

echo 10 via-openwrt >> /etc/iproute2/rt_tables
ip route add default via 192.168.0.1 table via-openwrt
ip rule add from 192.168.0.2 lookup via-openwrt

Om .1 är din gw och .2 är din RPi.

Tack för svaret Deegan. Det fungerar nu som förväntat. En följdfrågar är då vad raderna gör eller hur trafiken flödar:
Om jag använder traceroute eller likande så ser jag att den går igenom VPn och om man traceroutar VPN ip så slutar den vid vpn
så allt verkar fungera som det ska där. Antar att all trafik är skyddad ut från pin men man kan snappa upp paket som kommer in?

En annan sak som jag inte förstår riktigt är att SSH servern fungerar ej att komma åt geonom(vpn ipt) men jag kan komma åt en annan server på en annan port.

Mvh Lennis

Permalänk
Medlem
Skrivet av Lennis_o_O_o:

Tack för svaret Deegan. Det fungerar nu som förväntat. En följdfrågar är då vad raderna gör eller hur trafiken flödar:
Om jag använder traceroute eller likande så ser jag att den går igenom VPn och om man traceroutar VPN ip så slutar den vid vpn
så allt verkar fungera som det ska där. Antar att all trafik är skyddad ut från pin men man kan snappa upp paket som kommer in?

En annan sak som jag inte förstår riktigt är att SSH servern fungerar ej att komma åt geonom(vpn ipt) men jag kan komma åt en annan server på en annan port.

Mvh Lennis

Ok så det som händer är att när du startar upp OpenVPN så installeras en ny default-route i routing tabellen, och om du inte kan grunderna i nät riktigt så får du försöka hänga med ändå. source och destination IP ändras aldrig i paketet, det är bara MAC-adressen som ändras ( den gör det för varje hop i nätet), och när din RPi får in en ett SYN-paket för att initera en anslutning mot 22/TCP så vill RPin svara med ett ACK, eftersom IP-adressen i paketet inte är ett lokalt paket (alltså det återfinns inte på ditt LAN) så kommer RPi göra en route lookup genom att titta i routing tabellen och då ser den att enda möjligheten är att skicka trafiken via din default route som råkar gå ut via VPN anslutningen. Det här är asymetrisk routing, när trafik kommer in från ett håll (din openwrt router) men skickas ut åt ett annat håll (din vpn anslutning), det kommer aldrig att generera en lyckad anslutning eftersom en session aldrig kan upprättas.

Asymetrisk routing: https://www.youtube.com/watch?v=5LLv-_1-DMY#t=43

Så hur kan vi lösa detta? Ja ett sätt är att göra som du nyss gjort, att skapa en separat routing tabell utanför din default tabell och hänvisa viss trafik till den tabellen baserat på vissa regler, eller så väljer du att inte ta med default-routen från openvpn (ta bort defgw i .conf filen) och bind'a dina processer till det IP't när du vill använda vpn anslutningen, du kan även skapa en separat routing tabell här och säga "rule bla bla bla via openvpn" för den trafik som skall gå där.

echo 10 via-openwrt >> /etc/iproute2/rt_tables
Denna raden skapar helt enkelt tabellen i text-filen rt_tables som sedan läses av iproute2.

ip route add default via 192.168.0.1 table via-openwrt
Den här raden skapar en default route för den tabellen, annars kommer du bara black-hole'a trafiken som du skickar in hit.

ip rule add from 192.168.0.2 lookup via-openwrt
All trafik som har sin origin i 192.168.0.2 skall använda via-openwrt routing tabellen. Så trafik som kommer in till 192.168.0.2 (från internet och din openwrt router) kommer routas tillbaka samma väg som den kom.

Visa signatur

Cisco - Linux - VMWare
-- Citera mig om ni vill få återkoppling --

Permalänk
Medlem

En notis:

Så länge man inte adressöversätter någonting (vilket det dock görs i detta fall) så fungerar assymetrisk routing i många sammanhang. En brandvägg kommer sannolikt inte med default inställningar acceptera att den ser bara ser en riktning av trafiken, men en router har inget sådant begrepp (alltså en riktig router och inte en bredbandsrouter). Den skickar bara trafiken efter den routingtabell som gäller.

Det förekommer en massa assymetrisk routing på internet, men som Deegan skriver så fungerar det absolut inte i det här fallet då det är adressöversättningar inblandade.

Permalänk
Skrivet av deegan:

Ok så det som händer är att när du startar upp OpenVPN så installeras en ny default-route i routing tabellen, och om du inte kan grunderna i nät riktigt så får du försöka hänga med ändå. source och destination IP ändras aldrig i paketet, det är bara MAC-adressen som ändras ( den gör det för varje hop i nätet), och när din RPi får in en ett SYN-paket för att initera en anslutning mot 22/TCP så vill RPin svara med ett ACK, eftersom IP-adressen i paketet inte är ett lokalt paket (alltså det återfinns inte på ditt LAN) så kommer RPi göra en route lookup genom att titta i routing tabellen och då ser den att enda möjligheten är att skicka trafiken via din default route som råkar gå ut via VPN anslutningen. Det här är asymetrisk routing, när trafik kommer in från ett håll (din openwrt router) men skickas ut åt ett annat håll (din vpn anslutning), det kommer aldrig att generera en lyckad anslutning eftersom en session aldrig kan upprättas.

Asymetrisk routing: https://www.youtube.com/watch?v=5LLv-_1-DMY#t=43

Så hur kan vi lösa detta? Ja ett sätt är att göra som du nyss gjort, att skapa en separat routing tabell utanför din default tabell och hänvisa viss trafik till den tabellen baserat på vissa regler, eller så väljer du att inte ta med default-routen från openvpn (ta bort defgw i .conf filen) och bind'a dina processer till det IP't när du vill använda vpn anslutningen, du kan även skapa en separat routing tabell här och säga "rule bla bla bla via openvpn" för den trafik som skall gå där.

echo 10 via-openwrt >> /etc/iproute2/rt_tables
Denna raden skapar helt enkelt tabellen i text-filen rt_tables som sedan läses av iproute2.

ip route add default via 192.168.0.1 table via-openwrt
Den här raden skapar en default route för den tabellen, annars kommer du bara black-hole'a trafiken som du skickar in hit.

ip rule add from 192.168.0.2 lookup via-openwrt
All trafik som har sin origin i 192.168.0.2 skall använda via-openwrt routing tabellen. Så trafik som kommer in till 192.168.0.2 (från internet och din openwrt router) kommer routas tillbaka samma väg som den kom.

Tackar för grymt bra svar även att jag kanske inte förstår allt.
Angående varför Ena porten fungerade och andra inte beror troligtvis på att enligt diverse forum osv så blockerar 'Anonine port forwarding på 1-1024 portarna men släpper igenom över det. (Har inte hunnit testa byta port än).

Mvh

Permalänk
Medlem
Skrivet av Lennis_o_O_o:

Tackar för grymt bra svar även att jag kanske inte förstår allt.
Angående varför Ena porten fungerade och andra inte beror troligtvis på att enligt diverse forum osv så blockerar 'Anonine port forwarding på 1-1024 portarna men släpper igenom över det. (Har inte hunnit testa byta port än).

Mvh

Ja det är ju ett troligt problem. Och precis som Talisker00 påpekar så är detta bara ett problem om trafiken går genom en NAT / stateful brandvägg vilket det gör i ditt fall. Ute på Internet kan trafiken dela upp sig ganska mycket, dels på grund av diffande metrics i routes hos olika operatörer / routrar men också på grund av MPLS som kan skicka trafiken på olika vägar bara baserad på hashen. Du kan se det om du visar AS-nummer samt extended info i en traceroute.

deegan@deg:~$ traceroute -eA www.youtube.com
traceroute to www.youtube.com (64.233.165.93), 30 hops max, 60 byte packets
1 - (x.x.x.x) [*] 0.143 ms 0.141 ms 0.139 ms
2 c83-248-150-1.bredband.comhem.se (83.248.150.1) [AS39651] 1.219 ms 1.780 ms 2.215 ms
3 sv-bb-r-01-to-osk-r-01.comhem.se (83.255.252.51) [AS39651] 3.051 ms 4.546 ms 4.696 ms
4 mtc-bb-r-02-to-sv-bbr-1.comhem.se (83.255.252.53) [AS39651] 6.998 ms 7.527 ms 7.951 ms
5 83.255.253.204 (83.255.253.204) [AS39651] 6.963 ms 7.263 ms 8.683 ms
6 core1.ams.net.google.com (80.249.208.247) [AS1200] 32.303 ms netnod-ix-ge-b-sth-1500.google.com (194.68.128.115) [AS8674] 6.492 ms core1.ams.net.google.com (80.249.208.247) [AS1200] 32.110 ms
7 216.239.43.122 (216.239.43.122) [AS15169] 25.426 ms 6.844 ms 6.837 ms
8 209.85.254.13 (209.85.254.13) [AS15169] <MPLS:L=591616,E=4,S=1,T=1> 6.822 ms 209.85.254.31 (209.85.254.31) [AS15169] <MPLS:L=562080,E=4,S=1,T=1> 6.986 ms 209.85.253.249 (209.85.253.249) [AS15169] <MPLS:L=632271,E=4,S=1,T=1> 32.209 ms
9 209.85.255.85 (209.85.255.85) [AS15169] <MPLS:L=411911,E=4,S=1,T=1> 32.669 ms 209.85.247.89 (209.85.247.89) [AS15169] <MPLS:L=437216,E=4,S=1,T=1> 15.857 ms 209.85.255.85 (209.85.255.85) [AS15169] <MPLS:L=411911,E=4,S=1,T=1> 39.104 ms
10 209.85.247.77 (209.85.247.77) [AS15169] 51.792 ms 209.85.247.85 (209.85.247.85) [AS15169] 15.559 ms 209.85.255.71 (209.85.255.71) [AS15169] <MPLS:L=579559,E=4,S=1,T=1> 33.142 ms
11 209.85.240.88 (209.85.240.88) [AS15169] <MPLS:L=416305,E=4,S=1,T=1> 40.748 ms * *
12 64.233.165.93 (64.233.165.93) [AS15169] 15.628 ms 209.85.254.152 (209.85.254.152) [AS15169] <MPLS:L=424782,E=4,S=1,T=1> 39.319 ms 216.239.43.178 (216.239.43.178) [AS15169] <MPLS:L=656992,E=4,S=1,T=1> 39.307 ms
deegan@deg:~$

Hoppas du blev klokare.

Visa signatur

Cisco - Linux - VMWare
-- Citera mig om ni vill få återkoppling --

Permalänk

Har hållt på med detta lite fram och tillbaka nu och kan inte få nån riktig ordning på det.

Har flyttat över vpnen till Routern nu OpenWRT för att tunnla all trafik och det fungerar.
Har provat lite för att se hur det fungerar med port forwarding. Satt upp en FTP server och testat lite olika portar på en WIN 7 dator som jag utan problem kan komma åt från WAN sidan med IPt som jag får av VPN leverantören. Det som är problemet är att på RPI datorn så kör jag en annan server som användare loggar in på och upprättar en anslutning till på en specifik port. Det fungerar inte som det ska, jag ser att trafiken kommer fram till RPIn och på rätt port men det står bara SYN_RECV.

Det verkar också som att har jag användare inloggade innan jag kopplar upp mot VPNen å de har en established connection så kan de ansluta även när VPn är uppkopplad.

Så antar att det har med den Assymetriksa routningen att göra men jag förstår inte vad det är jag ska ändra?

All trafik kommer väl in och ut på samma ställe i detta fallet eller misstar jag mig?

Mvh Glenn

Permalänk
Skrivet av deegan:

Ja det är ju ett troligt problem. Och precis som Talisker00 påpekar så är detta bara ett problem om trafiken går genom en NAT / stateful brandvägg vilket det gör i ditt fall. Ute på Internet kan trafiken dela upp sig ganska mycket, dels på grund av diffande metrics i routes hos olika operatörer / routrar men också på grund av MPLS som kan skicka trafiken på olika vägar bara baserad på hashen. Du kan se det om du visar AS-nummer samt extended info i en traceroute.

deegan@deg:~$ traceroute -eA www.youtube.com
traceroute to www.youtube.com (64.233.165.93), 30 hops max, 60 byte packets
1 - (x.x.x.x) [*] 0.143 ms 0.141 ms 0.139 ms
2 c83-248-150-1.bredband.comhem.se (83.248.150.1) [AS39651] 1.219 ms 1.780 ms 2.215 ms
3 sv-bb-r-01-to-osk-r-01.comhem.se (83.255.252.51) [AS39651] 3.051 ms 4.546 ms 4.696 ms
4 mtc-bb-r-02-to-sv-bbr-1.comhem.se (83.255.252.53) [AS39651] 6.998 ms 7.527 ms 7.951 ms
5 83.255.253.204 (83.255.253.204) [AS39651] 6.963 ms 7.263 ms 8.683 ms
6 core1.ams.net.google.com (80.249.208.247) [AS1200] 32.303 ms netnod-ix-ge-b-sth-1500.google.com (194.68.128.115) [AS8674] 6.492 ms core1.ams.net.google.com (80.249.208.247) [AS1200] 32.110 ms
7 216.239.43.122 (216.239.43.122) [AS15169] 25.426 ms 6.844 ms 6.837 ms
8 209.85.254.13 (209.85.254.13) [AS15169] <MPLS:L=591616,E=4,S=1,T=1> 6.822 ms 209.85.254.31 (209.85.254.31) [AS15169] <MPLS:L=562080,E=4,S=1,T=1> 6.986 ms 209.85.253.249 (209.85.253.249) [AS15169] <MPLS:L=632271,E=4,S=1,T=1> 32.209 ms
9 209.85.255.85 (209.85.255.85) [AS15169] <MPLS:L=411911,E=4,S=1,T=1> 32.669 ms 209.85.247.89 (209.85.247.89) [AS15169] <MPLS:L=437216,E=4,S=1,T=1> 15.857 ms 209.85.255.85 (209.85.255.85) [AS15169] <MPLS:L=411911,E=4,S=1,T=1> 39.104 ms
10 209.85.247.77 (209.85.247.77) [AS15169] 51.792 ms 209.85.247.85 (209.85.247.85) [AS15169] 15.559 ms 209.85.255.71 (209.85.255.71) [AS15169] <MPLS:L=579559,E=4,S=1,T=1> 33.142 ms
11 209.85.240.88 (209.85.240.88) [AS15169] <MPLS:L=416305,E=4,S=1,T=1> 40.748 ms * *
12 64.233.165.93 (64.233.165.93) [AS15169] 15.628 ms 209.85.254.152 (209.85.254.152) [AS15169] <MPLS:L=424782,E=4,S=1,T=1> 39.319 ms 216.239.43.178 (216.239.43.178) [AS15169] <MPLS:L=656992,E=4,S=1,T=1> 39.307 ms
deegan@deg:~$

Hoppas du blev klokare.

Skrivet av Talisker00:

En notis:

Så länge man inte adressöversätter någonting (vilket det dock görs i detta fall) så fungerar assymetrisk routing i många sammanhang. En brandvägg kommer sannolikt inte med default inställningar acceptera att den ser bara ser en riktning av trafiken, men en router har inget sådant begrepp (alltså en riktig router och inte en bredbandsrouter). Den skickar bara trafiken efter den routingtabell som gäller.

Det förekommer en massa assymetrisk routing på internet, men som Deegan skriver så fungerar det absolut inte i det här fallet då det är adressöversättningar inblandade.

Ni verkade kunna detta så hade varit trevligt om ni tog er tid och löste detta problemet åt mig.
Tack på förhand.

Mvh Lennis