|
Сервер посылает пакеты вовне со своим локальным адресом (192.168.x.x).
Странная ситуация.
Имеется сервер, вывод его ifconfig: Код:
eth0 Link encap:Ethernet HWaddr XXXXXXXXXXXXКод:
root@my-server:~# tcpdump icmpКод:
root@my-server:~# tcpdump port 6600Что это за фигня и как быть? |
попробуй открыть порт на my-server и просканировать этот хост с 192.168.100.9
Цитата:
Цитата:
PS могу предположить что это из-за фаервола на my-server |
Цитата:
Цитата:
Цитата:
|
Повторюсь.
просканируй хост myserver с 192.168.100.9, напиши его ip адрес и выложи iptables -L -n с myserver. |
Цитата:
PS RST пакет был потому, что когда я делал tcpdump в это время netcat не слушал порт. Т.е. nc -l -p 8080 - коннекта нет, вырубал его, и делал tcpdump port 8080 Код:
root@my-server:~# iptables -L -n |
Сделай netstat -nr
Проблемы с маршутизацией, очевидно. |
Цитата:
Раз даже пинги обратно не приходят: PING 88.1.8.5 (88.1.8.5) 56(84) bytes of data. --- 88.1.8.5 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms Вот netstat -nr: Код:
Kernel IP routing table |
Вобщем, судя по всему у тебя на 192.168.100.4 стоит просто NAT без переименовывания заголовков (аля тупо форвардинг пакетов), это причина того, что тебе приходят пакеты с IP твоей машины (192.168.100.9) вместо внешнего IP от машины с 192.168.100.4 адресом.
Идем дальше, допустим твой my-server знает маршут до 192.168.100.9 (не суть как). Тогда 192.168.100.4 должен знать куда перенаправить пакет, т.е. к тебе на 192.168.100.9. Поскольку обычно делают port-forwarding, а доступ на прямую к машинам в локальных сетях предоставляют только по vpn, в твоем случае нужно чтобы на 192.168.100.4 был правильно сконфигурирован NAT. Для линукса: iptables -t nat -I POSTROUTING -s 192.168.100.0/24 -j SNAT --to-source ${EXT_IP_OF_192.168.100.4} iptables -A FORWARD -j ACCEPT Метод port-forwarding (прямой коннект к 192.168.100.9, порт 44555 через внешний IP 192.168.100.4, порт 34555): iptables -t nat -I PREROUTING -p tcp -m tcp --dport 34555 -d ${EXT_IP_OF_192.168.100.4} -i ${EXT_IFACE_OF_192.168.100.4} -j DNAT --to 192.168.100.9:44555 Также есть вероятность, что для forwarding-пакетов на 192.168.100.4 закрыты определенные порты или протоколы (т.е. icmp у тебя может успешно проходить все остальное - нет). Следовательно можно попробовать завесить иницирование открытие стандартных портов (22, 25, 80, 110, 33434-33523) на 192.168.100.9. Тогда есть вероятность, что 192.168.100.4 пропустить пакеты до твоей машины. Случай, когда ты коннектишься к 192.168.100.4 через vpn: 1. OpenVPN, нужно чтобы сервер выдавал тебе (my-server) таблицу маршутизации к своей сети (192.168.100.0/24). Делается это в конфиге openvpn. Тупое прописывание у себя такого маршута ни к чему не приведет, openvpn жестко отслеживает подобное. 2. vtun - тут можно и самому прописать соответствующий маршут. 3. Что-то иное - нужно тестировать и смотреть самому. |
ghostwizard
Спасибо!. Насколько я знаю, все это требует привелегий рута... PS Тогда ищется программа, которая может передавать файлы без получения обратных пакетов. Пока нашел hping, но может есть специалньо для этого сделанная программа, которая на обоих хостах запускается и передает файлы? PPS hping не подходит - требует рута для открытия сырых сокетов. И еще, почитал - идеальной была бы прога, которая посылает файлы по UDP, однако все, что гугл подсказал все-равно на разных стадиях требуют ответа от получателя. А идеальна была бы та, которая просто посылает все пакеты дважды например, а уж потом можно ей было бы дать команды переслать определённые части за номерами такими-то (которые бы увидел на получателе)... |
Цитата:
|
| Время: 20:52 |