:: Re: [DNG] Fwd: Can't ping outside o…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Axy
Fecha:  
A: dng
Asunto: Re: [DNG] Fwd: Can't ping outside of my network after having configured a tun tap device
Could you show output of "ip -a" and "ip route show"? I presume you have
no specific ip rules?

Just curious.

Axy

On 10/8/23 15:08, Mario Marietto via Dng wrote:
> I think I got it working in a dirty way. This is what I did :
>
>  1. Shut down libvirt
>  2. Create a bridge br1 manually without any slaves (|ip link add name
>     br1 type bridge|)
>  3. Added "allow all" to that bridge helper file (bridge.conf, you had
>     that file somewhere below /usr/local)
>  4. Started a VM with qemu only, telling it to use a bridge interface
>     "br1". This will create a tap interface "tap0" */which is a slave
>     /*of a bridge "br1"
>  5. Right after VM start, explicitly set link br1 to "up" (|ip link
>     set br1 up|)
>  6. Configured an IP address from within the VM in a new subnet
>     (192.168.20.2/24 <http://192.168.20.2/24>)
>  7. Configured IP address in the same subnet for br1 on KVM host
>     (192.168.20.1/24 <http://192.168.20.1/24>). No IP on the tap
>     interface :_ip a add 192.168.20.1/24 <http://192.168.20.1/24> dev br1_
>  8. Configured MASQUERADING for traffic leaving through my standard
>     home interface on the KVM host: |iptables -t nat -A POSTROUTING -o
>     mlan0 -j MASQUERADE|
>  9. Enable Routing :*echo*1 >/proc/sys/net/ipv4/ip_forward

>
>
> That's it. The VM could ping everything,but another step is necessary :
>
> After that the VM has been started,I should do : |ip a fl dev tap0 |
> |
> |
> This is a dirty workaround that I don't like too much,but it |removes the fake IP address 169.254.89.8 from the TAP0 and in this
> way I can ping the world while I'm using the VM.|
>
> Anyway every time I start a new VM,a new (and the same) fake ip
> [169.254.35.253] is assigned to the TAP interface and I should delete
> it everytime. That's annoying. Do you know why tap0 interferes with
> the correct working of the network ? Maybe what's wrong is the qemu
> parameter that manages the network :
>
> I tried to add a script directly between the qemu parameters like this :
>
> - net nic,model=virtio,macaddr=52:54:00:00:00:01 -net
> bridge,br=br1,script=*"/bin/ip a fl dev tap0"*\
>
> but it didn't work : the error is "invalid parameter script".
>
> Instead of deleting its IP address,can't it be routed correctly in
> some way ?
>
>
> ---------- Forwarded message ---------
> From: *Axy via Dng* <dng@???>
> Date: Sat, Oct 7, 2023 at 6:04 AM
> Subject: Re: [DNG] Can't ping outside of my network after having
> configured a tun tap device
> To: <dng@???>
>
>
> This won't work while default dev tap0 is in. Your routing table should
> have the only default route, via your wlx adapter. It looks like qemu vm
> networking is on your way (and all the rest network managers maybe), but
> I can't help with its settings, sorry.
>
> Axy
>
>
> On 10/6/23 22:21, Mario Marietto via Dng wrote:
> > ---> The only reason you can't ping 8.8.8.8 even from the host system
> > is messy routes
> >
> > I realized that I can ping 8.8.8 from the host os,but only if the
> > guest os (freebsd) does not start. Before to start it,I have the
> > following ip route situation :
> >
> > # iptables -t nat -A POSTROUTING -o wlx98ded00b7106 -j MASQUERADE
> >
> > # ip route
> > default via 192.168.1.1 dev wlx98ded00b7106 proto dhcp src 192.168.1.6
> > metric 600
> > 192.168.1.0/24 <http://192.168.1.0/24> <http://192.168.1.0/24> dev
> wlx98ded00b7106 proto
> > kernel scope link src 192.168.1.6 metric 600
> >
> > (I have changed wi-fi adapter,now I'm using a realtek)
> >
> > when the freebsd vm starts,the route situation change like this one :
> >
> > # ip route
> >
> > 0.0.0.0 dev tap0 scope link
> > default dev tap0 scope link
> > default via 192.168.1.1 dev wlx98ded00b7106 proto dhcp src 192.168.1.6
> > metric 600
> > 169.254.0.0/16 <http://169.254.0.0/16> <http://169.254.0.0/16> dev
> tap0 proto kernel scope
> > link src 169.254.192.128
> > 192.168.1.0/24 <http://192.168.1.0/24> <http://192.168.1.0/24> dev
> wlx98ded00b7106 proto
> > kernel scope link src 192.168.1.6 metric 600
> >
> > Now what should I do ? following your suggestion,I have removed these
> > routes :
> >
> > ip route del default dev tap0 scope link
> > ip route del 0.0.0.0 dev tap0 scope link
> >
> > Since I haven't created any tap0,the first one hasn't been deleted,but
> > the second one has. Now this is the situation :
> >
> > # ip route
> >
> > default dev tap0 scope link
> > default via 192.168.1.1 dev wlx98ded00b7106 proto dhcp src 192.168.1.6
> > metric 600
> > 169.254.0.0/16 <http://169.254.0.0/16> <http://169.254.0.0/16> dev
> tap0 proto kernel scope
> > link src 169.254.192.128
> > 192.168.1.0/24 <http://192.168.1.0/24> <http://192.168.1.0/24> dev
> wlx98ded00b7106 proto
> > kernel scope link src 192.168.1.6 metric 600
> >
> > the result is that I can't ping google.com <http://google.com>
> <http://google.com> inside
> > the vm and even on the host os. So,I presume that I should create the
> > tap0 interface if I want to delete it later.
> >
> > On Fri, Oct 6, 2023 at 7:03 PM Axy via Dng <dng@???> wrote:
> >
> >     Okay, let me try to explain (Friday is the excuse)
> >
> >     I know nothing about qemu-kvm-libvirt, but at a glance it should
> >     facilitate networking a lot, but I don't know how. Let's turn to the
> >     basics instead.
> >
> >     If you chose tap, which afaik is a way to handle ethernet frames in
> >     userspace, the handler could be any userspace process (e.g.
> >     qemu-kvm-libvirt). So your tap0 is actually one end of the wire. The
> >     opposite end is somewhere in qemu-kvm-libvirt (again, I know nothing
> >     about it, I'm an LXC user) and to reach that end you need the
> >     following
> >     route on your host system:
> >
> >
> >     ip route add 192.168.99.0/24 <http://192.168.99.0/24>
> <http://192.168.99.0/24> dev tap0
> >
> >     So if you ping some IP address in 192.168.99.0networkfrom the host
> >     system, packets will be routed to your virtualized system and if
> >     it has
> >     that IP address it will respond. Of course that system should have
> >     the
> >     default route back to 192.168.99.1
> >
> >     Same in LXC, where we use veth, which is a pair of linked
> interfaces:
> >     one is on the host system, another is assigned to the container .
> >
> >     You do not need a bridge interface.
> >
> >     Once again:
> >
> >     You do not need a bridge interface. In this configuration packets
> >     come
> >     from a virtualized system and go through NAT to mlan0. Your NAT rule
> >
> >     iptables -t nat -A POSTROUTING -o mlan0 -j MASQUERADE
> >
> >     looks correct.
> >
> >     The only reason you can't ping 8.8.8.8 even from the host system is
> >     messy routes. Assuming your mlan0 is the way to the Internet, the
> >     only
> >     default route should be:
> >
> >     default via 192.168.1.1 dev mlan0
> >
> >     With these ones
> >
> >     0.0.0.0 dev tap0 scope link
> >
> >     default dev tap0 scope link
> >
> >     packets will be directed to the wrong interface and embarrass your
> >     virtualized system. Drop these routes.
> >
> >     You would need a bridge if you wanted your host system and
> >     virtualized
> >     system to be on the same ethernet network (domain, segment,...)
> >     However,
> >     bear in mind: wifi interfaces in client mode cannot be bridged. In
> >     access point mode that does work, but does not work in client
> >     mode. Only
> >     wired interfaces can be freely bridged.
> >
> >     Axy
> >
> >     On 10/6/23 13:37, Mario Marietto via Dng wrote:
> >     > As long as I don't have any routing rules in my home network
> >     (static
> >     > or done by routing protocols such as OSPF or RIP), my KVM server
> >     will
> >     > be the only host in my network that knows how to reach
> > 192.168.20.0/24 <http://192.168.20.0/24> <http://192.168.20.0/24>
> >     > <http://192.168.20.0/24> (because it has 192.168.20.1 itself).
> That
> >     > means, my VMs will not be able to reach any other network. The
> >     > simplest approach to get this to work is to do NAT for /outgoing/
> >     > traffic. Now this kind of NAT is an SNAT, not a DNAT. While
> classic
> >     > SNAT is a one-to-one-mapping, MASQUERADE simply means "replace
> >     every
> >     > source IP with the IP on the outgoing interface".
> >     >
> >     > On Fri, Oct 6, 2023 at 8:51 AM Mario Marietto
> >     <marietto2008@???>
> >     > wrote:
> >     >
> >     >     Thanks.
> >     >
> >     >     so,maybe this is the solution :
> >     >
> >     >     |# iptables -t nat -A POSTROUTING -o mlan0 -j DNAT # ip
> >     tuntap add
> >     >     tap0 mode tap # ip link set dev tap0 up # ifconfig tap0
> >     > 192.168.99.1/24 <http://192.168.99.1/24> <http://192.168.99.1/24>
> >     <http://192.168.99.1/24> # echo 1 >
> >     >     /proc/sys/net/ipv4/ip_forward|
> >     >
> >     >
> >     >     iptables v1.8.9 (nf_tables): DNAT: option "--to-destination"
> >     must
> >     >     be specified
> >     >
> >     >     What could be the destination ? thanks.
> >     >
> >     >     On Fri, Oct 6, 2023 at 1:44 AM Gregory Nowak
> >     <greg@???> wrote:
> >     >
> >     >         On Thu, Oct 05, 2023 at 02:20:47PM +0200, Mario
> Marietto via
> >     >         Dng wrote:
> >     >         > I'm trying to set up a bridge on Linux Devuan 5
> (host os)
> >     >         with the
> >     >         > goal to give the connectivity to FreeBSD 13.2,that I
> have
> >     >         virtualized
> >     >         > with qemu-kvm-libvirt.
> >     >
> >     >         If you're trying to setup a bridge, then you're going
> >     about it the
> >     >         wrong way.. You'd set that up in
> /etc/network/interfaces, or
> >     >         in a file
> >     >         under /etc/network/interfaces.d where you bridge your
> >     mlan0 to
> >     >         your
> >     >         tap0. This is more involved when using wifi, but it can be
> >     >         done. See
> >     >         man interfaces, the bridge-utils package, and the
> >     wpasupplicant
> >     >         package. You mentioned
> >     >         you're using network manager. If so, then you will
> probably
> >     >         want to
> >     >         dump network manager if you go this route.
> >     >
> >     >         > on Devuan I did :
> >     >         >
> >     >         > # iptables -t nat -A POSTROUTING -o mlan0 -j MASQUERADE
> >     >
> >     >         If you want to keep going the way you are, then I
> think you
> >     >         want the
> >     >         DNAT target, not MASQUERADE.
> >     >
> >     >         Greg
> >     >
> >     >
> >     >         --
> >     >         web site: http://www.gregn.net
> >     >         gpg public key: http://www.gregn.net/pubkey.asc
> >     >         skype: gregn1
> >     >         (authorization required, add me to your contacts list
> first)
> >     >         If we haven't been in touch before, e-mail me before
> >     adding me
> >     >         to your contacts.
> >     >
> >     >         --
> >     >         Free domains: http://www.eu.org/ or mail
> dns-manager@???
> >     >
> >     >
> >     >
> >     >     --
> >     >     Mario.
> >     >
> >     >
> >     >
> >     > --
> >     > Mario.
> >     >
> >     > _______________________________________________
> >     > Dng mailing list
> >     > Dng@???
> >     > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >     _______________________________________________
> >     Dng mailing list
> > Dng@???
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >
> >
> >
> > --
> > Mario.
> >
> > _______________________________________________
> > Dng mailing list
> > Dng@???
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
> --
> Mario.
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng