helcoder
-
Posts
13 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by helcoder
-
-
Я сейчас ради интереса удалил все DNS сервера что были на скриншоте, перестало резолвиться вообще что либо. Без разницы делать "nslookup www.google.com 192.168.1.1" или "nslookup www.google.com", в браузере соответственно тоже ничего не открывается. Это разве не доказывает что все DNS запросы идут исключительно через DNS сервера указанные на скриншоте? Я это к тому что не совсем понимаю почему мне нужно что-то назначать и соотносить когда у меня всего один Home сегмент, да есть OpenVPN клиент выключенный, но повторюсь, он у меня уже очень давно, а проблема появилась буквально месяц назад.
-
14 minutes ago, ANDYBOND said:
Что и указывает, что маршрутизатор честно пытается задействовать DNS, не предназначенный для этого клиента, но который Вы разрешили использовать ему самому. Вот сам маршрутизатор и выполняет резолвинг, но клиенту этого не положено знать, потому для клиента резолвинга нет.
Можно как-то понять какой конкретно DNS сервер использует маршрутизатор для конкретного клиента?
14 minutes ago, ANDYBOND said:Да, это скриншот из той области, но важно не только создать профили, но и соотнести их с конкретными клиентами. 8.8.8.8, как понимаю, у Вас в системном профиле.
Так на скриншоте же выключено в системном профиле всё лишнее.
-
39 minutes ago, ANDYBOND said:
Вот. Проблема в профилях DNS, которые Вы понастраивали для разных клиентов, сегментов (Вам виднее). И иногда маршрутизатор путается в том, какие DNS использовать, если у некоторых стоит использовать любое подключение. И тут не важно, включен OVPN или выключен: возможно, Вы дали маршрутизатору указание использовать его DNS в любом случае, и иногда этот случай наступает. Касаемо команды, я дал Вам её правильный вариант, который отображает фактическое положение дел: выбирать маршрутизатор в качестве DNS в команде не нужно, ибо Вы просто отсекли её информацию о том, через что идёт резолвинг, соответственно, ничего не поняли о причинах происходящего. Устраните бардак в профилях DNS, их настройках и соотношениях с клиентами или сегментами - и всё станет хорошо. Никакого любого подключения: один DNS - через одно соединение.
Подскажите, где эти самые профили DNS править? На скрине который я выше скидывал не оно?
Я использовал "nslookup www.google.com 192.168.1.1", т.к. просто "nslookup www.google.com" резолвит в любом случае, даже если на данный момент браузер говорит что домена www.google.com не существует.
-
2 hours ago, keenet07 said:
Перенаправления (маршруты) могут быть прописаны в конфиге OpenVPN изначально. Плюс не должна стоять галочка "Получать маршруты от удаленной стороны" в параметрах VPN подключения.
Он у меня сейчас вообще выключен оказывается, т.ч. точно не в нём дело.
40 minutes ago, ANDYBOND said:А если просто "nslookup www.google.com"?
По-моему когда я последний раз проверял он резолвил через 8.8.8.8. Когда проблемы нет то результат одинаковый как с 192.168.1.1 так и без.
-
OpenVPN клиент у меня поднят очень давно и никаких перенаправлений я намеренно не настраивал, т.ч. вряд ли. DOT попробую добавить, спасибо за совет.
-
Сейчас у меня их прописано два, думаете есть смысл ещё добавлять?
-
Всем доброго дня. Девайс KN-1010, прошивка 3.9.8. С недавнего времени появилась странная проблема, которая выстреливает время от времени. Суть в том что иногда не резолвится www.google.com с любого девайса подключенного к роутеру. Если в этот момент выполнить "nslookup www.google.com 192.168.1.1" то пишет "*** UnKnown can't find www.google.com: Non-existent domain", спустя несколько минут всё начинает резолвиться нормально. Сначала думал что тупит днс сервер провайдера, пробовал его выключать и задавать кастомные, не помогло, потом пробовал настроить DoH, но проблема так и не ушла. Подскажите куда можно копать, может в логах можно что-то интересное на эту тему увидеть?
-
Удалось найти ответ на свой вопрос тут. Оказывается проблема в fastnat.
-
Всем доброго дня. Пытаюсь сделать выборочный роутинг по инструкции https://keenetic-gi.ga/2018/01/16/selective-routing.html , но почему-то соединение просто висит. Не уверен что это поможет, но вот tcpdump с попыткой открыть https://linkedin.com
Spoiler~ # tcpdump -i ovpn_br0 -vv
tcpdump: listening on ovpn_br0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:48:57.536119 IP (tos 0x0, ttl 127, id 12958, offset 0, flags [DF], proto TCP (6), length 52)
192.168.255.6.52157 > 13.107.42.14.https: Flags [S], cksum 0xdfa7 (correct), seq 925931686, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
08:48:57.691822 IP (tos 0x0, ttl 116, id 44032, offset 0, flags [DF], proto TCP (6), length 52)
13.107.42.14.https > 192.168.255.6.52157: Flags [S.], cksum 0x362e (correct), seq 3198608920, ack 925931687, win 65535, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
08:48:57.695452 IP (tos 0x0, ttl 127, id 12959, offset 0, flags [DF], proto TCP (6), length 40)
192.168.255.6.52157 > 13.107.42.14.https: Flags [.], cksum 0x7499 (correct), seq 1, ack 1, win 514, length 0
08:48:57.698313 IP (tos 0x0, ttl 127, id 12960, offset 0, flags [DF], proto TCP (6), length 432)
192.168.255.6.52157 > 13.107.42.14.https: Flags [P.], cksum 0xace8 (correct), seq 1:393, ack 1, win 514, length 392
08:48:57.853623 IP (tos 0x0, ttl 117, id 44033, offset 0, flags [DF], proto TCP (6), length 40)
13.107.42.14.https > 192.168.255.6.52157: Flags [.], cksum 0x6d10 (correct), seq 1, ack 393, win 2051, length 0
08:48:57.854726 IP (tos 0x0, ttl 117, id 44034, offset 0, flags [DF], proto TCP (6), length 1398)
13.107.42.14.https > 192.168.255.6.52157: Flags [.], cksum 0xcfcc (correct), seq 1:1359, ack 393, win 2051, length 1358
08:48:57.855144 IP (tos 0x0, ttl 117, id 44035, offset 0, flags [DF], proto TCP (6), length 1398)
13.107.42.14.https > 192.168.255.6.52157: Flags [.], cksum 0xe2c1 (correct), seq 1359:2717, ack 393, win 2051, length 1358
08:48:57.855485 IP (tos 0x0, ttl 117, id 44036, offset 0, flags [DF], proto TCP (6), length 1038)
13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xcdf8 (correct), seq 2717:3715, ack 393, win 2051, length 998
08:48:57.858017 IP (tos 0x0, ttl 127, id 12961, offset 0, flags [DF], proto TCP (6), length 40)
192.168.255.6.52157 > 13.107.42.14.https: Flags [.], cksum 0x6880 (correct), seq 393, ack 2717, win 503, length 0
08:48:57.858097 IP (tos 0x0, ttl 127, id 12962, offset 0, flags [DF], proto TCP (6), length 40)
192.168.255.6.52157 > 13.107.42.14.https: Flags [.], cksum 0x6875 (correct), seq 393, ack 2717, win 514, length 0
08:48:57.875542 IP (tos 0x0, ttl 127, id 12963, offset 0, flags [DF], proto TCP (6), length 198)
192.168.255.6.52157 > 13.107.42.14.https: Flags [P.], cksum 0xc2c3 (correct), seq 393:551, ack 3715, win 510, length 158
08:48:58.030963 IP (tos 0x0, ttl 117, id 44037, offset 0, flags [DF], proto TCP (6), length 40)
13.107.42.14.https > 192.168.255.6.52157: Flags [.], cksum 0x5df1 (correct), seq 3715, ack 551, win 2050, length 0
08:48:58.032235 IP (tos 0x0, ttl 117, id 44038, offset 0, flags [DF], proto TCP (6), length 91)
13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:48:58.380668 IP (tos 0x0, ttl 116, id 44039, offset 0, flags [DF], proto TCP (6), length 91)
13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:48:58.740483 IP (tos 0x0, ttl 117, id 44040, offset 0, flags [DF], proto TCP (6), length 91)
13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:48:59.439163 IP (tos 0x0, ttl 117, id 44041, offset 0, flags [DF], proto TCP (6), length 91)
13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:49:00.835664 IP (tos 0x0, ttl 117, id 44042, offset 0, flags [DF], proto TCP (6), length 91)
13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:49:02.765293 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 13.107.42.14 tell 192.168.255.6, length 28
08:49:02.765332 ARP, Ethernet (len 6), IPv4 (len 4), Reply 13.107.42.14 is-at de:72:0d:a2:a8:0e (oui Unknown), length 28
08:49:03.628367 IP (tos 0x0, ttl 117, id 44043, offset 0, flags [DF], proto TCP (6), length 91)
13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:49:09.212746 IP (tos 0x0, ttl 117, id 44044, offset 0, flags [DF], proto TCP (6), length 91)
13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51Если задать прямой маршрут ip route add 13.107.42.14 dev ovpn_br0, то всё работает, но через ipset ни в какую не хочет. Подскажите, куда можно подсмотреть чтобы понять в чём проблема?
-
Возник ещё один вопрос. Подскажите пожалуйста, есть ли возможность перенаправления с домена 4-го уровня по протоколам отличным от HTTP и HTTPS? Т.е. к примеру в локальной сети есть 2 linux машины и к ним нужен удалённый доступ по SSH:
$ ssh linux1.router.keenetic.pro
$ ssh linux2.router.keenetic.pro
Понимаю что всегда можно всё сделать через перенаправление портов, но интересно можно ли сделать перенаправление именно за счёт доменного имени.
-
12 minutes ago, ndm said:
Если имеется в виду домен 4-го уровня {iis}.{domain}.keenetic.pro, то есть такая настройка в CLI:
(config)> ip http proxy {iis} preserve-hostТак он сохранит оригинальный заголовок Host при проксировании.
Магия, работает просто замечательно. Спасибо!
3 hours ago, ajs said:А просто настроить проброс внешнего порта 80 на 192.168.1.99:80? Тогда не важно как попали на роутер из вне на этот порт, по IP по KeenDNS по Другому доменному имени, сайт будет работать с тем как на него вошли ...
https://help.keenetic.com/hc/ru/articles/360000360760-Переадресация-портов
Проблема решена, но чисто из любопытства спрошу. Это я так понимаю имеется ввиду что заходить я буду по доменному имени 3-го уровня и вместо вэб интерфейса роутера меня будет перенаправлять на 80 порт локальной машины? Если так, то это конечно тоже вариант, но не такой гибкий и настроить будет возможно только 1 сайт, если я правильно понимаю.
-
Всем доброго дня. Имеется следующая связка:
- Роутер KN-1010, на котором настроен внешний домен (KeenDNS) замапленный на локальный адрес - 192.168.1.99:80
- Локальная машина с адресом 192.168.1.99, на которой стоит IIS и слушает 80 порт.
- На IIS поднят вэбсайт, который забинден на 192.168.1.99:80
В данной связке всё работает, но проблема в том, что поскольку к вэбсайту все реквесты идут на 192.168.1.99:80, то он собственно ничего не знает о внешнем доменном имени, по которому к нему обращаются, и из-за этого вэбсайт ведёт себя не совсем корректно.
Собственно вопрос, возможно ли как-то донести реквест с внешним адресом до локальной машины? Если да, то на IIS останется только сайт забиндить на это доменное имя и будет работать как часы.
PS Я пробовал мапить домен с помощью ip host и оно работает в рамках локальной сети, но к сожалению при обращении из внешней сети к локальной машине запрос всё-равно идёт по ip адресу, а не по доменному имени.
Иногда не отрабатывает DNS
in Обмен опытом
Posted
Вот только что проблему словил ещё раз, интересный результат получился в этот раз:
nslookup www.google.com
Server: UnKnown
Address: 192.168.1.1
Name: www.google.com
Addresses: 2a00:1450:4010:c0f::69
2a00:1450:4010:c0f::6a
2a00:1450:4010:c0f::68
2a00:1450:4010:c0f::63
Вернулись только ipv6, как-то всё это очень странно.