I have installed the openvSwitch server on my two centos server (KVM). I have created two VM’s and bridged using openvSwitch. I am able to ping between the two VM’s. I am using VLAN for differentiating the private network.
Below is the VM IP
VM1 IP : 198.0.0.2 (resides in host1)
VM2 IP : 198.0.0.3 (resides in host2)
VLAN: 1000
I have followed the steps from the below link to configure the openvSwitch and it works fine.
http://openvswitch.org/support/config-cookbooks/vlan-configuration-cookbook/
Now I want to block few ports. I want to block the incoming traffic to the port 443, 80 for the VM1. One option is I can modify the iptables in my VM to drop the traffic to the ports. But I don’t want to modify the firewall rules in the VM. I want to drop the packets from the OVS integration Bridge itself.
Thanks,
Kalpeer
Related
I am in need of creating an overlay network to connect the VMs of two KVM hosts with each other.
The tutorial at OpenvSwitch explains it pretty well [1], but I do have one restriction. Host A can only reach host B via SSH on Port 22. All other outgoing connections and ports are blocked.
I have established an SSH tunnel with port forwarding between the two hosts and would need to send the OpenvSwitch traffic over that SSH tunnel. The problem is, the command for creating the SSH tunnel requires me to specify the IP of the tunnel endpoint:
ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote_ip=<IP of eth0 on host2>
Since I am using port forwarding I would need to insert "localhost" here and specify the forwarded port. This option, however, does not exist.
How can I create an overlay network between two hosts that are only connected via an SSH tunnel?
I tried to create tap interfaces with socat on both sides from [2] and added these tap interfaces to the OpenvSwitch bridge br0 that I created. Maybe this would eliminate the need for the GRE tunnel, if traffic is routed via the socat tunnels instead?
Thanks,
Nils
[1] https://docs.openvswitch.org/en/latest/howto/tunneling/
[2] https://gist.github.com/cfra/752d6e761225fd5bf783b44abe30f707
I am not able to send/receive messages with public IP in Kafka. I tried by changing IP with private and public. I also tried by changing advertised.host.name to 0.0.0.0.
What am I missing in Kafka ?
I suppose you are running Kafka on one machine and trying to access it from other machine.
It can be debugged as follows:
Try pinging the public IP from your machine. ping public_ip
If ping works, then try doing a telnet to that public IP along with the Kafka bootstrap server port.
For example, telnet 1.2.3.4 9092
If you are able to telnet means, that you are able to connect to the public IP (here, 1.2.3.4) and port from your machine.
If you are not able to connect, check your iptables rules on your Kafka server. You may want to allow the port to be accessible from outside.
Example to allow 9092 port.
iptables -A INPUT -p tcp --dport 9092 -j ACCEPT
You may also want to check if any firewall is blocking access like UFW or firewalld. Try disabling them or allow Kafka port there and check.
If you are using OpenStack or similar software, you may want to check Security group rules there and allow those ports. This can be applicable to AWS also.
Check that your advertised.listeners have the public IP which you are using to connect to. By default this property is found in etc/kafka/server.properties file.
Change it to something like (if you are using PLAINTEXT)
advertised.listeners=PLAINTEXT://<PUBLIC_IP>:<PORT>
For example,
advertised.listeners=PLAINTEXT://1.2.3.4:9092
advertised.host.name seems to be DEPRECATED now (see documentation)
in some cluster environments, there are pair servers that are HA 2 by 2. for example i have server1 with IP 22.1.1.1 and server2 with IP 22.1.1.2.
server1 is giving service and server2 is standby. there is this virtual IP 22.1.1.3 that other servers connect to it to get services from server1 and server2.
now i need to monitor this virtual IP to see if it is up and other servers outside its VLAN can connect to it. how i can do this in zabbix?
i don't have an actual physical server to create in zabbix according to this question. i tried to create one but i got errors. also this question is asked 3 years ago. is there any new features i can use to solve this problem?
You can create a host with agent ip 22.1.1.3 and monitor it in agentless mode.
You can ping it (icmpping), connect to a tcp port that you know it's open (net.tcp.service) or, in case of a web service, do a http call with the http agent and react accordingly.
Just create the correct items/templates according to the simple check and http agent documentation.
You do not need a physical server to create a host.
You can create a host with the target IP address and use various items against it - based on your question, you do not need agent items, but some other (remote) type.
https://github.com/coturn/coturn/blob/c4477bfddd2cd51de1ad37032ca88330f3c44ed6/docker/coturn/turnserver.conf#L100
In turnserver.conf , I see a world " For Amazon EC2 users", if the external-ip is only used for aws?
I let the stun server run in the k8s cluster, and then expose it to the public network with the nodeport service, but the srflx returned by stun is a gateway address, not the external-ip which I set. My k8s cluster runs on Alibaba Cloud.
I hope someone can help me solve this problem, thank you！！！
AWS EC2 instances, for the most part, run behind a NAT. Even if you've assigned a public IP address (e.g. 1.2.3.4) via the AWS Console, the instance only knows about the private network its on and is unaware of the public IP address assigned to it. That is, the instance thinks its IP address is 172.31.5.6 because that's what the Operating System discovered at boot time. Port forwarding enables certain TCP and UDP ports to be forwarded from the public IP address to the private IP address that the EC2 instance is running on.
This typically isn't a problem for most services run on an AWS EC2 instance. With STUN running in full "2 IP address and 2 port mode", the server needs to advertise its alternate IP address back to the client, should the client want to conduct NAT behavior and filtering tests. But it would be incorrect for the STUN server to send back 172.31.5.7 as its alternate IP - the client has no way of reaching that IP since its private.
Similarly for TURN, when port allocations occur, the server needs to send back the public IP address of the EC2 isntance to the client who allocated it. It would be bad if the client requested a TURN port to share with another peer - only for the TURN srever to send back 172.31.5.6.
Hence, for a STUN or TURN server to be hosted behind a NAT, a set of command line parameters or configuration parameters are needed to tell the server what its "real" IP addresses are. The STUN/TURN software will use these IP addresses for sending responses back to clients.
mongodb has bind ip but it is not so practical due to when new server add, it need shutdown db and add the new server ip into bind ip list and restart db. This is unacceptable because all other servers need to relaunch either.
In almost all deployment, servers machine and db machine are in same LAN. So can mongodb be configured as only accept ranges of ip of [172.16.0.0 - 172.31.255.255], [192.168.0.0 - 192.168.255.255], [10.0.0.0 - 10.255.255.255]?
These 3 ranges ip is LAN ip
The bind_ip configuration value only determines which IP address(es) your MongoDB server is listening to. It does not control access from remote IPs -- that is the job of a firewall.
The address ranges you have listed as requiring remote access are all private IP address space which means these networks are not directly reachable/routable outside your LAN. Assuming you can route traffic between your private networks you should not need to bind to multiple IP addresses.
Given you are allowing access from a broad range of IP addresses, you should also read the Security section of the MongoDB manual (in particular, the Security Checklist and tutorial on enabling Access Control).
bindIp can accept multiple comma separated values. See the "Security considerations" section Here
Other than that you might want to consider configuring your firewall, maybe iptables if it runs on Linux machine.
Hope this helps