FastGitORG / discussion

👥 For general discussion over FastGit development and usage.
5 stars 0 forks source link

FastGit Service returned 301 redirect to github.com #1

Closed mnixry closed 2 years ago

mnixry commented 4 years ago

Today when I access fastgit, it returned 301 redirection

$ curl -v hub.fastgit.org
* Rebuilt URL to: hub.fastgit.org/
*   Trying 104.18.40.99...
* TCP_NODELAY set
*   Trying 2606:4700:3037::ac43:c99f...
* TCP_NODELAY set
* Immediate connect fail for 2606:4700:3037::ac43:c99f: Network is unreachable
*   Trying 2606:4700:3033::6812:2863...
* TCP_NODELAY set
* Immediate connect fail for 2606:4700:3033::6812:2863: Network is unreachable
*   Trying 2606:4700:3034::6812:2963...
* TCP_NODELAY set
* Immediate connect fail for 2606:4700:3034::6812:2963: Network is unreachable
* Connected to hub.fastgit.org (104.18.40.99) port 80 (#0)
> GET / HTTP/1.1
> Host: hub.fastgit.org
> User-Agent: curl/7.61.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Date: Mon, 24 Aug 2020 09:49:27 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Mon, 24 Aug 2020 10:49:27 GMT
< Location: https://github.com/
< cf-request-id: 04c178793e0000053444144200000001
< Server: cloudflare
< CF-RAY: 5c7c29d53aca0534-LAX
< 
* Connection #0 to host hub.fastgit.org left intact

if I use HTTPS connection, it returned 301 also:

$ curl -v https://hub.fastgit.org
* Rebuilt URL to: https://hub.fastgit.org/
*   Trying 104.18.41.99...
* TCP_NODELAY set
*   Trying 2606:4700:3037::ac43:c99f...
* TCP_NODELAY set
* Immediate connect fail for 2606:4700:3037::ac43:c99f: Network is unreachable
*   Trying 2606:4700:3034::6812:2963...
* TCP_NODELAY set
* Immediate connect fail for 2606:4700:3034::6812:2963: Network is unreachable
*   Trying 2606:4700:3033::6812:2863...
* TCP_NODELAY set
* Immediate connect fail for 2606:4700:3033::6812:2863: Network is unreachable
* Connected to hub.fastgit.org (104.18.41.99) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=Cloudflare, Inc.; CN=sni.cloudflaressl.com
*  start date: Aug 23 00:00:00 2020 GMT
*  expire date: Aug 23 12:00:00 2021 GMT
*  subjectAltName: host "hub.fastgit.org" matched cert's "hub.fastgit.org"
*  issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* Using Stream ID: 1 (easy handle 0x561fe2b03720)
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> GET / HTTP/2
> Host: hub.fastgit.org
> User-Agent: curl/7.61.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
< HTTP/2 301 
< date: Mon, 24 Aug 2020 09:51:36 GMT
< cache-control: max-age=3600
< expires: Mon, 24 Aug 2020 10:51:36 GMT
< location: https://github.com/
< cf-request-id: 04c17a70d10000eaf84082d200000001
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 5c7c2cfae901eaf8-LAX
< 
* Connection #0 to host hub.fastgit.org left intact
KevinZonda commented 4 years ago

@mnixry Hi there! This is a method to prevent abuse. Now we redirect non-China IP to GitHub.

mnixry commented 4 years ago

This is a method to prevent abuse. Now we redirect non-China IP to GitHub.

Thank you for your early reply, but I could ensure I'm using China IP address 223.108.0.0/14. Does it means I need to modify my DNS options?

KevinZonda commented 4 years ago

@mnixry Ummm.. It's weird. We use Aliyun's intelligent DNS resolution to return ip depends geographical locations. I guess that you may use Shadowsocks or similar application so that caused a cached DNS result?(I'm not sure)

And, I think your solution is right. You can correct DNS result by modifying hosts.

KevinZonda commented 4 years ago

@mnixry If you want to get our current DNS records list, mail me. My Email is realkevin@tutanota.com.

mnixry commented 4 years ago

Okay, after trying, I found that whether the DNS server is in the mainland determines the resolution result:

; <<>> DiG 9.16.6 <<>> @8.8.8.8 hub.fastgit.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9379
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;hub.fastgit.org.               IN      A

;; ANSWER SECTION:
hub.fastgit.org.        262     IN      CNAME   hub.fastgit.org.cdn.cloudflare.net.
hub.fastgit.org.cdn.cloudflare.net. 299 IN A    104.18.41.99
hub.fastgit.org.cdn.cloudflare.net. 299 IN A    104.18.40.99
hub.fastgit.org.cdn.cloudflare.net. 299 IN A    172.67.201.159

;; Query time: 100 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 02 08:54:24 CST 2020
;; MSG SIZE  rcvd: 140
; <<>> DiG 9.16.6 <<>> @114.114.114.114 hub.fastgit.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41842
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;hub.fastgit.org.               IN      A

;; ANSWER SECTION:
hub.fastgit.org.        36      IN      A       (**Server IP**)

;; Query time: 80 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Wed Sep 02 08:54:40 CST 2020
;; MSG SIZE  rcvd: 60

A large number of users in mainland China may use foreign DNS servers, especially developers who need to use GitHub services. So in my opinion, it is not a good idea to use DNS to determine whether visitors are from China.

KevinZonda commented 4 years ago

Ummm, maybe.

image

Also, do you have some good idea? Just to solve it.

KevinZonda commented 4 years ago

Should we use GeoIP as? umm, limit? idk

mnixry commented 4 years ago

Should we use GeoIP as? umm, limit? idk

Some server providers may provide hardware-based firewalls that can provide network segment-based blocking services (similar to the "security group" provided by Alibaba Cloud), but this will completely denied access from non-China IP instead of redirect user to GitHub. But deploying IP-based redirection rule in the Nginx application layer will also consume server CPU and bandwidth resources :facepalm: .

I can't think of a better way other than the hardware firewall provided by the service provider :( BTW, when the server is under DDoS attack, most of the traffic will usually come from non-China IP. Maybe this is also a means to block DDoS attacks?

KevinZonda commented 4 years ago

@mnixry To deny non-China access is just to save money you know....

KevinZonda commented 4 years ago

Now we move download to CDN. Waiting for SSL request.