Brama Linuksa wykorzystująca podwójne dane w AT&T, czy moje iptables są błędne?

Mam komórkowe połączenie internetowe z AT & amp; T. Wszyscy łączą się z punktem dostępu do sieci Wi-Fi, z którym mój Raspberry Pi jest podłączony do serwera DNS DNS / DHCP / Gateway.

Na moim Pi używam dnsmasq, aby nadać każdemu urządzeniu statyczny adres IP, jeśli jest na liście. Następnie używam iptables, aby ustawić reguły dla każdego urządzenia (aby policzyć przepustowość i ograniczyć, jeśli jest więcej) jest to przykład dwóch urządzeń.

Chain FORWARD (policy ACCEPT)
target     prot opt source             destination
usb-w      all  --  0.0.0.0/0          192.168.1.3
usb-w      all  --  192.168.1.3        0.0.0.0/0       MAC 00:11:22:33:44:55
tab        all  --  0.0.0.0/0          192.168.1.4
tab        all  --  192.168.1.4        0.0.0.0/0       MAC 66:77:88:99:AA:BB
Local      all  --  0.0.0.0/0          0.0.0.0/0

Chain Local (2 references)
target     prot opt source               destination
ACCEPT     all  --  192.168.1.0/24       192.168.1.0/24
REJECT     all  --  192.168.1.0/24       0.0.0.0       reject-with icmp-port-unreachable

Chain usb-w (2 references)
target     prot opt source               destination
Local      all  --  0.0.0.0/0            0.0.0.0/0

Chain tab (2 references)
target     prot opt source               destination
ACCEPT      all  --  0.0.0.0/0            0.0.0.0/

W skrypcie PHP loguję liczbę bajtów tabel użytkownika i zeruję ją. Jeśli urządzenie przekroczyło ustalony limit, tabela użytkownika zostanie zmieniona na tabelę lokalną. To działa dobrze przez chwilę.

Następnie dwa miesiące temu zaczęliśmy przeglądać AT i T-cap dużo . Przechodząc przez fazę rozwiązywania problemów, odkryłem, że jako przykład , Nagrałem 10 GB użycia, ale AT i T oraz ich urządzenie internetowe mówią, że korzystałem z 20 GB.

Po rozmowie z nimi (mówią, że to ja) przeprowadziłem test pobierania. Pobrałem plik debian-live-8.4.0-i386-cinnamon-desktop.iso ze strony Debiana podłączonej bezpośrednio do urządzenia AT & amp; T i ponownie podłączonego do pi. I dowiedziałem się, że moje Pi używa podwójnych danych.

Jak mogę to rozwiązać? Uzyskanie opłat za nadmiar jest kosztowne, rachunek za ten miesiąc przekracza 600 USD.

Nie ma nic złego w twoich zasadach. Zamierzałem opublikować to jako komentarz, ale to za długo.

Podchodzę do tego inaczej - spróbuj użyć wireshark na karcie sieciowej, która łączy się z telefonem.

Zamknij wszystkie urządzenia korzystające z sieci i wysyłaj / odbieraj od pojedynczych pakietów. Proponuję ping z ustawionym ładunkiem używając flagi -s na linuxie; Nie przypominam sobie flagi Windows. Wyślij znany pakiet, odbierz pakiet i sprawdź swój skrypt oraz wireshark szukając rozbieżności. Jeśli są jakieś, które będziesz mógł zobaczyć w wireshark, jeśli transmitujesz 2x, otrzymujesz 2x lub twój skrypt php ma problemy. W razie potrzeby zwiększ rozmiar transferu do większej, ale znanej wartości. Jeśli to konieczne, przełącz z ping na ftp lub http, ponieważ problem może być zależny od protokołu. np. ICMP i UDP nie wymagają połączenia, TCP nie - TCP może żądać retransmisji na poziomie protokołu, pozostałe dwa nie (UDP może, ale na poziomie aplikacji)

Wireshark powinien mieć „prawdziwą” odpowiedź, chyba że problem dotyczy samego retransmisji telefonu. Prawdopodobnie masz w telefonie narzędzie do pomiaru danych, zresetuj je przed testowaniem, aby sprawdzić, czy zaczyna się ono znacząco oddzielać od liczników wireshark i php.

Zasadniczo sugeruję, abyś potwierdził jego prawdziwy problem i zaczął charakteryzować problem przed nurkowaniem na niski poziom debugowania. W rzeczywistości może to być iptables, ale nie chciałbym tam zacząć. Po wykonaniu tych testów spróbuj uruchomić je ponownie za pomocą niestandardowych reguł iptables i sprawdź zmianę zachowania.

Jeśli zbierzesz te dane, najprawdopodobniej odpowiedź pojawi się, ale jeśli nie, opublikuj wyniki.

Jeśli okaże się, że jest to telefon, możesz wykonać test pętli zwrotnej (przenieść coś do zewnętrznego serwera i przekierować go do ciebie), ale konfiguracja będzie trochę bolesna.