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?
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.
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.
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:
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):
W tej sytuacji postanowiłem sprawdzić pomysł @g3n3zyp, ale konsola zgłasza odmowę dostępu:
Nie zawołałem Cię i pewnie przegapiłeś moją ostatnią odpowiedź. Proxy zadziałało i teraz jedyne co by mi się przydało do szczęścia w tej sprawie, to przetrwanie tunelu przez restart bramki. Konsultowałem sprawę ze znajomym dobrze zorientowanym w temacie i zaproponował takie rozwiązania:
Dowiedzieć się dlaczego cloudflared akurat przy tej bramce szuka dns pod [::]:53 i usunąć tę przyczynę.
Proces tunelu powinien mieć zmienną środowiskową TUNNEL_DNS=true, żeby odpalił sobie proxy dns jako jeden z wątków.
Możliwość zmiany argumentów dla cloudflared, żeby dorzucić mu argument --proxy-dns. Efekt ten sam jak z pkt. 2.
Osobny initscript dla cloudflared proxy-dns, żeby się włączał równolegle obok tunelu.
Zaproponowałem te rozwiązania mailowo ekipie AIS, ale odpowiedzieli, że się za to nie wezmą, więc jedyna nadzieja w społeczności…
A tak w ogóle, to bardzo dziękuję za dotychczasową pomoc!
