I am trying to configure my Linux server to connect via a VPN using the following command:
sudo pppd pty "pptp UKIPVPN.com --nolaunchpppd" file /etc/ppp/options.pptp user ukipvpn.com password freevpn
Using ifconfig I can confirm the pppd connection is established:
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.162.0.74 P-t-P:10.162.0.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1496 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:60 (60.0 B) TX bytes:66 (66.0 B)
I have added the ppp0 to the route using:
$ sudo route add default ppp0
The issue I have is that the VPN normally serves a HTML 'I accept' page before allowing a connection to the internet.
The page is served every time I try and connect to any pages from the CLI:
curl ipecho.net/plain
<html>
<head><title>UFreeVPN.COM Service from UK</title></head>
<br>
<br>
<font color=blue><center> <h1>UFreeVPN.COM Service from UK</h1> </center></font>
<center><h2><a href='http://uk.ufreevpn.com'>I Agree</a> to use the Free VPN Service</h2></center>
<center><font size='2'>No illegal activities allowed. In case of abuse, users' VPN access log is subjected to expose to related authorities.</font></center>
Is there a way I can 'Agree' from Bash to allow this connection to work?
EDIT:
Having checked the source of the "I agree" page it is just as returned by curl above with no Javascript etc.
On clicking I agree you get auto redirected to http://www.ukipvpn.com.
I tried the following:
curl http://www.ukipvpn.com
and curl http://www.ukipvpn.com -e--referer
but each time i try and grab a page with curl then I am presented with the "I agree" page from the vpn.
So after reading around slightly more on curl the key is to use the POST data function:
curl --data "button=%20I%20AGREE%20&sessionid=<SESSION ID HERE>" http://www.ukipvpn.com
Now the VPN accepts requests and is working. Thanks for the help.
http://curl.haxx.se/docs/httpscripting.html
Related
Question 1 :
1.1. who is sitting behind the "openshift_master_cluster_public_hostname" hostname ? is it the web console ( web console service ? or web service deployment ) or something else ?
1.2. when doing oc get service -n openshift-web-console i can see that the web console is runnung in 443 , isn't it supposed to work on port 8443 , same thing for api server , shouldn't be working on port 8443 ?
1.3. can you explain to me the flow of a request to https://openshift_master_cluster_public_hostname:8443 ?
1.4. in the documentation is
Question 2:
why i get different response for curl and wget ?
when i : curl https://openshift_master_cluster_public_hostname:8443 , i get :
{
"paths": [
"/api",
"/api/v1",
"/apis",
"/apis/",
"/apis/admissionregistration.k8s.io",
"/apis/admissionregistration.k8s.io/v1beta1",
"/apis/apiextensions.k8s.io",
"/apis/apiextensions.k8s.io/v1beta1",
...
"/swagger.json",
"/swaggerapi",
"/version",
"/version/openshift"
]
}
when i : wget https://openshift_master_cluster_public_hostname:8443 i get an index.html page.
Is the web console answering this request or the
Question 3 :
how can i do to expose the web console on port 443 rather then the 8443 , i found several solution :
using variables "openshift_master_console_port,openshift_master_api_port" but found out that these ports are ‘internal’ ports and not designed to be the public ports. So changing this ports could crash your OpenShift setup
using an external service ( described here )
I'm kind of trying to setup port forwarding on an external haporxy , is it doable ?
Answer to Q1:
1.1. Cite from the documentation Configuring Your Inventory File
This variable overrides the public host name for the cluster,
which defaults to the host name of the master. If you use an
external load balancer, specify the address of the external load balancer.
For example:
> openshift_master_cluster_public_hostname=openshift-ansible.public.example.com
This means that this Variable is the Public facing interface to the OpenShift Web-Console.
1.2 A Service is a virtual Object which connects the Service Name to the pods and is used to connect the Route Object with the Service Object. This is explained in the documentation Services. You can use almost every port for a Service because it's virtual and nothing will bind on this Port.
1.3. The answer depend on your setup. I explain it in a ha-setup with a TCP loadbalancer in front of the masters.
/> Master API 1
client -> loadbalancer -> Master API 2
\> Master API 3
The Client make a request to https://openshift_master_cluster_public_hostname:8443 the loadbalancer forwards the Client to the Master API 1 or 2 or 3 and the Client get the answer from the requested Master API Server.
api server redirect to console if request come from a browser ( https://github.com/openshift/origin/blob/release-3.11/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver/patch_handlerchain.go#L60-L61 )
Answer to Q2:
curl and wget behaves different because they are different tools but the https request is the same.
curl behavior with wget
wget --output-document=- https://openshift_master_cluster_public_hostname:8443
wget behavior with curl
curl -o index.html https://openshift_master_cluster_public_hostname:8443
Why - is described in Usage of dash (-) in place of a filename
Answer to Q3:
You can use the OpenShift Router which you use for the apps to make the Web-Console available on 443. It's a little bit outdated but the concept is the same for the current 3.x versions Make OpenShift console available on port 443 (https) [UPDATE]
I setup ssl on localhost (wamp), I made the ssl crt with GnuWIn32.
When I try to login with fb in Chrome I get the following message:
URL:
https://localhost/ServerSide/fb-callback.php?code=.....#_=_
Error:
Your connection is not private.
Attackers might be trying to steal your information from localhost (for example, passwords, messages, or credit cards). NET::ERR_CERT_INVALID.
localhost normally uses encryption to protect your information. When Chrome tried to connect to localhost this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be localhost, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Chrome stopped the connection before any data was exchanged.
You cannot visit localhost right now because the website sent scrambled credentials that Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later.
My SSL Config:
Listen 443
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLPassPhraseDialog builtin
SSLSessionCache "shmcb:c:/wamp/www/ssl/logs/ssl_scache(512000)"
SSLSessionCacheTimeout 300
<VirtualHost *:443>
DocumentRoot "c:/wamp/www"
ServerName localhost:443
ServerAdmin admin#example.com
ErrorLog "c:/wamp/logs/error.log"
TransferLog "c:/wamp/logs/access.log"
SSLEngine on
SSLCertificateFile "c:/wamp/www/ssl/ia.crt"
SSLCertificateKeyFile "c:/wamp/www/ssl/ia.key"
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory "c:/Apache24/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-5]" nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog "c:/wamp/logs/ssl_request.log" \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
My question is how to setup valid SSL certificate on localhost? or do I need to edit my configuration?
Allow Insecure SSL (localhost)
In Chrome (including Version 110), enable allow insecure localhost:
chrome://flags/#allow-insecure-localhost
Refer to this Stack Overflow for more information.
Allow Insecure SSL (other)
See "Your connection is not private. blah-bla-blah"...
Type thisisunsafe (key listeners pick it up).
Notes
If you are just curious if this works, browse this site which has a bad root ssl certificate. Other "bad ssl" sites can be found using badssl.com.
More about the chromium "override keyword":.
This is specific for each site.
The chrome developers also do change this periodically.
The current (v110) BYPASS_SEQUENCE is dGhpc2lzdW5zYWZl (which is base64 encoded).
1. When you see "Your connection is not private...NET::ERR_CERT_INVALID" warning on Chrome,
2. Just type "thisisunsafe" and wait.
Note: Last time this was tested, Chrome latest version was 107.0.5304.107
Your connection is not private
Attackers might be trying to steal your information from 10.10.10.10 (for example, passwords, messages or credit cards). Learn more
NET::ERR_CERT_INVALID
Type “badidea” or “thisisunsafe” directly on same chrome page.
Do this if you REALLY SURE about the link you are trying is safe. In my case I was trying to setup stackstorm locally using vagrant and virtualbox
Chrome version: Version 92.0.4515.131 (Official Build) (x86_64).
Source
I have added mod_apns to my ejabberd server. You can find this module here.
my ejabberd.yml configuration is like this:
mod_apns:
address: "gateway.sandbox.push.apple.com"
port: 2195
certfile: "/Applications/ejabberd-15.10/conf/cert.pem"
keyfile: "/Applications/ejabberd-15.10/conf/key.pem"
password: "myPassword"
the address is sandbox since I am still in development phase. And I have tested my cert.pem and key.pem and they are valid and working.
I send my device token to ejabberd server like this:
<iq type="set" to="myEjabberdServer.com">
<register xmlns="https://apple.com/push">
<token>myDeviceTokenWithoutAnySpace</token>
</register>
</iq>
I can see my device token is saved in apns_users database.
But I still do not get notifications when my user is offline.
Am I doing anything wrong?
Does it work with gateway.sandbox.push.apple.com?
should my device token be without space and only characters?
I appreciate your help..
You have asked for an alternate approach. This alternate approach takes the process of triggering push notifications by the ejabberd server.
1. Use the mod_interact library. This will provide you an ability to transfer your messages to another url.
2. From there on you can use the direct HTTP call for push notifications
I cannot reliably trigger this, although if I spin up many vms at a time and then attempt to connect to some of them, I run into this condition:
$ ping 192.168.122.135
PING 192.168.122.135 (192.168.122.135) 56(84) bytes of data.
From 192.168.122.1 icmp_seq=1 Destination Host Unreachable
From 192.168.122.1 icmp_seq=2 Destination Host Unreachable
From 192.168.122.1 icmp_seq=3 Destination Host Unreachable
Note that this does not happen for all VMs that I create and start, only a handful of them (randomly).
The vm that has obtained the ip 192.168.122.135 has the following for its network in its domain xml:
<interface type='network'>
<mac address='52:54:00:3d:72:ab'/>
<source network='default'/>
<target dev='vnet0'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</interface>
And the default network is defined as (and yes, 22 vms are currently running):
<network connections='22'>
<name>default</name>
<uuid>69674b8b-f067-4513-b594-3e52360f391b</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr0' stp='on' delay='0'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>
The output from ifconfig for vnet0 (referenced by the VM's network domain xml) and virbr0 (used by the default network as shown above):
$ sudo ifconfig vnet0
vnet0 Link encap:Ethernet HWaddr fe:54:00:3d:72:ab
inet6 addr: fe80::fc54:ff:fe3d:72ab/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:425 errors:0 dropped:0 overruns:0 frame:0
TX packets:1304 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:57503 (57.5 KB) TX bytes:67257 (67.2 KB)
and
$ sudo ifconfig virbr0
virbr0 Link encap:Ethernet HWaddr fe:54:00:08:e9:a4
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:882508 errors:0 dropped:0 overruns:0 frame:0
TX packets:2527165 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:93980992 (93.9 MB) TX bytes:3047773583 (3.0 GB)
Below is the partial output from ip route list:
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
The route output above makes me think that it should be working. BUT ITS NOT. and it only fails sometimes, and works most of the time.
Why can't I connect to the guest (192.168.122.135) from the host??
I was originally using filters, but removing the filters from the VM's domain xml has no effect on this condition randomly showing up. If I spin up many VMs at the same time I can get it to happen to a lot of them. Some of the VMs work just fine though and allow me to connect.
Also, I am using ubuntu 14.04.3:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
With kernel 3.19.0-30-generic.
More info - virsh version:
$ virsh --version
1.2.2
libvirtd version:
$ libvirtd --version
libvirtd (libvirt) 1.2.2
I don't have enough reputation to comment... But I have a few suggestions on things you could try to further explore the problem.
Question: Does assigning an IP address in the 192.168.122.X subnet on vnet0 do anything? The route that is configured seems to suggest that your traffic will go to virbr0 since it has the 192.168.122.1 IP address. If you can't ping any other devices in that subnet, then I suspect that's the issue.
If that doesn't get you anywhere...
Packet trace on host / VM
Try doing a packet dump on virbr0 and on the internal VM interface when this occurs. Ping the VM, and see what kind of traffic you see.
sudo tcpdump -n -i virbr0 -v "icmp or arp"
Depending on what you see there, will help narrow down the source of the problem. If you're not even getting your pings on that interface, then it's a routing issue on the host. If pings are going in, but the VM isn't seeing them, then it's a network/routing issue with the libvirt network.
I recommend also doing the above with a working VM, so you have a reference to compare the traffic against.
Check ARP Cache
Check your ARP cache on the host when this occurs. Does the mac address exist in the cache? Maybe it's getting mangled...
To dump the arp cache:
# arp
Check your libvirt logs
If configured, libvirt will log to syslog using the 'libvirtd' tag. Check your configuration to be sure this is enabled. It seems unlikely it's a libvirt issue, but it wouldn't hurt to turn on the logging.
To enable this setting
# vi /etc/libvirt/libvirtd.conf
Add the line
log_outputs_"1:syslog:libvirtd"
Restart libvirt
# service libvirt-bin restart
I had similar issue. I just tried following command to check whether machine is installed properly or not.
lsmod | grep kvm
If it is showing kvm details then machine is installed properly.
After that to restart the services
service libvirtd restart
Also check gateway using the below command
netstat -rn
I have the same network setting, and similar problem in a CentOS 7 host. Eventually, it turned out that the problem was guest VM's firewall setting blocked echo request and other external connection. After changing the firewall setting, the problem is solved.
My case, I've a hardware server where Libvirt is installed.
On this server I create VM in where install libvirt and after that I've get random network interruption and ping response with 192.168.122.1:
From 192.168.122.1 icmp_seq=1 Destination Host Unreachable
I've fixed this be deleting default libvirt network on hardware server like this:
virsh net-destroy default
virsh net-undefine default
Note: This is a question related to Bluemix Container service, it is not generic to Docker.
I have a linux environment with cf and ice tools installed and working correctly with US_SOUTH Data Center. I changed the login parameters to UK Data Center and now, although it login correctly to Container service it fails when executing any command with 404.
Command failed with container cloud service
404 Not Found: Requested route ('api-ice.eu-gb.bluemix.net') does not exist.
I did the login following documentation:
ice login -a https://api.eu-gb.bluemix.net -H https://api-ice.eu-gb.bluemix.net/v2/containers -R registry.eu-gb.bluemix.net
And as I said the login is successful.
Try this for London:
ice login -H containers-api.eu-gb.bluemix.net -R registry.eu-gb.bluemix.net -a api.eu-gb.bluemix.net
For US South:
ice login -H containers-api.ng.bluemix.net -R registry.ng.bluemix.net -a api.ng.bluemix.net
api-ice.eu-gb.bluemix.net should throw a 404. When we closed our our public beta we changed our API server to use the containers-api.{domain} pattern. (While temporarily leaving api-ice.ng.bluemix.net available for folks needing to migrate from the beta.)
We are currently updating the docs. Thanks for pointing this out.