How to identify the internet status of the computer using Blue Prism - blueprism

So that we can identify the status and proceed accordingly. Otherwise we have to face unwanted errors

SHORT ANSWER
By using the provided Utility - Network object's Ping action to run three ping tests for analysis.
CORRECT ANSWER
By using the provided Utility - Network object's Ping action to run three ping tests for analysis BUT this wholly depends on the network setup of your resource PC.
As well if you have any kind of Firewall configured to block ICMP packets a result will be that you can not send ICMP echo request packets to external networks.
However, let's say you know your network architecture enough to be certain the resource PC can directly send and receive packets. If that were the case then Solution 1 will work.
IF your resource is well and rightly insulated within your organizations network BUT are confident that your network exit points are always connected to the internet AND know your domain network name or IP Solution 2 will work.
Solution 1
ping google.comTo test that DNS is working on the resource
ping 8.8.8.8 To test that resource's TCP/IP settings are correct
ping 127.0.0.1 Loopback test to make sure there's nothing wrong with the resource's network adapter or connection settings
Depending on your requirements you can also directly ping the endpoint addresses your bot needs to communicate with. This would be especially useful if the bot is not using a browser-based application, but rather sending emails.
Solution 2
ping {yourdomainnetwork}.comTo test that DNS is working on the resource
ping {yourdomainnetwork IP} To test that resource's TCP/IP settings are correct
ping 127.0.0.1 Loopback test to make sure there's nothing wrong with the resource's network adapter or connection settings

Related

Mininet Ping issue

Is it possible to ping mininet ip? I found mininet's ip starts with 10.0.2.15 . I can ping from mininet to others. However, I failed to ping other place to mininet. How can I setup this?
10.0.0.0/8, which is 10.0.0.0 - 10.255.255.255 are IP addresses used only locally, they are not accessed from the internet (other networks). Here is some info from IANA:
These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hundreds of millions of devices. They are only intended for use within a private context and traffic that needs to cross the Internet will need to use a different, unique address.
These addresses can be used by anyone without any need to coordinate with IANA or an Internet registry. The traffic from these addresses does not come from ICANN or IANA. We are not the source of activity you may see on logs or in e-mail records.

Test setup on AWS to test TCP transparent proxy (TPROXY) and spoofing sockets

I'm developing a proof-of-concept of some kind of transparent proxy on Linux.
Transparent proxy intercepts TCP traffic and forwards it to backend.
I use https://www.kernel.org/doc/Documentation/networking/tproxy.txt and spoofing sockets for outgoing TCP connection.
On my dev PC I was able to emulate network using Docker and all works fine.
But I need to deploy test environment on AWS.
Proposed design:
Three VMs within the same subnet:
client, 192.168.0.2
proxy, 192.168.0.3
backend, 192.168.0.4
On client I add route to 192.168.0.4 thru 192.168.0.3
On proxy I confugure TPROXY to intercept TCP packets and forward it to backend with 192.168.0.2 IP source address. Here our transparent proxy works.
On backend I run simple web server. Also I add route to 192.168.0.2 thru 192.168.0.3 otherwise packets will go back directly to 192.168.0.2
The question:
Will proposed network design work as expected?
AWS uses some kind of software defined network and I don't know will it work in the same way as I would connect 3 Linux boxes to one Ethernet switch.
Will proposed network design work as expected?
Highly unlikely.
The IP network in VPC that instances can access is, from all appearances, an IP network (Layer 3), not an Ethernet network (Layer 2), even though it's presented to the instances as though it were Ethernet.
The from/to address that is "interesting" to an Ethernet switch is the MAC address. The from/to address of interest to the EC2 network is the IP address. If you tweak your instance's IP stacks by spoofing the addresses and manipulating the route tables, the only two possible outcomes should be one of these: the packets will actually arrive at the correct instance according to the infrastructure's knowledge of where that IP address should exist... or the packets will be dropped by the network. Most likely, the latter.
There is an IP Source/Destination Check Flag on each EC2 instance that disables some of the network's built-in blocking of packets the network would otherwise have considered spoofed, but this should only apply to traffic with IP addresses outside the VPC supernet CIDR block -- the IP address of each instance is known to the infrastructure and not subject to the kind of tweaking you're contemplating.
You could conceivably build tunnels among the instances using the Generic Route Encapsulation (GRE) protocol, or OpenVPN, or some other tunneling solution, and then the instances would have additional network interfaces in different IP subnets where they could directly exchange traffic using a different subnet and rules they make up, since the network wouldn't see the addresses on the packets encapsulated in the tunnels, and wouldn't impose any restrictions on the inner payload.
Possibly related: In a certain cloud provider other than AWS, a provider with a network design that is far less sensible than VPC, I use inter-instance tunnels (built with OpenVPN) to build my own virtual private subnets that make more sense than what that other cloud provider offers, so I would say this is potentially a perfectly viable alternative -- the increased latency of my solution is sub-millisecond.
But this all assumes that you have a valid reason for choosing a solution involving packet mangling. There should be a better, more inside-the-box way of solving the exact problem you are trying to solve.

Find network interface that is communicating with gateway without using PING/ ICMP or UDP

I have a RHEL client machine which has to get data from the RHEL server machine at the time of booting up.
The IP address of the server is known.
The gateway which has to be used by the client machine is known.
The client machine has multiple network interfaces. All may not be up at the same time or all may be connected to different networks.
I need to determine which network interface has to be used.
I know that this can be easily done using the "ping" or "traceroute".
The issue is ICMP protocol is disabled both at the client end as well as the server end.
ICMP has been disabled due to security concerns.
ICMP may be disabled at machine level or it may be disabled for the whole network.
In otherword, I need to find a way that can give me if two ip's are communicating if ICMP is disabled.
Also, I have to use this result in my script, which I am writing in bash, to set the network of the client machine.
What is the best possible way to achieve this?
You can ping the ip with ARP try using arping command

Cannot send or receive packets from my VirtualBox debian linux VM using UDP

For the sake of simplicity, I will refer you to http://en.wikipedia.org/wiki/Berkeley_sockets and the UDP server and client source code there.
I am trying to send a packet using UDP protocol to a linux VirtualMachine server program. Both my host and VM ping well; all packets sent are received in both directions. However my server program is either not receiving any packets, or it is simply not printing. Either way, it isn't printing the confirmation or contents of any packets I send to it from the host.
I do not have another PC handy, but both programs communicate well enough if I stage them on the same computer and Wireshark reports that the packets are being sent.
Mine is a three part question: first, how can I fix this. Second, why would the host and VM receive each others ping messages, but not pass these on to the open sockets of both ends of my UDP system? Finally, do you have any suggestions about the form or intent of this question?
EDIT: I've tried running my VM with the NAT and bridged adapter network setups. However, I can't conceptualize the relationship between those setups and my problems right now.
With NAT networking, the VM gets a private IP address (usually 192.168.x.y) and the host does NAT translation of outgoing packets, and translates reply packets back to the VM. In this mode, all communication must be initiated by the VM -- outside machines can only send packets to the VM in reply to packets the VM sent to them. On the network, the packets will look like they're coming from/going to the host on some unrelated port.
With bridged networking, the VM gets a device that connects directly to the host's network device. In this mode, the VM appears as a separate machine on the same network LAN as the host, with its own IP address. You need to allocate an IP address for it, the same as the host get allocated an IP address (usually via DHCP).
In either case, to debug what is going on, use tcpdump/wireshark on the host to monitor the host's network device. Send packets from the VM, and you should see them in the trace -- they'll appear to come from the host and a different port in the NAT case, and will appear to come from the VM's IP address (and unchanged ports) in the bridged case.
Once you see that, you should be able to send packets back to the VM, though in the NAT case, they must come FROM the address/port the original packet(s) were sent to.
There are known issues with VirtualBox bridged networking not working properly on wifi devices; in general you can only use bridged networking with wired networks.
Oracles VB manual page clear all the terminology used in settings.
I've had similar problem, where my VB program didn't receive any packets, which I solved by setting "Bridged Networking" and setting up proper source/destination IP address in my program by analyzing WLAN interface with wireshark and using ifconfig (or ipconfig) in terminal.

How to enable Ping(ICMP) on Azure

In Windows Azure role, I cannot ping out
D:\Users\foglight>ping www.google.com
Pinging www.l.google.com [209.85.143.104] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 209.85.143.104:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
I google it and found some one suggest run below command, but even after run it, I still can not ping out
netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6
Please someone tell me the reason and how to walkaround.
I don't believe you can do this. Traffic leaving the data center goes through the load balancer, and the load balancer only routes TCP-based traffic.
I know this question is very old, but I stumbled upon it while facing the same issue and there is an actual solution for it now in Azure.
When setting up your Virtual machine you can assign it an "Instance IP address". Once that has been configured, you can enabled ICMP in and out in the local firewall. You will then be able to ping out of your Azure VM and also use tools like traceroute.
I had a similar problem. Needed to assign public IP to Azure VM in order to enable ICMP. I used set-azurepublicip and update-azurevm and resolved the issue.
I also had problems to do traceroutes from my azure VM and to ping it.
Just wanted to let you know, that after you have a public IP assigned to the VM (which is in many cases the default), you also need to add ICMP Rules to your network security groups (NSG) (if you have any, which you should).
If you have a NSG on the vnet and a NSG on the VM network interface, you should create 4 rules that allow ICMP (vnet-in, vnet-out, vm-in, vm-out).
Selecting "Any" as protocol, will not work.
The default rule for internet access seems to be not sufficient.
You need to select ICMP. "Any" seems to be only UDP+TCP.
I set the source and destination port to "*" (not sure if it even has any effect if ICMP is selected).
After that and a little wait (~1-2 min), I could ping and trace in every direction :)

Resources