Question regarding a management VLAN. Should there be an IP address for every device you need to manage, or just enough addresses on the subnet for a few people to manage devices?
From Cisco Design Best Practices for VLAN:
A good security practice is to separate management and user data traffic. The management VLAN, which is VLAN 1 by default, should be changed to a separate, distinct VLAN. To communicate remotely with a Cisco switch for management purposes, the switch must have an IP address configured on the management VLAN. Users in other VLANs would not be able to establish remote access sessions to the switch unless they were routed into the management VLAN, providing an additional layer of security.
Often, admin workstations with access to the management VLAN do not have a direct connection but they are routed by a firewall.
Related
Could anyone please explain if by default (firewall application) all users can access DMZ? Or only inside users? Also, if the users will be added to the access control list?
The most common form of a DMZ is a kind of "proxy" network between your intranet (LAN) where all your clients are connected to and the WAN. Imagine you have a network with some web servers, PCs like laptops or workstations, and some other servers or services with databases or similar. In front of your LAN, there´s a firewall creating the gateway to the WAN.
If everything is inside the same network you'll have security issues since, if one machine gets compromised, basically everything will be possible.
As long as you're communicating in the same subnet, let´s say a class C network of 192.168.0.0 (IP-Range from 192.168.0.1 - 192.168.0.254) the traffic will not be routed to your gateway which is usually your firewall. Meaning that every request you do from 192.168.0.2 to 192.168.0.3 will not be monitored and/or restricted by your firewall. This is an issue.
Web servers for instance have to be accessible from the outside. If an attacker gets access to the server he could mess with anything in your network.
Now you introduce a DMZ, basically a proxy network between your LAN and the WAN (at least in most cases). Since it's an own subnet the traffic will be routed through your gateway (firewall) so your rules apply. Also, to get into the intranet the data has to pass two firewalls (or twice the same firewall). You can now create firewall rules that will allow or disallow the communication from servers or clients and vice versa in the DMZ to your actual LAN. This way you can define that every communication into your LAN is denied by default and then you start adding rules to allow communication, for instance, if some service has to connect to a database in your LAN or similar.
Many networks only filter inbound traffic that way but in my opinion, you should also deny all outbound traffic until approved by a firewall rule.
Also, depending on the situation, often the clients are in the DMZ as well-meaning only critical infrastructure is in your actual intranet. In this case, commonly only administrative users will have "full" access to the intranet itself. Generally, it's a good idea to put the clients in a separate, restricted network since you'll often get to points where the clients are the biggest vulnerability for your network (Like users who like to open word documents clearly being some kind of fraud and similar)
I'm not sure if I understand the purpose of OpenStack Neutron management subnet right.
OpenStack docs suggest that it is a VLAN that is created to let OpenStack components to talk to each other and also allows me to SSH into the host (physical machine).
I assumed that upon splitting a network interface into VLANs for OpenStack, I abandon the IP address, assigned to that physical interface in untagged l3 network (say, 10.100.70.), and instead split it into 3 VLANs, and again get an IP address from my provider infrastructure in another provider subnet on this logical interface (say, 10.100.71.).
But here is a page that explains how to install OpenStack with InfiniBand, and it makes use of both management VLAN and PXE/admin interface. So I keep an IP in the untagged PXE network and also create a tagged management VLAN and get IP addresses on both.
Aren't PXE/admin network and management VLAN network redundant here?
I am making a game in Libgdx where a user(client) will be a host of the server himself
and only one other client can connect to him and play with him(likewise there might be multiple independent servers and pair of clients playing with each other like miniclip games)
but how will the other client locate host-client (or servers) IP?
I am using kryonet
Some guy suggested me to do NAT punching and stuff but I am totally confused.
Please help
(I am complete beginner to networking)
If you want your clients to discover servers just in LAN, you can do broadcasting on the servers and sniffing on the clients. As they are in the same LAN, there should be no need for NAT.
Otherwise, you have to set up managers(servers for managing) on the Internet. Servers have to register themselves to a manager, clients ask a manager for servers information. As managers know both servers and clients public IP addresses, NAT should be easy once you think your managers as STUN servers.
The most simple manager can be just a simple wraper over database/Redis with a server name/server ip/server metadata table. Details about how to implement it relies on your skill stack. To enable STUN, there are open source STUN server and client you can just pick up, e.g. coturn. No matter you put the STUN server into your manager or not, both your managers and STUN servers have to be published on the Internet (sure include AWS) where they have their own public IP.
Or you can let the managers to relay messages for servers and clients. But this way may be too complicated compares to previous. I would not recommend.
I have 3 devices each of them have Mosquitto broker running on them. Each of this device has subscriber and publisher.
I am using IP of each device to open port at 8883 and exchange messages --> subscribe/publish their messages. If the case happens to be that devices use dynamic IP., How can I publish new IP-PORT address to its clients that are already connected? How to tackle this problem. Is my approach correct? Is there any other way I can create my own private IP-PORT address to the broker?
Your broker needs to be reachable at a known location, be that fixed IP address or a DNS entry that points to it's current IP address.
Any clients connected at the time the IP address changes will be disconnected and will need to reconnect.
You've not said if these are all on the same LAN or spread across the internet, but either way you need some sort of dynamic DNS solution.
If the devices are all on the same LAN then you can use Avahi/mDNS/Bonjour to discover the current address of the device in the .local domain. Each broker will need to have a unique name.
If you are in a none lan environment then you will need to use a proper Dynamic DNS solution and have each broker have a unique fully qualified DNS name that the host machine can update when ever it's IP address changes.
Both of these solutions are more network admin solutions than programming questions so I suggest you ask on SuperUser if you have follow up questions.
There is a 3rd option, which is to have a 4th broker on a fixed IP address that acts as a central bridge for all the other brokers.
I have been looking for an answer to this problem, but I cannot find what I am looking for. I think, perhaps, it is because I lack the knowledge to ask the question in meaningful way.
I have been learning a lot about remote access to devices at home. I know that ISP's change public IP addresses regularly (dynamic IP address). I know that to get around this, one could use a service like "no-ip", etc. Or one could get a static IP address.
What I do not understand is how some of the latest home automation devices are able to be controlled remotely without use of a static IP, or a service like "no-ip". For example, a wifi enabled thermostat, or lighting system.
If the device had a built in server, or client, then I assume that the device could connect to an outside server in a remote location. The user could then also log into that server and send commands to the device. What I don't understand is how commands sent to the device from a cell phone, for example, can reach the home device. Presumably the off site location of the server would have to know the public IP address where the devise is located, and then port-forwarding would have to be set up to allow access to the device.
What am I missing here? Is it possible to create a homemade wifi enabled thermostat, webcam, or other device without using port-forwarding, no-ip, or a static IP?
Well, there are several ways to bypass the inbound connection constraint of NAT protocol. Such as:
A virtual adapter on the device configured to a VPN server that has an inbound port open ready to transfer data. Various open source solutions such as openVPN are considered as great examples for this service over IOT boards like Raspberry Pi, Beagle Bone, etc. These are used as gateways often. Further, they communicate with the microcontrollers over popular IOT protocols such as MQTT, COAP, etc.
Another solution is to create a port forwarding tunnel, since the router won't block the outbound connection. There are various tunneling services that are availble such as localtunnel, ngrok, etc. You could also use a cloud server that has a public IP such as AWS, DigitalOcean, etc. Again as above mentioned point, they can be implemented in the gateways.
Some devices "phone home" to a server so that there are ports open between them and the servers, and the mobile apps just contact the servers. This is the same way your web browser can receive web pages from a web server. If you have a NAT router, the router must open a port from the inside device to the outside server. This is maintained in a NAT table with expiration timers for UDP and session monitoring for TCP.