Problem z tunelem Cloudflare

Hej,
Z tunelu korzystam w wielu lokalizacjach i generalnie nie mam z nim problemów. Jest natomiast jeden taki dostawca internetu, GreenLAN, u którego mam 2 bramki i tunel nie działa na żadnej.

Wklejam fragment logów

21|tunnel  | 2022-07-21T11:31:10Z INF Starting tunnel tunnelID=562f5679-b558-4e5f-9376-c39a8b516bfe
21|tunnel  | 2022-07-21T11:31:10Z INF Version 
21|tunnel  | 2022-07-21T11:31:10Z INF GOOS: android, GOVersion: go1.16.7, GoArch: arm
21|tunnel  | 2022-07-21T11:31:10Z INF Settings: map[config:/data/data/pl.sviete.dom/files/home/.cloudflared/config.yaml cred-file:/data/data/pl.sviete.dom/files/home/.cloudflared/key.json credentials-file:/data/data/pl.sviete.dom/files/home/.cloudflared/key.json]
21|tunnel  | 2022-07-21T11:31:10Z INF Autoupdate frequency is set autoupdateFreq=86400000
21|tunnel  | 2022-07-21T11:31:10Z INF Generated Connector ID: a0c02e8d-1a7e-4796-ac85-3de444b8997d
21|tunnel  | 2022-07-21T11:31:10Z ERR Unable to lookup protocol. Defaulting to http2. If this fails, you can set --protocol h2mux in your cloudflared command. error="lookup protocol.argotunnel.com on [::1]:53: read udp [::1]:36853->[::1]:53: read: connection refused"
21|tunnel  | 2022-07-21T11:31:10Z INF Initial protocol http2
21|tunnel  | 2022-07-21T11:31:10Z INF Starting metrics server on 127.0.0.1:40559/metrics
21|tunnel  | 2022-07-21T11:31:11Z ERR update check failed error="no release found"
2|ais      | 2022-07-21 13:31:12 INFO (MainThread) [homeassistant.components.ais_shell_command] stdout [PM2] Saving current process list...
2|ais      | [PM2] Successfully saved in /data/data/pl.sviete.dom/files/home/.pm2/dump.pm2
21|tunnel  | 2022-07-21T11:31:20Z ERR Error looking up Cloudflare edge IPs: the DNS query failed error="lookup _origintunneld._tcp.argotunnel.com on [::1]:53: read udp [::1]:53970->[::1]:53: read: connection refused"
21|tunnel  | 2022-07-21T11:31:20Z ERR Please try the following things to diagnose this issue:
21|tunnel  | 2022-07-21T11:31:20Z ERR   1. ensure that argotunnel.com is returning "origintunneld" service records.
21|tunnel  | 2022-07-21T11:31:20Z ERR      Run your system's equivalent of: dig srv _origintunneld._tcp.argotunnel.com
21|tunnel  | 2022-07-21T11:31:20Z ERR   2. ensure that your DNS resolver is not returning compressed SRV records.
21|tunnel  | 2022-07-21T11:31:20Z ERR      See GitHub issue https://github.com/golang/go/issues/27546
21|tunnel  | 2022-07-21T11:31:20Z ERR      For example, you could use Cloudflare's 1.1.1.1 as your resolver:
21|tunnel  | 2022-07-21T11:31:20Z ERR      https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/
21|tunnel  | 2022-07-21T11:31:20Z INF Tunnel server stopped
21|tunnel  | 2022-07-21T11:31:20Z ERR Initiating shutdown error="Could not lookup srv records on _origintunneld._tcp.argotunnel.com: lookup _origintunneld._tcp.argotunnel.com on [::1]:53: read udp [::1]:53970->[::1]:53: read: connection refused"
21|tunnel  | 2022-07-21T11:31:20Z INF Metrics server stopped
21|tunnel  | Could not lookup srv records on _origintunneld._tcp.argotunnel.com: lookup _origintunneld._tcp.argotunnel.com on [::1]:53: read udp [::1]:53970->[::1]:53: read: connection refused

Wygląda, jakby tunel nie mógł sobie poradzić z zapytaniem DNS. Sprawę próbowałem już konsultować z ekipą AI-Speaker z konkluzją, że problem leży po stronie konfiguracji urządzeń sieciowych lub ISP. Urządzenia sieciowe wykluczyłem, więc udałem się do ISP, ale jak na razie, już po dłuższym czasie, bez rezultatu, mimo zaangażowania panów z obsługi technicznej.

Moje pytanie brzmi: czy ktoś spotkał się z podobnym problemem i może wie, gdzie szukać przyczyny?

Próbowałeś użyć DNS innego niż ISP?

Oczywiście, zmieniłem w routerze DNS na 1.1.1.1

Spróbuj może ustawić na bramce ten DNS.

A co to mogłoby potencjalnie dać w kontekście tego, że wystarczy podmienić kabelek z internetem w routerze i tunel zaczyna działać? Ostatecznie przecież i tak bramka powinna zaciągnąć konfigurację sieci z routera.

To zależy na ile masz pewność że router faktycznie konfiguruje bramkę po DHCP z DNS = 1.1.1.1?
Ustawienie DNS w bramce daje 100% pewność, że masz ten DNS tak ustawiony.

Sprawdziłem, serwerem dns bramki jest lokalny router, który tak jak mówiłem jest ustawiony na 1.1.1.1, więc to raczej ślepy trop. Poza tym, tak jak wspominałem: jeśli do portu WAN routera podepnę router LTE to nagle tunel zaczyna działać. Co ciekawe, pod tym adresem korzystam również z kontrolera TP-Link Omada i do niego zdalnie dostaję się bez przeszkód.

Po braku aktywności w tym temacie wnioskuję, że nikt w całym kraju się z tym problemem nie spotkał niezależnie od dostawcy internetu, tylko ja jeden mam tak w greenlanie?

No bez przesady, na forum jest zarejestrowanych tylko 490 użytkowników (i tylko oni mogą odpowiadać - "pisać na forum) więc potencjalna skala problemu naprawdę jest mała.

Pytanie ilu jeszcze z tych 490 korzysta z GreenLAN? Mam u siebie lokalnego dostawcę internetu za podwójnym NAT. Tunel od AIS jak i postawiony osobno z Cluodflare, pod własną domenę, działają bez problemu. Twoje doświadczenia wskazują na problem po stronie ISP.

Więcej czasu straciłeś na pisanie tej wypowiedzi niż zajmuje ustawienie dns w androidzie. A my nadal nie wiemy czy taka opcja działa.

Chyba się nie zrozumieliśmy. Wydaje mi się, że w ogóle nie straciłem czasu, tylko określiłem kilka dodatkowych okoliczności, m. in. tą, że sprawdziłem konfigurację DNS bramki i jest taka jak trzeba, więc ten trop można wykluczyć.

No właśnie, 490 użytkowników to na tyle mało, że całkiem prawdopodobne, że nikt poza mną nie ma okazji korzystać w łącza od GreenLAN. To co mówisz o swoim łączu jest dodatkowo ciekawe, bo obsługa techniczna GreenLAN próbowała mnie przekonywać, że to właśnie skomplikowana architektura sieci po ich stronie powoduje problem. Twój przykład pokazuje, że wcale nie musi tak być, bo jak rozumiem u Ciebie tunel działa bez żadnych uzgodnień z ISP?

GreenLAN próbował przekierowywać porty specjalnie pod tą usługę, oczywiście bez efektu.

Tak, tunel działa bez żadnych zmian w mojej i ich sieci. Router dostawcy pozostał tak jak go stawiali standardowo ponieważ nie potrafią skonfigurować poprawnie dostarczanej telewizji internetowej na ich sprzęcie, z moim routerem. Więc dołożylem swoj router za tym od ISP i wszystko działa. Telewizja osobną skrętką do ich dekodera.

Największą zaletą tunelu jest brak potrzeby grzebania przy portach. Nie trzeba ich otwierać na świat. Najważniejszy jest prawidłowy DNS, tak aby Cludflare mógł zestawić połączenie.

Zrób o co prosił @Stravi .

hejka

u mnie też coś podobnego zauważyłem i szczególnie zastanowił mnie ten fragment:

on [::1]:53: read udp [::1]:53970->[::1]:53: read: connection refused

cloudflared próbuje odpytać się lokalnie o dns ale po adresach ipv6

moje obejście na tą chwilę które zadziałało to - proxy-dns Run a DNS over HTTPS proxy server w cloudflare

cloudflared proxy-dns &

po wrzuceniu tego w tło tunel się odpalił, możesz sprawdzić czy u ciebie też tak zadziała

No to mały update. Okazało się, że GreenLAN przekierowuje zapytania dns użytkowników na własne serwery, dlatego zmiana dns na routerze nie dawała żadnego efektu. To dało mi chwilową nadzieję, że uda się ogarnąć temat interweniując u ISP, żeby dał spokój z ingerencją w dnsy. Zareagowali dość szybko i teraz wyjście z dnscheck.tools wygląda tak:

image

Czyli powinno być dobrze. Ale nie jest, tunel daje nadal ten sam błąd.

Wobec tego próbowałem posłuchać sugestii @Stravi i nadałem bramce przez interfejs stałe IP razem z serwerem dns 1.1.1.1. I co? I nic nadal ten sam błąd, mimo, że zmiana się powiodła (pic rel):
image

W tej sytuacji postanowiłem sprawdzić pomysł @g3n3zyp, ale konsola zgłasza odmowę dostępu:

Jak to obejść?

faktycznie na zwykłym koncie nie pójdzie, trzeba być rootem
z tego co pamiętam to powinno być tak:

su 
export PATH=$PATH:/data/data/pl.sviete.dom/files/
cloudflared proxy-dns &
exit

czyli:

  1. wchodzisz na konto root
  2. dodajesz ścieżkę do plików ais gdzie powinien być cloudflare
  3. odpalasz proxy-dns
  4. wracasz do poprzedniej sesji zwykłego usera

potem możesz sprawdzić czy wstanie tunel, jeśli zadziała to będzie działać tylko do restartu ale to będziemy się martwić później

Zastosowałem Twoją metodę:
image

Na oko wygląda, że coś jest nie tak, bo ‘cloudflared: not found’ i rezultatu brak.

Jeśli chodzi o działanie po restarcie to kolega wymyślił coś takiego:

export TUNNEL_DNS=true
cloudflared tunnel

Ale też kończy się błędem:

w takim razie trzeba na początku sprawdzić gdzie siedzi cloudflare:
z konta zwykłego użytkownika:

whereis cloudflared

w odpowiedzi dostaniesz ścieżkę (i pewnie będzie inna niż moja):

~ $ whereis cloudflared
cloudflared: /data/data/pl.sviete.dom/files/usr/bin/cloudflared

i

su 
export PATH=$PATH:/tutaj/wstawiasz/ścieżkę/z/poprzedniego/polecenia/
cloudflared proxy-dns &
exit

jak ruszy to test tunelu

edit: chyba zjadłem ‘bin’ w poprzednim “poradniku”
obstawiam, że powinno być tak:

export PATH=$PATH:/data/data/pl.sviete.dom/files/usr/bin/

1 polubienie

Ok, pokopałem jeszcze trochę i udało się, tunel wstał. Zrzut z konsoli:

Teraz trzeba sprawić, żeby restart nie przeszkadzał. Czy to nie jest czasem temat dla deweloperów AIS?