Obsługa 2 łącz w Windowsie dla realizacji tego pomysłu okazuje się banalnie prosta.
Wystarczą 2 zmiany w tabeli routingu:
- puszczenie całego ruchu internetowego tylko przez interfejs Aero2
- dodanie trasy do serwera Captcha Brotherhood przez drugi interfejs
To wszystko do zrealizowania 3 poleceniami route.exe
To wiem.
Wiem nawet jak przypisać konkretne łącze do konkretnej aplikacji.
Ale jak z wnętrza aplikacji wybierać, z którego łącza aktualnie korzystasz i jak zagwarantujesz to, że Windowsowi coś się nie odwidzi i nie pozmienia tablicy routingu w locie?
Myślę, że z wnętrza aplikacji można ewentualnie pilnować tylko poprawności tablicy routingu, nic więcej.
Zarządzanie ruchem należy pozostawić systemowi operacyjnemu.
Nie należy też z góry zakładać czarnego scenariusza, wszystko wyjdzie podczas testów.
Windows na pewno przebudowuje tablicę routingu w sytuacji gdy pojawia się nowy interfejs sieciowy, w innych przypadkach raczej nie.
Ja znam Windows, to nie jest takie proste.
Musisz mieć możliwość wyboru bramki, przez którą się łączysz z wnętrza aplikacji -inaczej nie pobierzesz kapcia z Aero2 i nie wyślesz go skutecznie przez Orange lub inne łącze.
Nie zgadzam się z tym co piszesz. Aplikacja nie musi sama wybierać bramy, aplikacja komunikuje się z konkretnym adresem IP i właśnie z tabeli routingu wynika konkretna trasa do celu.
Jeżeli tabela jest jednoznaczna, to nie ma żadnej przypadkowości w wybieraniu trasy.
Poza tym w analizowanym przez nas pomyśle Dekapeć nie musi w ogóle mieć dostępu do drugiego interfejsu. Jego zadanie będzie polegać na zapisaniu na dysk obrazka z kapciem i wywołaniu programu cbhcoreplugin.exe z parametrami: login, hasło, ścieżka dostępu do zapisanego obrazka. Następnie należy zaczekać na pojawienie się pliku output.txt, który będzie zawierać odczytany kod. Wartość tego kodu należy wysłać jako odpowiedź na kapcia.
Przez drugi interfejs sieciowy komunikował się będzie tylko program cbhcoreplugin.exe.
Czyli nie zrozumiałeś problemu - rozpisz dokładnie co ma się dziać i kiedy. Jak są dwa łącza z internetem, które restartują się w losowych momentach.
Dodam, że przypisanie trasy dla exe jest możliwe dopiero po odpaleniu exe - dla tej metody co ją znam. Ale tylko dla aktywnego łącza. Rozłączenie i połączenie ponowne zmienia tablicę routingu.
1. Przypadek łatwiejszy, czyli połączenia przez routery 3G.
W tym wypadku, adresy IP bram i interfejsów się nie zmieniają, dodatkowo rozłączenie połączenia modemowego router <-> operator 3G nie powoduje żadnych zmian w tablicy routingu, ponieważ interfejsy nie znikają z systemu. W tym wypadku nie ma konieczności bieżącego kontrolowania tabeli.
2. Przypadek trudniejszy – modemy.
W przypadku nawiązania połączenia modemowego w systemie pojawia się nowy interfejs sieciowy, który za każdym razem ma inny adres IP. W momencie pojawienia się tego interfejsu do tablicy routingu system dodaje kilka domyślnych wpisów. Gdy modem się rozłączy, interfejs sieciowy znika z systemu co powoduje również usunięcie odpowiednich wpisów z tabeli routingu. W tym wypadku mamy do czynienia z ciągłymi zmianami w tabeli.
W przypadku modemu, aby zapewnić ciągły dostęp do serwera captchabrotherhood, za każdym razem jak zmieni się adres interfejsu drugiego łącza i musimy rozkodować kapcia, Dekapeć musi dodać w systemie nową trasę do tegoż serwera. W tym celu wystarczy że wykona jedno polecenie route.exe. Dodatkowo, aby profilaktycznie zablokować na drugim łączu ruch sieciowy inny niż ruch kapciowy (pamiętajmy, jest to najtańsze łącze z niewielkim limitem danych) należy wykasować trasę 0.0.0.0 na tymże łączu.
W przypadku routerów sprawa jest dużo prostsza, właściwie Dekapeć tylko przy starcie musiałby sprawdzić, czy tabela routingu jest w porządku.
Oczywiście możliwy jest wariant mieszany, router+modem. Jak łatwo wywnioskować z powyższego wywodu, lepiej żeby dodatkowe łącze było na routerze.
Nie widzę potrzeby przypisywania trasy dla konkretnego programu. Wystarczy prawidłowo skonfigurowany routing. Trasa zależy od adresu docelowego, a nie od programu który ten ruch inicjuje.
Jak by powyższe pomysły zaadaptować do zestawu router + 2 lub więcej modemów z aero, to oprócz wyższej przepustowości (zależnie od techniki łączenia tuneli czy load balansingu) można mieć "automatyczne" rozwiązywanie captache, oczywiście do momentu kiedy wszystkie modemy się rozłączą. Ewentualnie można by użyć routera z opcją "fail over" i podnoszonym linkiem na innym modemie z doładowaną kartą.
Chyba pora zaopatrzyć się w aktywny hub usb z własnym zasilaniem
Możnaby zrobić tak, że po wprowadzeniu pierwszego kapcia (nawiązanie połączenia) drugie Aero2 już by było rozwiązywane poprzez pierwsze, zdekacpiowane - tak o tym kiedyś myślałem.
Ogólnie to co pisze gbr na "papierze" wygląda OK. Problem w tym, że cały czas nie widzę rozwiązania tego problemu:
->Wykryliśmy kapcia
--->jak przełączamy się na drugie łącze w sposób niezawodny? Odpalamy nowe połączenie przez router, czy zmieniamy trasy? Jak to robimy żeby mieć pewność, że faktycznie wyjdziemy przez właściwe łącze (pamiętaj, że w wielu systemach połączenia przechodzą często przez z trasy ustalone przed uruchomieniem programu - stąd czasem problemy z ping i innymi, jeżeli w czasie ich pracy zmienimy konfigurację połączeń)? Skąd wiemy które łącze jest które (jak się pomylimy to cały ruch pójdzie przez płatne łącze i będzie draka). Po prostu zrobienie tego niezawodnie i dla przeciętnego użyszkodnika niezawodny jest trudne.
Świadomy użytkownik da sobie radę, to wiem, ale robienie rozwiązania dla 100 osób jest dla mnie ograniczone pod względem sensu (włożona praca/efekt).
Co nie zmienia faktu, że ja zapraszam do zrobienia choćby szkicu faktycznie działającego rozwiązania (jakiejkolwiek wyklejki) z rozważeniem praktycznym problemów. Choćby jak ustalić które łącze jest które. Jak nawiązać połączenie modemowe z linii poleceń (no chyba, że dwa routery weźmy na start, i niech mają sztywne IP) itd.
Myślę że najbezpieczniej było by to tak:
Jeden router i dwa modemy. Ten z Aero jako podstawowy i drugi z płatnym dostępem jako rezerwa do rozwiązywania captache.
Dla typowego użyszkodnika całość musiała by być postawiona na typowym sprzęcie obecnie (ze statystyk wysyłanych z gargoryle) wynika że to zestaw MR3420(MR3220) + E3131. Trzeba by przygotować specjalną konfiguracje oprogramowania np. właśnie na gargoryle.
Wszystko jest do ogarnięcia.
Na początek rzeczywiście najlepiej byłoby wykonać zadanie dla prostszego wariantu z routerami, z założeniem że routery automatycznie wznawiają połączenie. W konfiguracji Dekapcia użytkownik podaje adres IP interfejsu z Aero2 i adres drugiego łącza. Dekapeć koniecznie musi na bieżąco pilnować tabeli routingu i wycinać trasę 0.0.0.0 dla drugiego łącza, gdyby taka mimo wszystko pojawiała się w tabeli. Tak zabezpieczymy się przed obciążaniem płatnego łącza.
Nie musimy przełączać się na drugie łącze, wystarczy że Dekapeć będzie dbał o właściwą tabelę routingu.
W przypadku modemów również widzę to w ten sposób, aby utrzymywać on-line oba połączenia. Proponuję zastosować tu jakieś istniejące oprogramowanie dedykowane do tego celu. Działałoby ono niezależnie od Dekapcia. Tutaj nie mam wiedzy, gdyż pomimo iż posiadam modemy, to jednak nie używam ich praktycznie w ogóle, preferuję routery 3G.
W przypadku modemów, w konfiguracji Dekapcia użytkownik podaje nazwę połączenia modemowego dla Aero2 i nazwę połączenia dla drugiego łącza. Dekapeć na podstawie analizy odpowiedzi na polecenie ipconfig, będzie wiedział jakie adresy IP mają aktualnie oba łącza. Na podstawie tych informacji musi korygować tabelę routingu.
Załóżmy prostą sytuację:
- Odpalony program torrent, p2p, ssie cały czas na maksa. Albo Skype, albo ftp - cokolwiek, co sobie cały czas wznawia sesje i wysyca każde łącze.
- co dzieje się w momencie pojawienia się kapcia? Zmieniamy trasę na alternatywne łącze, kontaktujemy się z CB (Captcha Brotherhood) i... w tym czasie leci kilkadziesiąt MB przez to łącze?
To tylko czubek góry lodowej.
Na routerze z linuxem na wan2 ustawiamy iptables zakazem połaczenia ze wszystkimi adresami z wyjątkiem na adres serwera dekapciującego, ewentualnie dopuszczamy jakieś komunikatory. Taki firewall z blokadą możemy uruchamiać automatycznie wraz z podniesieniem konkretnego interfejsu.
Najlepiej będzie jak sam to sprawdzisz.
Jeżeli usuniesz trasę 0.0.0.0 dla danego interfejsu, to to łącze stanie się "martwe" dla połączeń internetowych. Żaden ruch tamtędy nie przejdzie. Nawet jak straci się drugie łącze, to przez pierwsze nadal nic nie będzie przechodzić. Windows sam z siebie nie zmieni routingu dla istniejącego interfejsu.
Teraz jeżeli dla tego interfejsu dodamy trasę do jednego serwera, to tylko ruch do tego serwera będzie przechodził przez to łącze. Nie ma możliwości że będzie inaczej.
Wczoraj testowałem to na Windows XP. W sumie ręcznie symulowałem pracę, którą miałby wykonywać Dekapeć. To naprawdę działa.
Spróbuj to oskryptować - cygwin32 ma basha, da się spokojnie coś takiego zrobić. Nie wiem tylko jak z niego sterować routami. Albo powershell do win vista i wyższych.
Sprawa jest na tyle prosta, że wystarczy batch z command line'a.
Załączam.
Uruchamiamy następująco:
r2b "192.168.1.1"
- gdzie 192.168.1.1 to przykładowy adres bramy dla łącza kapciowego.
Skrypt sprawdza czy istnieje trasa 0.0.0.0 dla bramy łącza kapciowego, jeżeli istnieje to kasuje ją. Następnie sprawdza czy istnieje dedykowana trasa do serwera captchabrotherhood.com, jeżeli nie istnieje to dodaje ją.
Skrypt przeznaczony jest dla systemów Windows, w których oba łącza są na routerach.
Testowane na systemach XP i 7.
No to możesz już zautomatyzować całość z poziomu bata - wget i curl to chyba żaden problem - oczywiście logiki z tyłu żadnej nie będzie (odporności na zmiany strony przez aero) ale jako proof-of-concept...
Niestety zarówno wget jak i curl nie obsługują JavaScript. Bez tego nie dostanę się do obrazka kapcia.
Znacie jakieś proste narzędzie, które da sobie radę z JS?
Chyba nie trzeba tego robić z JS - ale jak chcesz, jest phantom js.
Wg tego artykułu, algorytm Googla rozpoznający numery budynków dla StreetView potrafi rozpoznawać reCaptchę ze skutecznością 99%. Taka tam ciekawostka.
Ciekawy jest również jeden z komentarzy pod tekstem, który mówi jakoby system OCR Googla osiągnął taką skuteczność właśnie dzięki biednym milionom ludzi przepisujących captchę. System przez lata zbierał i analizował dane nt tego w jaki sposób ludzie odczytują obrazki, tak aby na podstawie zgromadzonych doświadczeń stać się na tyle bystrym, żeby móc samodzielnie rozpoznawać znaki na budynkach w sposób, w jaki robią to ludzie.
http://techcrunch.com/2014/04/16/googles...-captchas/