bipul | Hi, could anyone help me to know why i'm not able to ping from A to D, since A, C and D all are running on Ubuntu-server. Is it a flaw in OpenVPN tap or? in routing https://pastebin.com/raw/fje2RFhc | 11:26 |
---|---|---|
cryptodan_mobile | bipul: are they pingable off openvpn | 13:01 |
=== phunysanta is now known as phunyguy | ||
jlacroix | Hello eveyrone. I am in the process of creating a VM template for Ubuntu Server 18.04. For some reason, if I delete /etc/machine-id, it's not regenerated automatically when the VM is started. I can regenerate it manually, but I was hoping there was a way for this to happen automatically at first boot. | 15:57 |
OerHeks | i think dbus-uuidgen --ensure=/etc/machine-id is your answer https://unix.stackexchange.com/questions/402999/it-is-ok-to-change-etc-machine-id | 16:00 |
OerHeks | systemd-machine-id-setup | 16:00 |
jlacroix | Thanks OerHeks, but that was the article I was already looking at. I know how to generate the machine ID manually, I was hoping to make it automatically happen. I tried deleting it but it doesn't create it when it starts. As for the systemd-machine-id-setup service, that's not available in Ubuntu 18.04 unless it requires a package to be installed | 16:05 |
TJ- | jlacroix: systemd-machine-id-setup is in 18.04's systemd package, in /bin/ | 16:06 |
OerHeks | ah hard linking | 16:07 |
jlacroix | Ah, I was able to find the systemd-machine-id now, thanks. | 16:08 |
jlacroix | The problem though is that it's always generating the same id each time I run it, despite me deleting /etc/machine-id first | 16:09 |
TJ- | did you read the man-page? | 16:11 |
OerHeks | If this file is empty | 16:12 |
OerHeks | or missing, systemd will attempt to use the D-Bus machine ID from /var/lib/dbus/machine-id, the value of the kernel command line option container_uuid, the KVM DMI product_uuid (on KVM systems), and finally a randomly generated UUID. | 16:12 |
jlacroix | Yes, I read it. | 16:13 |
jlacroix | /var/lib/dbus/machine-id is simply a link to /etc/machine-id | 16:14 |
bipul | cryptodan_mobile, Yes, at least the virtual interface created by OpenVPN from that i'm able to ping each others client/server and vice versa. | 17:34 |
cryptodan | bipul: yes your issue would appear to be routing | 17:54 |
cryptodan | bipul: i would ask in ##networking | 17:54 |
bipul | i have asked, and it was not related to routing, all routing is seems okay | 17:55 |
cryptodan | if it was then you would be able to ping from a to d | 17:56 |
cryptodan | and d to a | 17:56 |
bipul | exactly. it was working well in tun mode, but not with tap mode | 17:56 |
cryptodan | or maybe ask the OpenVPN people | 17:56 |
bipul | I have asked and raise a bug as well | 17:57 |
bipul | do we need to do bridging here??? i don't think so | 17:57 |
cryptodan | id wait till openvpn gets back unless its mission critical | 17:59 |
TJ- | bipul: what was the issue? I've seen you mention it in various channels over the last few days | 18:01 |
bipul | TJ-, It was related to tap mode in OpenVPN . Please find the diagram. https://pastebin.com/raw/fje2RFhc | 18:02 |
bipul | May be i should check the mac address of D at C, while pinging from A to D | 18:04 |
TJ- | yeah, just got the pastebin link in ##networking... seems to me the problem is on A's routing table... | 18:04 |
TJ- | bindi: "10.4.0.0/24 dev tap0 proto kernel scope link src 10.4.0.2 " <--- looks wrong! | 18:04 |
bipul | TJ-, So what would be the correct one?? | 18:05 |
bindi | wat | 18:07 |
bindi | hi | 18:07 |
bipul | I believe the gateway would be the tap0 IP on the client as well as on the server. | 18:07 |
TJ- | bipul: In other words, have you checked whether C/D receive the pings from A using tcpdump? even if the reply doesn't get back to A? | 18:08 |
bipul | Because this is the virtual interface created during running on OpenVPN | 18:08 |
TJ- | bipul: also, double-check on C that forwarding is enabled on all the interfaces | 18:08 |
bipul | TJ-, Yes, it's enabled inside /etc/sysctl.conf net.ipv4.ip_forward=1 | 18:09 |
TJ- | bipul: how about "for n in /proc/sys/net/ipv4/conf/*/forwarding; do echo $n=$(cat $n); done " | 18:09 |
bipul | wait let me check,and share with you. | 18:09 |
bipul | TJ-, The problem is with tap mode , not with tun mode. | 18:10 |
TJ- | bipul: my strong recommendation is to deploy tcpdump on C, and later on D, and check whether it is replying, and if so, on which interface | 18:10 |
bipul | sure i would definitely follow your suggestion. And get back to you. | 18:10 |
TJ- | bipul: I realise that; tap is a virtual ethernet interface, but I'm recommending you check other things around this in case it gives clues. | 18:11 |
bipul | I'm new to this tcpdump, would you suggest any link to go with it. | 18:12 |
TJ- | bipul: wooa, on C, what is this about!? "route add -net 10.216.0.0 netmask 255.255.0.0 gw 10.4.0.1" ? | 18:14 |
bipul | https://paste.ubuntu.com/p/HNy6m59jc8/ | 18:15 |
TJ- | bipul: that is going to conflict with "10.216.21.0/24 dev enp0s3 proto kernel scope link src 10.216.21.1 " | 18:15 |
bipul | I believe 10.216.0.0/16 is network inside it i.e 10.216.0.0/16 { 10.216.21.0/24 } | 18:16 |
TJ- | bipul: on C: "sudo tcpdump -ni tap0 icmp" | 18:16 |
jelly | more specific routes take precedence, a route for /16 won't override a nested route for /24 | 18:16 |
TJ- | bipul: that 10.216.0.0/16 does NOT look correct; you're telling it to send packets for that subnet down tap0 (to A) | 18:17 |
TJ- | bipul: THAT rule should be executed on A, not C | 18:18 |
bipul | okay. So what would be for {C,D} to A | 18:18 |
jelly | TJ-: oh, here, have an idiom: grep . /proc/sys/net/ipv4/conf/*/forwarding | 18:18 |
bipul | okay. So what would be for {C,D} to A at C? | 18:19 |
TJ- | bipul: sorry, been at dinner; have you made progress. Just looked at A and I think this is wrong too (wrong gateway - should be the IP address of the interface at the far end of the tunnel) "route add -net 10.216.0.0 netmask 255.255.0.0 gw 10.4.0.2" so I'd expect it to be "route add -net 10.216.0.0 netmask 255.255.0.0 gw 10.4.0.1" | 18:49 |
bipul | okay, sure, i will try with your given solution. | 18:50 |
bipul | TJ-, Thank you. And i would let you know the outcome :) | 18:50 |
TJ- | bipul: I'll simulate your network in marionnet, see if I can reproduce | 18:55 |
bipul | Oh thank you very much. At this moment i'm doing some cryptanalysis,whole my vm is busy , i have less resource. Otherwise i would let you know the result. | 18:59 |
bipul | wow nice marionnet | 19:00 |
bipul | s/cryptanalysis/ studying crypto | 19:09 |
bipul | I will do it later, and let you know. :) | 19:09 |
bipul | TJ-, YES, it works | 19:52 |
bipul | it was routing issue :) | 19:52 |
TJ- | bipul: :) | 19:52 |
TJ- | bipul: simple when you think it through :P | 19:53 |
bipul | :) wow thank you very much sir | 19:53 |
cryptodan | you are welcome bipul | 20:01 |
kinghat | is there another way to mount a share other than cifs? | 20:41 |
kinghat | i guess node/npm over cifs doesnt function properly. | 20:42 |
kinghat | just wondering if mounting it via some other method would be a workaround? | 20:42 |
kinghat | specifically what happens when i try to install packages over the share: https://paste.debian.net/hidden/b15c702d/ | 20:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!