Let’s first talk about how it all started with and what we achieved.
It’s all started with a healthy discussion with a team where our team members were discussing many aspects of different fields of technology. So, one of our colleagues mentioned OpenVPN. So, we discussed the different working field, architecture, workflow of OpenVPN, in which role of iptables comes into the picture because for Linux architecture, OpenVPN support iptables as it’s primary firewall utility or can say OpenVPN support iptables as it’s a firewall for filtering workflow.
So in-between discussion, I mentioned that I am using iptables in OpenVPN to block traffic for the domain name and it is working fine. So, my colleague asked me about how you implemented & how is it possible to use iptables for domain and they discussed multiple logical explanations like OSI layer support and many other things. So, we decided to do POC of this discussion and try to write-up some blog or points to make clear that is it possible use iptables for the domain name and if not, what are the area that we can cover with iptables for the domain name and try to cover up flaws of this.
Continue reading “That’s Why Iptable Is Not A Good Fit For Domain Name?”
A BIG THANK YOU TO TRANSIT AND DIRECT CONNECT GATEWAYS
In everyone’s career path, this particular situation always comes when we think that everything will work out fine when, suddenly, out of the blue, we realize that a big issue is waiting to happen. We freak out about what are we gonna do before this issue knocks at your door ..Right?
Something similar happened to me some time ago, so let me cut to the chase. 🙂
I will explain why there is benefit in using transit and direct connect gateways by telling you what issues we faced without it.
This blog talks about the two possible ways of hosting your infrastructure in Cloud, though it will be more close to hosting on AWS as it is a real life example but this problem can be applied to any cloud infrastructure set-up. I’m just sharing my thoughts and pros & cons of both approaches but I would love to hear from the people reading this blog about their take as well what do they think.
Before jumping right away into the real talk I would like to give a bit of background on how I come up with this blog, I was working with a client in managing his cloud infrastructure where we had 4 environments dev, QA, Pre Production and Production and each environment had close to 20 instances, apart from applications instances there were some admin instances as well such as Icinga for monitoring, logstash for consolidating logs, Graphite Server to view the logs, VPN server to manage access of people.
At this point we got into a discussion that whether the current infrastructure set-up is the right one where we are having a separate VPC per environment or the ideal setup would have been a single VPC and the environments could have been separated by subnet’s i.e a pair of subnet(public private) for each environment
Both approaches had some pros & cons associated with them
Single VPC set-up
You only have a single VPC to manage
You can consolidate your admin app’s such as Icinga, VPN server.
As you are separating your environments through subnets you need granular access control at your subnet level i.e instances in staging environment should not be allowed to talk to dev environment instances. Similarly you have to control access of people at granular level as well
Scope of human error is high as all the instances will be on same VPC.
VPC per environment setup
You have a clear separation between your environments due to separate VPC’s.
You will have finer access control on your environment as the access rules for VPC will effectively be access rules for your environments.
As an admin it gives you a clear picture of your environments and you have an option to clone you complete environment very easily.
As mentioned in pros of Single VPC setup you are at some financial loss as you would be duplicating admin application’s across environments
In my opinion the decision of choosing a specific set-up largely depends on the scale of your environment if you have a small or even medium sized environment then you can have your infrastructure set-up as “All environments in single VPC”, in case of large set-up I strongly believe that VPC per environment set-up is the way to go.
Let me know your thoughts and also the points in favour or against of both of these approaches.
Recently I’ve been working on automating the nodes creation on our Linode infrastructure, in the process I came across the Linode API and it’s bindings. Though they were powerful but lacks at some places i.e:
In case of Linode CLI, while creating a linode you have to enter the root password so you can’t achieve full automation. Also I was not able to find an option to add private ip to the linode
In case of Linode API python binding you can’t straight away create a running linode machine.
Recently I’ve launched a new GitHub project, this project is a wrapper over existing python bindings of linode and will try to ease out the working with linode api. Currently using this project you can create a linode with 3 lines of code from linode import Linode linode=Linode(‘node_identifier’) linode.create()
You just need to have a property file,/data/linode/linode.properties:
KERNEL_LABEL=Latest 64 bit
The project is still in development, if someone wants to contribute or have any suggestions you are most welcome.
One of the suggested practices in cloud administration is to always host your applications on a Virtual Private Cloud. Also, you should have a public subnet hosting the public facing apps, and a private subnet which hosts the private apps (like a database or a back-end service/app). To know more about why you need such kind of a setup, please read more about VPC.
This blog will talk about a scenario where you have multiple Virtual Private Clouds (hereafter referred to as VPC), and you need to access a private app hosted in one VPC from another VPC. An example of this scenario could be that you have a VPC for your staging environment and another VPC for production environment, then you’d like to sync the database from of production environment from the staging environment. In this case, it might not be straight forward to do this, as you might not be able to access the production database from outside the production VPC.
One of the solutions for this problem would be to first take a dump of the production database on one of the public facing machines in the production VPC, and then copy that dump to a public facing machine in the Staging VPC and finally applying this dump to the private database of Staging environment. This approach will work, but it would not be a perfect solution, as you have to copy the db dump between VPC’s.
A much better approach would be if you could directly connect to the production database from the Staging VPC & execute the dump & restore command, for that you need direct access of production database from staging environment. This approach is called port-forwarding. We configure port-forwarding at one of the public facing machines(NAT is the preferred one) in the production VPC in such a manner that if a request comes on this machine at port x it will be forwarded to port y on a private facing machine in the production VPC which is the database production in this case.
In the next blog I will talk about other alternate approaches that can be used to solve this problem.