Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Witam.
Potrzebuje pomocy zwiazanej z konfiguracja iptables na maszynie, ktora robi za router w mojej sieci.
Glowna potrzeba: dostep przez internet do rejestratora kamer z monitoringu.
Przeczytalem tysiac tutoriali itp. Niestety nie radze sobie z Iptables.
Mam VPS, ze stalym IP i z odpalonym serwerem OpenVPN, ktory przyjmuje polaczenia i przez ten tunel puszcza ruch.
W chwili obecnej system dziala tak, ze jak odpale na routerze OpenVPN to ruch od routera w internet idzie przez tunel, ale ruch z urzadzen za routerem dociera tylko do routera i dalej go puszcza.
Zalaczam schemat sieci. Jesli potrzeba jakies logi, lub pliki conf to mowcie.
I naprawde niech sie ktos nade mna zlituje bo osiwieje przedwczesnie... :)[img]http://eksprespak.pl/img.jpg[/img]
Offline
Pokaż wynik polecenia: # ip route show ( z routera na debianie)
i jeszcze zapodaj konfiga tego iptablesa na routerze co tam wyklikałeś, może forward wystarczy dodać tylko.
Ostatnio edytowany przez stepien86 (2017-04-12 19:29:34)
Offline
Ok prosze bardzo.
Przed odpaleniem OpenVPN
default via 192.168.0.1 dev eth1 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.10 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
Po uruchomieniu
0.0.0.0/1 via 192.168.3.1 dev tun0 default via 192.168.0.1 dev eth1 51.254.208.185 via 192.168.0.1 dev eth1 128.0.0.0/1 via 192.168.3.1 dev tun0 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.10 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 192.168.3.0/24 dev tun0 proto kernel scope link src 192.168.3.2
Iptables:
Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 192.168.3.0/24 192.168.1.0/24 ctstate NEW Chain OUTPUT (policy ACCEPT) target prot opt source destination
Offline
Ponawiam prosbe do zgromadzonych tutaj :P
Offline
Do OpenVPN musisz puścić routing default, a tylko OpenVPN (jako usera systemowego) albo ruch do VPSa (routing do hosta) puścić przez eth1.
Masz problem nie z netfiterem/iptables tylko z routingiem.
Przy okazji, OpenVPN moim zdaniem troszkę lepiej chodzi przez interfejsy TAP niż TUN, ale wtedy musi działać na protokole TCP, nie UDP.
Jeśli chcesz na TUP/TAP wyciągnąć większe prędkości, niż 10Mbit, to potrzebujesz tej łatki na kernele (na obu końcach tunelu):
diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 8c8dc16..64f4dcc 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -950,6 +950,9 @@ static void tun_net_init(struct net_device *dev) dev->addr_len = 0; dev->mtu = 1500; + /* Set default speed 1000M */ + tun->flags |= TUN_CTRL_SPD_1000; + /* Zero header length */ dev->type = ARPHRD_NONE; dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST; @@ -2257,9 +2260,18 @@ static struct miscdevice tun_miscdev = { static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { + struct tun_struct *tun = netdev_priv(dev); + + /*Get the speed of tun*/ + if (tun->flags & TUN_CTRL_SPD_1000) { + ethtool_cmd_speed_set(cmd, SPEED_1000); + } else if (tun->flags & TUN_CTRL_SPD_100) { + ethtool_cmd_speed_set(cmd, SPEED_100); + } else + ethtool_cmd_speed_set(cmd, SPEED_10); + cmd->supported = 0; cmd->advertising = 0; - ethtool_cmd_speed_set(cmd, SPEED_10); cmd->duplex = DUPLEX_FULL; cmd->port = PORT_TP; cmd->phy_address = 0; @@ -2287,6 +2299,27 @@ static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info } } +static int tun_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) +{ + struct tun_struct *tun = netdev_priv(dev); + u32 speed = ethtool_cmd_speed(cmd); + + if (10 == speed) { + tun->flags &= ~TUN_CTRL_SPD_100; + tun->flags &= ~TUN_CTRL_SPD_1000; + tun->flags |= TUN_CTRL_SPD_10; + } else if (100 == speed) { + tun->flags &= ~TUN_CTRL_SPD_10; + tun->flags &= ~TUN_CTRL_SPD_1000; + tun->flags |= TUN_CTRL_SPD_100; + } else { + tun->flags &= ~TUN_CTRL_SPD_10; + tun->flags &= ~TUN_CTRL_SPD_100; + tun->flags |= TUN_CTRL_SPD_1000; + } + return 0; +} + static u32 tun_get_msglevel(struct net_device *dev) { #ifdef TUN_DEBUG @@ -2307,6 +2340,7 @@ static void tun_set_msglevel(struct net_device *dev, u32 value) static const struct ethtool_ops tun_ethtool_ops = { .get_settings = tun_get_settings, + .set_settings = tun_set_settings, .get_drvinfo = tun_get_drvinfo, .get_msglevel = tun_get_msglevel, .set_msglevel = tun_set_msglevel, diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h index 50ae243..78a09a7 100644 --- a/include/uapi/linux/if_tun.h +++ b/include/uapi/linux/if_tun.h @@ -66,6 +66,11 @@ #define IFF_PERSIST 0x0800 #define IFF_NOFILTER 0x1000 +/*add speed control, default 1000M*/ +#define TUN_CTRL_SPD_10 0x0020 +#define TUN_CTRL_SPD_100 0x0040 +#define TUN_CTRL_SPD_1000 0x0080 + /* Socket options */ #define TUN_TX_TIMESTAMP 1
Używam tej łatki od dawna, na źródła z kernel.org wchodzi czysto - wszystkie z serii 4.7.x, 4.8.x i 4.9.x.
Pozdro
Ostatnio edytowany przez Jacekalex (2017-04-15 21:30:11)
Offline
Pozwolę sobie wrzucić swoje trzy grosze jako gość który wczoraj zestawił OpenVPNa do domu
Przy okazji, OpenVPN moim zdaniem troszkę lepiej chodzi przez interfejsy TAP niż TUN,[/quote]
Mocno się nie zgodzę- ja miałem niesamowite problemy z zestawieniem łącza w L2- pomijając fakt że chcąc korzystać z zasobów zza VPNa na Androidach trzeba rootować urzadzenie.
Zęby prawie sobie połamałem z VPNem, a w moim wypadku chodziło o firewalla ;)
Także [b]immcio[/b], sprawdź po zestawieniu tunelu czy jesteś w stanie pingować 192.168.3.1. Logi iptables z serwera VPN też przydałyby się, bo ja tylko dzięki logom doszedłem do wstępnych błędnych opcji konfiguracji.
Dalej: na początku cos pisałeś że po zestawieniu tunelu ruch idzie przez niego- czyli jesteś w stanie przeglądać internety jako modem lte? W sensie, na komputerze- kliencie VPN po sprawdzeniu adresu IP pod jakim jesteś widziany pokazuje Ci adres nadany przez modem LTE?
Offline
Mocno się nie zgodzę- ja miałem niesamowite problemy z zestawieniem łącza w L2- [b]pomijając fakt że chcąc korzystać z zasobów zza VPNa na Androidach trzeba rootować urzadzenie[/b].[/quote]
Co to za problemy z tym rootowaniem?
Na Linuksach i BSD wszyscy mamy dostęp do roota na swoich gratach,
i jakoś nasze systemy brykają jak dzikie bez żadnych problemów.
To co za problem z tym Andkiem?
Kupować tylko graty, które odblokujesz przez fastboota, i nie tracisz gwarancji po roocie (na co już jest wyrok Europejskiego Trybunału Praw Człowieka).
To przecież nie dwumian Newtona, trzeba mieć tylko odrobinkę oleju w głowie przed zakupem.
Tam na rysunku Debian gada z VPSem, a jeszcze nie widziałem Andka bez roota na VPS. xDOstatnio edytowany przez Jacekalex (2017-04-15 22:12:32)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
Problemy są takie, że do utworzenia interfejsu TAP potrzebujesz superjuzka, a do TUN już nie :)
TUN spełnia swoją rolę nader wyśmienicie, chyba że masz coś co komunikuje się stricte po L2 jak jakieś discovery Mikrotików; ale ja z powodzeniem korzystam z zasobów NFS, HTTP, SSH przez interfejs TUN, czy to na lapku (gdzie mam ruta xD) czy na służbofonie (gdzie ruta mieć nie będę). Także nie widzę powodu by dla tak trywialnych zastosowań iść w schemat oparty o interfejsy TAP.
Na rysunku domyślam się że na VPSie nie stoi Andek, z rootem czy bez. Mówię o scenariuszu w którym OP chciałby podejrzeć obraz na żywo z kamer na jakimś andku.
Offline
Służbofona? Do szuflady grata, chyba że nie słyszałeś o Dual SIM - dual standby. xD
Przy okazji, ja nie zabraniam używania TUN, tylko wolę TAP, bo po prostu przy TAP mam praktycznie normalną kartę sieciową VPNa, co mocno upraszcza życiorys.
Offline
[b]Jacekalex:[/b] Jakos od poczatku intuicyjnie myslalem o TAP. Po Twoim poscie postanowilem postawic vpn na tap. I pojawil sie pierwszy, dla mnie mocno nie zrozumialy problem. Mianowicie, czy mam robic bridge servera z eth0 na VPS? Jesli tak to jak skoro eth0 ma IP zewnetrzne VPS? W momencie kiedy bridguje tap0 z eth0 na VPS to wywala caly ruch do i z VPSa, dopiero restart calego networking przywraca IP, maske i reszte w ifconfig dla eth0. Wiem ze cala zabawa z OpenVPN jest prosta, ale jak dla mnie malo logiczna :P.
Pozdrawiam
___
Ok, wiec jeszcze raz wszystko od poczatku:
Ponizej nowa mysl jesli chodzi o polaczenie z VPS.
[img]http://eksprespak.pl/img2.jpg[/img]
Chodzi o to, zeby vps pelnil role gatewaya do LAN za NAT. Czyli, zeby dostac sie do LAN i np na rejestrator video, musze sie polaczyc z OpenVPN na VPS. Urzadzenie laczace sie z VPS stanie sie kolejnym urzadzeniem w LAN.
Takie zestawienie sprawy o wiele bardziej mi odpowiada.
Ide dobrym tokiem rozumowania, czy mnie ponioslo?
Czy na VPS musze cos ze soba bridgowac? Jesli tak to co i jak. Bo nie logicznym wydaje mi sie bridgowanie z obecnym eth0, poniewaz wyglada ono tak:
eth0 Link encap:Ethernet HWaddr fa:16:3e:07:3e:37 inet addr:51.254.208.185 Bcast:51.254.208.185 Mask:255.255.255.255 inet6 addr: fe80::f816:3eff:fe07:3e37/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:21160 errors:0 dropped:0 overruns:0 frame:0 TX packets:21209 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1234738 (1.1 MiB) TX bytes:2107169 (2.0 MiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:267 errors:0 dropped:0 overruns:0 frame:0 TX packets:267 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:19188 (18.7 KiB) TX bytes:19188 (18.7 KiB)
W momencie, gdy probowalem bridgowac eth0 z tap0 na VPS, to ucinal sie caly ruch z i na VPS. Musialem z konsoli restartowac networking.
Z kolei odpalony bez bridge tworzy tap0, ale bez zadnych adresow:
tap0 Link encap:Ethernet HWaddr fa:16:3e:07:3e:37 UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Polaczenie miedzy client - server bez ustawionych bridgow rowniez sie odbywa, ale nie ma odpowiedzi na ping ani z servera ani z klienta.
Jesli dobrze to wszystko rozumiem, to bridge musi nastapic miedzy tap0 a eth1 na routerze w lan za natem, czyli na polaczeniu clienta vpn.
Wszystkie tutoriale dotyczace TAP na VPN jakie znalazlem, nawet te pochodzace z manuala openvpn, dotyczyly sytuacji gdy server VPN znajduje sie w LAN, do ktorego sie laczy client i uzyskuje do niego dostep. W takiej sytuacji jest logiczne, ze bridguje sie tap z eth na serwerze. Ale w mojej sytuacji jest to kompletnie bez sensu...
Gdyby ktos mial chwile to prosze o wyjasnienie i pomoc.
Pozdrawiam
Offline
Nie mostkuj tap z eth0, tylko routing default puść na tap od VPNa.
Mostek interfejsu fizycznego z interfejsem wirtualnym do VPN to katastrofalna wtopa, która nie ma prawa działać.
Albo zrozumiesz sprawy routingu w linuxie, albo się w ogóle nie bierz za te systemy.
Tu masz dosyć ważny dokument po polsku:
www.przybytek.net/download/2.4routing.pdf
Ostatnio edytowany przez Jacekalex (2017-04-18 20:12:30)
Offline
[b]@Jacekalex[/b]: Wiec dobrze myslalem. Poprostu sugerowalem sie wieloma tutorialami, ktore tak jak wspomnialem, nie przedstawialy mojej sytuacji.
Ok, dzieki za ten dokument. Jak uda mi sie postawic tego vpn w tej konfiguracji, to podziele sie tym
Pozdrawiam
Offline
Najprostsza konfiguracja routingu na OpenVPN:
route add -host {server_vpn} gw 192.168.0.1 eth1
Czyli ta trasa po włączeniu VPNa
51.254.208.185 via 192.168.0.1 dev eth1
była prawidłowa.
Problem był tu:
default via 192.168.0.1 dev eth1
Bo po prostu, żeby programy leciały przez VPN, trasa default musi kierować do VPN, czyli:
default via 192.168.3.1 dev tun0
Łatwiej taki cel osiągnąć na interfejsach TAP, ale nie zawsze da się je zastosować.
Ostatnio edytowany przez Jacekalex (2017-04-18 20:24:32)
Offline
[b]@Jacekalex[/b]: No to jednak mam uzywac tun? Mysle ze tapem tez sie da...
Offline
TUN czy TAP, routing jest taki sam.
TAP ma tą przewagę, że jest interfejsem obsługującym L2, czyli praktycznie pełnowartościową, chociaż wirtualną kartą sieciową.
Jeśli można używać TAP, powinien działać lepiej, jeśli nie można założyć interfejsu TAP, zostaje TUN, też będzie działał.
Na połączeniu VPS<>Debian zazwyczaj nie masz takich ograniczeń, jak np łącząc się ze smartfona, na którym nie masz roota.
Chyba że VPS jest na wirtualizacji OpenVZ albo LXC bez sterowników TUN/TAP, ale wtedy w ogóle byś VPNa nie odpalił.
Ostatnio edytowany przez Jacekalex (2017-04-18 21:21:10)
Offline
Nie no na VPS jest tez debian, takze dostep do roota bede mial tu zawsze...
Wiec ok, bedzie TAP + routing do tego i ma smigac tak? Zadnych mostkow, poprostu odpowiednie tabele i kazde urzadzenie ktore sie prawidlowo polaczy z OpenVPN na VPS zostanie pelnoprawnym urzedzeniem w LAN za NAT?
Bo caly czas mnie frapuje kwestia zwiazana np z tym, ze nawet w oficjalnej dokumentacji OpenVPN calosc opiera sie na mostach, z tym ze w tamtych przypadkach VPN jest elemnetem LAN, i kazdy klient do tego lanu sie dolacza. A u mnie bedzie odwrotnie... Serwer ma byc furtka do lanu, ktory sie do niego dolacza...
Offline
Póki kaczka dupy nie umoczy, pływać się nie nauczy.
Spróbuj zrobić prawidłowo routing do VPS, jak się nie uda, to będziemy dalej kombinować, ale powinno się udać.
Offline
[quote=Jacekalex]Problem był tu:
default via 192.168.0.1 dev eth1
Bo po prostu, żeby programy leciały przez VPN, trasa default musi kierować do VPN, czyli:
default via 192.168.3.1 dev tun0
[/quote]
No nie do końca. Można zostawić default tak jak jest i dorobić te dwa poniższe wpisy w tablicy routingu:
0.0.0.0/1 via 10.80.0.1 dev tun0 128.0.0.0/1 via 10.80.0.1 dev tun0 ... default via 192.168.1.1 dev bond0 metric 10
Nie trzeba tego ręcznie wpisywać, wystarczy w konfiguracji serwera dodać:
push "redirect-gateway def1 bypass-dhcp"
I to automatycznie doda te dwa powyższe wpisy w tablicach routingu każdego z klientów, który się do serwera VPN podłączy. [url=https://morfitronik.pl/jak-skonfigurowac-serwer-vpn-na-debianie-openvpn/]Jak coś to tutaj jest więcej info[/url] ale tam w tablicy routingu już te wpisy siedzą, więc tutaj nie ma problemu.
Jeśli chcesz na TUP/TAP wyciągnąć większe prędkości, niż 10Mbit, to potrzebujesz tej łatki na kernele (na obu końcach tunelu):[/quote]
Jak to? U mnie bez żadnych łat (debian założył?) na moim VPS wyciągam po VPN około 40 mbit/s.Ostatnio edytowany przez morfik (2017-04-19 06:57:56)
Offline
Dobra wiec po kilku dniach walki wrocilem do opcji tun, bo tap nie chodzil jak trzeba. Komputery sie nie widzialy i nie mialem cierpliwosci zeby sie w tym babrac.
W tej chwili mam:
Struktura i adresacja tak jak na pierwszym obrazku powyzej.
Server widzi klienta i odwrotnie.
Ruch z sieci lan idzie przez LTE - tak jak chcialem
Gdy puszczam na komputerze z lan traceroute 192.168.3.1 - czyli na adres servera openvpn, to ruch odbywa sie przez tun0
Stanalem na routingu do rejestratora IP. Rejestrator jest na 192.168.1.189:80. Pod spodem sa wpisy w iptables:
ROUTER (klient vpn):
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT icmp -- anywhere anywhere icmp echo-reply ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere 192.168.1.189 tcp dpt:5800 ACCEPT tcp -- anywhere 192.168.3.2 tcp dpt:http ACCEPT tcp -- anywhere 192.168.3.2 tcp dpt:http-alt ACCEPT tcp -- anywhere 192.168.3.2 tcp dpt:http-alt ACCEPT tcp -- anywhere 192.168.1.189 tcp dpt:http-alt ACCEPT tcp -- anywhere 192.168.1.189 tcp dpt:http ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- 192.168.1.0/24 anywhere ctstate NEW ACCEPT all -- 192.168.3.0/24 anywhere ctstate NEW ACCEPT all -- 192.168.3.0/24 192.168.1.0/24 ctstate NEW ACCEPT all -- 192.168.1.0/24 anywhere ACCEPT all -- anywhere 192.168.1.0/24 ACCEPT all -- anywhere 192.168.3.0/24 ACCEPT all -- anywhere 192.168.3.0/24 ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- 192.168.0.0/16 anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT icmp -- anywhere anywhere icmp echo-reply
Server VPS (Server VPN):
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT icmp -- anywhere anywhere icmp echo-reply ACCEPT udp -- anywhere anywhere udp dpt:openvpn ctstate NEW /* vpn */ Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere 192.168.3.2 tcp dpt:5800 ACCEPT tcp -- anywhere 192.168.3.2 tcp dpt:http ACCEPT tcp -- anywhere 192.168.3.2 tcp dpt:http-alt ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- 192.168.1.0/24 anywhere ACCEPT all -- anywhere 192.168.1.0/24 ACCEPT all -- 192.168.3.0/24 anywhere ACCEPT all -- anywhere 192.168.3.0/24 Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT icmp -- anywhere anywhere icmp echo-reply ACCEPT icmp -- anywhere anywhere icmp echo-request
Przy probie polaczenia przez np www to przegladarka mieli, nastepuje polaczenie, jednak zrywa z powodu timeout timeout. Wnioskuje ze jednak cos nie tak jest z routingiem od routera do rejestratora...
Ponizej jeszcze iptables jakich uzylem:
Server
iptables -I FORWARD -i eth0 -p tcp -d 192.168.3.2 --dport 8080 -j ACCEPT iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.3.2:8080
Router
iptables -I FORWARD -i tun0 -p tcp -d 192.168.1.189 --dport 8080 -j ACCEPT iptables -t nat -I PREROUTING -i tun0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.189:80
Jeszcze dodam ze przy probie polaczenie przez http://192.168.3.2 z komputera w lan to pieknie sie laczy z serwerem www na routerze, ale jak dodam port 8080 to nie moze nawiazac polaczenia...
Ostatnio edytowany przez immcio (2017-04-22 09:30:27)
Offline
Time (s) | Query |
---|---|
0.00010 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00135 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.116.63.105' WHERE u.id=1 |
0.00071 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.116.63.105', 1730415745) |
0.00047 | SELECT * FROM punbb_online WHERE logged<1730415445 |
0.00071 | DELETE FROM punbb_online WHERE ident='85.208.96.194' |
0.00071 | SELECT topic_id FROM punbb_posts WHERE id=310047 |
0.00005 | SELECT id FROM punbb_posts WHERE topic_id=29497 ORDER BY posted |
0.00047 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=29497 AND t.moved_to IS NULL |
0.00006 | SELECT search_for, replace_with FROM punbb_censoring |
0.00174 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=29497 ORDER BY p.id LIMIT 0,25 |
0.00090 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=29497 |
Total query time: 0.00731 s |