The story of the mobile Internet. Paranoia or have something to think about?
Good day, colleagues.
Just want to make a reservation that this note ... this is just a note on some technical problem, which, as it seems to the author, has something to do with the subject of the section where it is published.
Here, habrahabr.ru/post/148200 has already touched on the topic of proxying through free VPN services, now we will focus on the mobile Internet.
')
In general, the author of the note didn’t overlap with such “beasts” as GPRS / 2G / 3G and so on. But once had to.
Once on one remote object the channel disappeared (or rather all the channels) to the head object. And it was very bad. An interim solution was urgently needed and considering the whole mass of accompanying factors (very unhappy), nothing “dance” was better than pptp via the usual USB “whistle”. But will it work? And the author notes and colleagues "in the shop" took doubts. Come mobile operator cuts the whole thing. But decided to try. Have tried. When the dial-up connection started up, we quickly found out through which real IP our traffic from the operator, looked at whois, got the mask with mask / 21, opened it on the firewall of the border equipment, where the pptp tunnel was to be terminated, tried it - the VPN started up.
Good news, the operator does not cut TCP 1723 and GRE. The temporary scheme worked out, the channels were repaired. But at one "beautiful" moment they fell again, while the previously tested temporary scheme did not work. Small troubleshooting and a result that was a little surprised.
Traffic that is different from pptp (test ping, connection to arbitrary non-standard ports) the operator will get through one external IP (well, not just one, it is clear that they have a certain pool, which means the same for a particular modem connection), but pptp - through some other. Moreover, this other one is separated from the gprs-pool (/ 21), revealed earlier and opened in access sheets quite seriously. And it does not resolve to the name, unlike the IP from the gprs pool. And whois doesn't clarify anything.
Corrected access sheets, the tunnel was wound up. Since the risk of a repeated accident on conventional channels was high for some time, this “crutch” did not completely remove. And as a result, a curious statistic was gathered. When “whistles” were dropped and repeated connections, naturally, different gray IPs were issued, the external IP, from which the normal traffic ran, but the IP from which the operator pptp remained constant.
At the same time, the tunnel periodically fell and did not want to wind up, sometimes for a very long time, up to a work shift, and even a couple of times up to several days. Then suddenly he began to work as if nothing had happened.
The author of the note has long drove away various little thoughts, convincing himself that there is nothing to suffer with paranoia, you never know what is there in the “black box” of the operator's network, but ... I decided to improve the situation in more detail.
As a result, nothing suspicious with pptp traffic was noticed (except for the initial situation with nat from an incomprehensible IP). But during this debug, interesting details surfaced regarding HTTP traffic.
Data.
1. The connection to the IP of a server controlled by the author on a closed / un-listenable port 80 was successfully passed (in the absence of incoming traffic on the target server at the time of the connection).
2. This was not always, no tendency could be traced.
3. When netcat was launched on port 80 on the target server, it turned out that proxying is present in an explicit form, it is not clear.
In the case when it is presumably not present, nothing appears on L7 superfluous and is not modified, the protocol version, headers, etc. Moreover, if you send to the channel, for example, erroneous requests, they are transmitted as they are through and through to break the connection it does not lead.
When proxying is exactly there, when sending a minimalist "GET /" netcat on the server gave an curious
GET / HTTP / 1.1
X-Via: Harmony proxy
Host: xx.xx.xx.xx
and telnet at break timeout
Just want to make a reservation that this note ... this is just a note on some technical problem, which, as it seems to the author, has something to do with the subject of the section where it is published.
Here, habrahabr.ru/post/148200 has already touched on the topic of proxying through free VPN services, now we will focus on the mobile Internet.
')
In general, the author of the note didn’t overlap with such “beasts” as GPRS / 2G / 3G and so on. But once had to.
Once on one remote object the channel disappeared (or rather all the channels) to the head object. And it was very bad. An interim solution was urgently needed and considering the whole mass of accompanying factors (very unhappy), nothing “dance” was better than pptp via the usual USB “whistle”. But will it work? And the author notes and colleagues "in the shop" took doubts. Come mobile operator cuts the whole thing. But decided to try. Have tried. When the dial-up connection started up, we quickly found out through which real IP our traffic from the operator, looked at whois, got the mask with mask / 21, opened it on the firewall of the border equipment, where the pptp tunnel was to be terminated, tried it - the VPN started up.
Good news, the operator does not cut TCP 1723 and GRE. The temporary scheme worked out, the channels were repaired. But at one "beautiful" moment they fell again, while the previously tested temporary scheme did not work. Small troubleshooting and a result that was a little surprised.
Traffic that is different from pptp (test ping, connection to arbitrary non-standard ports) the operator will get through one external IP (well, not just one, it is clear that they have a certain pool, which means the same for a particular modem connection), but pptp - through some other. Moreover, this other one is separated from the gprs-pool (/ 21), revealed earlier and opened in access sheets quite seriously. And it does not resolve to the name, unlike the IP from the gprs pool. And whois doesn't clarify anything.
Corrected access sheets, the tunnel was wound up. Since the risk of a repeated accident on conventional channels was high for some time, this “crutch” did not completely remove. And as a result, a curious statistic was gathered. When “whistles” were dropped and repeated connections, naturally, different gray IPs were issued, the external IP, from which the normal traffic ran, but the IP from which the operator pptp remained constant.
At the same time, the tunnel periodically fell and did not want to wind up, sometimes for a very long time, up to a work shift, and even a couple of times up to several days. Then suddenly he began to work as if nothing had happened.
The author of the note has long drove away various little thoughts, convincing himself that there is nothing to suffer with paranoia, you never know what is there in the “black box” of the operator's network, but ... I decided to improve the situation in more detail.
As a result, nothing suspicious with pptp traffic was noticed (except for the initial situation with nat from an incomprehensible IP). But during this debug, interesting details surfaced regarding HTTP traffic.
Data.
1. The connection to the IP of a server controlled by the author on a closed / un-listenable port 80 was successfully passed (in the absence of incoming traffic on the target server at the time of the connection).
2. This was not always, no tendency could be traced.
3. When netcat was launched on port 80 on the target server, it turned out that proxying is present in an explicit form, it is not clear.
In the case when it is presumably not present, nothing appears on L7 superfluous and is not modified, the protocol version, headers, etc. Moreover, if you send to the channel, for example, erroneous requests, they are transmitted as they are through and through to break the connection it does not lead.
When proxying is exactly there, when sending a minimalist "GET /" netcat on the server gave an curious
GET / HTTP / 1.1
X-Via: Harmony proxy
Host: xx.xx.xx.xx
and telnet at break timeout
Error 504 Gateway Timeout
HTTP ERROR: 504 Gateway Timeout
RequestURI=http://xx.xx.xx.xx/
4. , TTL IP MSS TCP 80 . , IP Win TTL 128, TTL 167. , , 194, . MSS 1210. 80 . , MSS , TTL .
, ? Harmony proxy ?
pptp , . . , .
UPD: - -""? VPN :) Error 504 Gateway Timeout
HTTP ERROR: 504 Gateway Timeout
RequestURI=http://xx.xx.xx.xx/
4. , TTL IP MSS TCP 80 . , IP Win TTL 128, TTL 167. , , 194, . MSS 1210. 80 . , MSS , TTL .
, ? Harmony proxy ?
pptp , . . , .
UPD: - -""? VPN :)
Error 504 Gateway Timeout
HTTP ERROR: 504 Gateway Timeout
RequestURI=http://xx.xx.xx.xx/
4. , TTL IP MSS TCP 80 . , IP Win TTL 128, TTL 167. , , 194, . MSS 1210. 80 . , MSS , TTL .
, ? Harmony proxy ?
pptp , . . , .
UPD: - -""? VPN :) Error 504 Gateway Timeout
HTTP ERROR: 504 Gateway Timeout
RequestURI=http://xx.xx.xx.xx/
4. , TTL IP MSS TCP 80 . , IP Win TTL 128, TTL 167. , , 194, . MSS 1210. 80 . , MSS , TTL .
, ? Harmony proxy ?
pptp , . . , .
UPD: - -""? VPN :)Source: https://habr.com/ru/post/148260/
All Articles