|
Hi Timothy,
What you had working was it in AWS or VMWare?
I've pretty much given up trying to get the spoofed reply traffic back
out of AWS it gets dropped always with either DR mode or TUN unless I
send it back via the director and that case I may as well do NAT mode
instead...
My understanding is that when egress traffic hits their edge they
check the source matches the instance it came from and if it doesn't
the packet gets dropped. However, all works fine if the client is in
the same VPC so it doesn't need to go out past the edge of the VPC.
Just interested if you found the same in your testing?
Aaron West
Loadbalancer.org
www.loadbalancer.org
+1 888 867 9504 / +44 (0)330 380 1064
aaron@xxxxxxxxxxxxxxxx
LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG
On 10 August 2017 at 18:08, Timothy R. Weiand <timothy.weiand@xxxxxxxxx> wrote:
> Julian:
>
> Good news and bad news: this guidance helped me get LVS-TUN working with a
> 3.10.0 kernel. But, I am not able to use the same configuration to get
> 4.4.x,4.8.x or 4.12.x working. We are working on doing further analysis to
> ensure it is kernel dependent and not distribution dependent. I hope to
> find the kernel version that this configuration stops working.
>
> Note on 4.x machines: If we do not have the correct ip assigned to the
> tunnel interface we can see traffic on that interface. But, if we use the
> correct VIP then we no longer see the traffic.
>
> I will keep you updated as I find information out.
>
> Thanks!
> -Timothy
>
> On Tue, Jul 25, 2017 at 4:25 PM Julian Anastasov <ja@xxxxxx> wrote:
>
>>
>> Hello,
>>
>> On Fri, 14 Jul 2017, Timothy R. Weiand wrote:
>>
>> > I am building a DR-TUN configuration to load balance DNS traffic. My
>> issue
>> > is with the real servers: the ipip packet get unwrapped and appears on
>> the
>> > tunnel interface and becomes a martian. Also, I have not been able to
>> > determine how to bind to the tunnel interface to capture these packets. I
>> > have verified details with tcpdump/dmesg. All my configuration is
>> scripted
>> > to ensure reproducibility. tcpdumps below do not show real DNS traffic;
>> > using netcat to send text.
>> >
>> > Much more detail can be supplied, please request it.
>> >
>> > Configuration:
>> >
>> > ==============
>> >
>> > - All machines are currently Debian 9 (4.9.30-2+deb9u2)
>> >
>> > - Client: 192.168.200.10
>> >
>> > - Director: 192.168.200.11
>> >
>> > - Real Server: 192.168.200.12
>> >
>> > - No VIP: I am using the IP address for my director interface -
>> > 192.168.200.11
>> >
>> >
>> > Director Configuration:
>> >
>> > ==================
>> >
>> > vagrant@debian-9-lb:~$ sudo ipvsadm -Ln
>> >
>> > IP Virtual Server version 1.2.1 (size=4096)
>> >
>> > Prot LocalAddress:Port Scheduler Flags
>> >
>> > -> RemoteAddress:Port Forward Weight ActiveConn InActConn
>> >
>> > UDP 192.168.200.11:53 rr
>> >
>> > -> 192.168.200.12:53 Tunnel 1 0 0
>> >
>> >
>> >
>> > Real Server:
>> >
>> > ============
>> >
>> > # modprobe ipip
>> >
>> > # echo 1 > /proc/sys/net/ipv4/ip_forward
>> >
>> > # ip tunnel add tunl1 mode ipip ttl 32 local 192.168.200.12 remote
>> > 192.168.200.11
>> >
>> > # ip link set tunl1 up arp off
>> >
>> > # echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
>> >
>> > # echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter
>> >
>> > # echo 2 > /proc/sys/net/ipv4/conf/tunl0/rp_filter
>> >
>> > # echo 2 > /proc/sys/net/ipv4/conf/tunl1/rp_filter
>>
>> tunl1/rp_filter=2 is ignored if there are no
>> IPv4 addresses configured on tunl1, you can see
>> __fib_validate_source() for reference:
>>
>> if (no_addr)
>> goto last_resort;
>>
>> As result, packets are dropped as martians due to rpf=2.
>>
>> To check if packets are dropped by routing try:
>>
>> ip route get from 192.168.200.10 to 192.168.200.11 iif tunl1
>>
>> Here is small howto for TUN (outdated):
>>
>> http://ja.ssi.bg/TUN-HOWTO.txt
>>
>> > vagrant@debian-9-dns:~$ sudo tcpdump -e -n -s 0 -i tunl1 -vv
>> >
>> > tcpdump: listening on tunl1, link-type RAW (Raw IP), capture size 262144
>> > bytes
>> >
>> > 10:16:13.919646 ip: (tos 0x0, ttl 64, id 63545, offset 0, flags [DF],
>> proto
>> > UDP (17), length 40)
>> >
>> > 192.168.200.10.51149 > 192.168.200.11.53: [udp sum ok] 26226
>> updateMA+
>> > [b2&3=0x6f6d] [27753a] [11619q] [25966n] [29706au][|domain]
>> >
>> >
>> >
>> > If I add an IP address to the interface the packet never reaches tunl1
>> >
>> > # ip addr add 192.168.200.11/24 brd 192.168.200.11 dev tunl1
>>
>> Try with (note mask /32):
>>
>> ip addr add 192.168.200.11/32 dev tunl1
>>
>> as shown in LVS HOWTO (8.3):
>>
>> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-Tun.html
>>
>> > Notes:
>> >
>> > ======
>> >
>> >
>> >
>> > LVS-DR was not an option because the real servers will be in different
>> > subnets (I was able to get LVS-DR working though).
>> >
>> >
>> >
>> > I am looking for advice on how to better understand or resolve this
>> issue.
>> > Or, who would be better to answer this question.
>> >
>> >
>> >
>> > I have groked as many articles on how to setup this configuration as I
>> can.
>> > And, I have read a good deal of the archives of this mailing list.
>> >
>> >
>> >
>> > Linux distributions I have tried are Debian, Ubuntu and Amazon linux.
>> This
>> > is been tested on both AWS and VMware fusion.
>> >
>> >
>> >
>> > ------
>> >
>> >
>> >
>> > I have a feeling I am missing something simple...
>> >
>> >
>> >
>> > Thanks!
>> >
>> > -Timothy
>>
>> Regards
>>
>> --
>> Julian Anastasov <ja@xxxxxx>
>>
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
>
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
