Przejdź do treści forum
eko.one.pl
OpenWrt, Linux, USB, notebooki i inne ciekawe rzeczy
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Opcje wyszukiwania
Przepraszam za ożywienie starego wątku, ale pomyślałem, że może komuś się przyda i nie straci pół niedzieli.
Też chciałem hasło w sieci dla gości generować za pomocą qrencode wg. tego poradnika: https://blog.tldnr.org/2019/11/11/Guest-Wifi/
Oczywiście problem z generacją kodu png bo jak Cezary zauważył wyłączone w pakiecie, ale nie dało mi to spokoju, bo przecież na przywołanej stronie jako plik wyjściowy jest svg. W końcu znalazłem, że opcja --type=SVG generuje obrazek w tymże formacie.
Czyli w skrypcie linijka powinna wyglądać:
qrencode -o /www/wifi.svg --type=SVG "WIFI:S:${ssid};T:${security};P:${password};;"
Zobacz taki skrypt w php z curl: https://code.google.com/p/liveboxreconn … n2&r=2
i spróbuj go dostosować do swojego Livebox'a.
Krzychu, no właśnie dokładnie to samo mi wyszło z eksperymentów, putty jest niedopracowane w tym względzie, opcja "Remote ports do the same" przełącza słuchanie pomiędzy 127.0.0.1 a wszystkimi interfejsami na raz.
@build000: ja dokładnie wiem, co chcę osiągnąć i nie mam zamiaru sobie portów zostawić na zewnątrz otwartych bez kontroli, stąd sprawdzenie za pomocą netstat. Oczywiście, że tak naprawdę w świetle niedawnych ujawnionych dziur w openssl nie można ufać zarówno ssh jak i openvpn. Ja wybieram opcję śledzenia najnowszych problemów i łatanie ujawnionych dziur, ale można oczywiście blokować wszystko.
Może to właściwość putty, którym wytwarzam tunel. Poeksperymentuję trochę i dam znać, może komuś jeszcze się to przyda.
Aktualizacja: faktycznie wygląda to na jakieś kwestie związane z putty. Otwarcie tunelu przez ssh robi dokładnie to co trzeba, czyli można ograniczyć nasłuchiwanie do określonego interfejsu.
Faktycznie GatewayPorts musi być "on". Co prawda mam efekt uboczny, teraz niezależnie co podam, czy localhost, czy interfejs LAN, słucha na wszystkich interfejsach:
root@xxx:~# netstat -na | grep 4666
tcp 0 0 0.0.0.0:4666 0.0.0.0:* LISTEN
Krzychu, dzięki wielkie. Jutro przetestuję w firmie, którą się opiekuję, bardzo mi to ułatwi sprawę zdalnego monitorowania.
@build000: o i to jest już odpowiedź na moje pytanie, choć może pośrednia. Szkoda tylko, że nie napisałeś wcześniej, że takie ograniczenie istnieje, zaoszczędziłbym trochę czasu na eksperymenty. Jak już pisałem, mogę to zrobić inaczej, choć mniej wygodnie, więc przy tym pozostanę. A posądzanie mnie o włamanie to jest trochę nadinterpretacja (szczególnie w świetle posta nr 10), ale to chyba dosyć popularne, że szuka się u kogoś najgorszych intencji, prawda? 
Nie chodzi o obejście firewalla (który akurat jest zupełnie osobnym urządzeniem), bo jak najbardziej mogę się dostać do tej sieci poprzez VPN, ale jest to niewygodne z różnych względów, np. rozłączanie raz dziennie, przekierowanie całego ruchu sieciowego przez VPN etc. etc. Poza tym, przecież piszę, że potrafię to zrobić, ponieważ tunel się otwiera, i nawet potrafię się podłączyć tworząc drugi tunel z laptopa do mojego routera (o czym nie pisałem, żeby nie zaciemniać obrazu), ale chcę to uprościć.
Zadałem więc pytanie techniczne, związane z konfiguracją dropbear'a, licząc że ktoś kto ma wiedzę, spróbuje pomóc (jak Cezary i build0000), a jak ktoś nie wie to nie będzie bił piany 
Jeszcze raz dla wyjaśnienia wszystkich wątpliwości, chciałem przedstawić rysunek.
Ponieważ nie mam uprawnień do konfiguracji firewalla w lokalizacji, gdzie stoi komputer z aplikacją, do której chcę się podłączyć, niemożliwe jest proste połączenie (linia czerwona). W związku z tym otwieram zdalny port na swoim domowym routerze, który jest przekazywany do portu na komputerze za firewallem. Robię to za pomocą putty na tymże komputerze za firewallem, wykorzystując remote port forwarding (linia niebieska). W teorii powinno to umożliwić połączenie z laptopa poprzez tak zestawione połaczenie (linia zielona). Niestety, pomimo że port na routerze otwiera się, nasłuchuje jedynie na adresie 127.0.0.1, a zatem nie mogę podłączyć się do tego portu z mojej podsieci domowej. Czy ktoś miałby jakieś sugestie, dlaczego pomimo włączonej opcji GatewayPorts na routerze, nie mogę uzyskać tego połączenia?
Ach, widzę niedopowiedzenie, już tłumaczę: to jest wynik polecenia netstat wykonanego na routerze w sieci domowej, czyli w sieci A, po utworzeniu odwrotnego tunelu przez putty z sieci B. Czyli port został zdalnie otwarty, tyle tylko, że słucha na interfejsie 127.0.0.1 a nie na 10.0.0.1 czyli LAN.
Na firewallu nie mogę, bo nim nie administruję, stąd konieczność remote port forwardingu. A dropbear to robi, jak widać poniżej:
root@xxx:~# netstat -na | grep 466
tcp 0 0 127.0.0.1:4666 0.0.0.0:* LISTEN
ale ja bym chciał tak:
root@xxx:~# netstat -na | grep 466
tcp 0 0 10.0.0.1:4666 0.0.0.0:* LISTEN
jeśli 10.0.0.1 to interfejs LAN mojego routera.
W pierwszym przypadku, czyli to co umiem zrobić, forwardowany port jest widziany tylko "wewnątrz" routera, a w drugim przypadku w całym LAN'ie. Pytanie zatem, czy jest to ograniczenie dropbeara, który pomimo ustawienia GatewayPorts na yes, ignoruje to ustawienie?
Tutaj chodzi o nieco bardziej skomplikowany przypadek, chodzi mi o reverse port forwarding. Czyli z zewnątrz wywołanie polecenia:
ssh -f -N -q -R LAN_IP:4666:localhost:4666 xxx@yyy.zz
Scenariusz jest taki: mam sieć domową (A) za routerem z openwrt. Router ma zewnętrzne IP. Mam też komputer w innej sieci (B), za NAT'em i firewallem, i potrzebuję się czasem podłączyć do jednej z usług na tym komputerze, do konkretnego portu. Trudność polega na tym, że nie kontroluję tego NAT'a i firewalla. Zatem jedyną możliwością jest otwarcie portu na moim routerze od strony LAN, z którego ruch będzie przekazywany na port tego komputera na zewnątrz. Ale trzeba to zainicjować z komputera w sieci B, stąd reverse port forwarding. Port na routerze się otwiera, ale tylko lokalnie, pomimo że GatewayPorts w dropbearze jest ustawione na "yes". Jak zrobić, żeby port był dostępny z innych komputerów w sieci A?
Potrzebowałem ostatnio za pomocą SSH otworzyć odwrotny tunel z zewnątrz do mojego routera. Niestety nie potrafię tego zrobić, a raczej potrafię, ale na routerze port jest otwarty tylko dla localhosta, a nie dla wszystkich po stronie LAN:
root@xxx:~# netstat -na | grep 466
tcp 0 0 127.0.0.1:4666 0.0.0.0:* LISTEN
Uprzednio zmieniłem konfigurację dropbear'a włączając GatewayPorts i w tej chwili mam w /etc/config/dropbear
config 'dropbear'
option 'PasswordAuth' 'on'
option 'Port' '22'
option 'GatewayPorts' 'yes'
Ponadto na zdalnym komputerze w konfiguracji putty mam zaznaczone w "Port forwarding", że "Remote ports do the same", w sensie że przyjmują połączenia z innych hostów. Czy jest jeszcze coś, co można spróbować zrobić, czy może ta implementacja dropbeara "tak ma"? Czy ktoś mógłby coś jeszcze zasugerować?
Pozdrawiam
Grzesiek
Dzięki Cezary, tak zrobię:)
Dzięki za błyskawiczną odpowiedź:) F/W wzięte stąd: http://ecco.selfip.net/tl-wr1043nd-luci/, LuCI pisze, że 10.03.
Chyba skonfiguruję w takim razie openvpn grzebiąc w plikach.
Ale w takim razie skąd mam wziąć pakiety openvpn i openvpn-easy-rsa, żeby mieć pewność że zadziałają poprawnie z moim firmwarem?
Witam, stanąłem przed koniecznością zainstalowania sobie serwera openvpn w domu i pomyślałem, że mój TL-WR1043ND świetnie się nada do tego celu. Wybrałem więc OpenWrt Backfire 10.03 z LuCI i ponieważ tutaj: https://forum.openwrt.org/viewtopic.php?pid=112402 wyczytałem, że jest również moduł konfiguracyjny do LuCI, próbowałem go wgrać. Niestety po instalacji pakietu luci-app-openvpn 0.9+svn6240-1 (ten który jest na liście Available Packages) LuCI przestaje działać 
W sumie mogę skonfigurować openvpn z konsoli, ale pomyślałem, że może ktoś miał podobny problem i mógłby się podzielić rozwiązaniem.
Pozdrawiam
Grzesiek
Znalezione posty: 16