On Thu, 27 Sep 2012, alex alex wrote:

Salut.

Lipseste dump-ul pachetului ICMP (pachetul UDP original).
Poti sa refaci tcpdump-ul, te rog?

> E accesibil, insa nu e  direct conectat. Din B:
> ping 172.16.116.142
> PING 172.16.116.142 (172.16.116.142) 56(84) bytes of data.
> 64 bytes from 172.16.116.142: icmp_seq=1 ttl=61 time=5.16 ms
> 64 bytes from 172.16.116.142: icmp_seq=2 ttl=61 time=1.75 ms
> La rute:
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 172.16.116.142  172.16.217.61   255.255.255.255 UGH   0      0        0 eth0
>
>
> Oricum ,nu inteleg care ar fi ideea sa fie direct conectat.
>
>
>
> 2012/9/27 Alex 'CAVE' Cernat <[email protected]>
>
>>  ce netmask e pus pe eth0 ? sigur e accesibil serverul A direct de pe B ?
>>
>>
>> 9/27/2012 10:38 AM, alex alex wrote:
>>
>> Schema e simpla (A, B, C sunt calculatoarele; intre ele sunt rutere (R)) :
>>
>>             A
>> -------------------------------             Eth0               ----------
>> Eth1 172.20.44.36                  10.199.25.58
>> |eth0 172.16.116.142| ------|R|-------------------------|B       |
>> --------------------------------|R| ---------------| C|
>> ------------------------------             172.16.217.61   |         |----
>> Eth2
>>
>> -----------      |
>>
>> -------------------Alta retea
>>
>>
>>
>> Pachetele vin pe eth1 (calculatorul B):
>>  tcpdump -nli eth1 host 10.199.25.58 -nnN
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
>> 10:29:43.640171 IP 10.199.25.58.65522 > 172.20.44.36.1234: UDP, length 1464
>> 10:29:43.675942 IP 10.199.25.58.65522 > 172.20.44.36.1234: UDP, length 1464
>>
>> C este doar sursa, pachetele sunt UDP. Nu e necesara conexiune
>> bidirectionala ci numai C->A (asta ar fi scopul).
>> Stiu ca am mai facut acelasi lucru acum ceva timp si simt ca-mi scapa
>> ceva.Daca aveti idei, shoot!
>> Multumesc,
>> alex
>>
>>
>> 2012/9/27 Alex 'CAVE' Cernat <[email protected]>
>>
>>> pare in regula la prima vedere (nu stiu de ce te-ai complicat cu
>>> chain-uri in plus, dar in fine, daca ti-e mai usor atunci asa sa fie - de
>>> fapt vad ca si loghezi pe acolo, e mai simplu de gandit asa)
>>>
>>> o singura nedumerire am: sigur e eth1 interfata pe care vin pachetele de
>>> dnat-uit ?
>>>
>>> cred ca nu ar strica si un mic de ascii art, cu schema retelei (adica
>>> cele 3 calculatoare din problema), pe ce eth-uri sunt conectate, eventual
>>> ceva adrese ip (pe bune sau 'pireli', dupa cum preferi sa divulgi
>>> informatiile - oricum sunt deja in tcpdump)
>>>
>>>
>>> On 9/27/2012 9:02 AM, alex alex wrote:
>>>
>>>>  Salut,
>>>> am nevoie de un cap limpede in setarea unui DNAT.
>>>> Pe scurt,am 3 calculatoare (A,B,C). B face masquerade (iptables) pentru
>>>> A.
>>>> In acelasi timp, C trimite pachete UDP catre B, la un port specific
>>>> (1234).
>>>> Vreau ca acele pachete sa ajunga la A.
>>>> Ce am facut:
>>>> iptables -t nat -N forward_to_server
>>>> iptables -t nat -A forward_to_server  -j LOG --log-prefix " [>] New
>>>> Forward"
>>>> iptables -t nat -A forward_to_server -p udp -j DNAT --to
>>>> 172.16.116.142:9996
>>>> iptables -t nat -I PREROUTING -i eth1 -p udp  --dport 1234 -j
>>>> forward_to_server
>>>>
>>>>
>>>> Rezultatul este
>>>>
>>>> iptables -L -n -v -t nat
>>>> Chain PREROUTING (policy ACCEPT 6837 packets, 668K bytes)
>>>>   pkts bytes target     prot opt in     out     source
>>>> destination
>>>>      0     0 forward_to_server  udp  --  eth1   *       0.0.0.0/0
>>>> 0.0.0.0/0           udp dpt:1234
>>>>
>>>> Chain POSTROUTING (policy ACCEPT 9350 packets, 785K bytes)
>>>>   pkts bytes target     prot opt in     out     source
>>>> destination
>>>> 33527 2914K MASQUERADE  all  --  *      eth1    0.0.0.0/0
>>>> 0.0.0.0/0
>>>>     65  5460 MASQUERADE  all  --  *      eth2    0.0.0.0/0
>>>> 0.0.0.0/0
>>>>
>>>> Chain OUTPUT (policy ACCEPT 36414 packets, 3058K bytes)
>>>>   pkts bytes target     prot opt in     out     source
>>>> destination
>>>>
>>>> Chain forward_to_server (1 references)
>>>>   pkts bytes target     prot opt in     out     source
>>>> destination
>>>>      0     0 LOG        all  --  *      *       0.0.0.0/0
>>>> 0.0.0.0/0           LOG flags 0 level 4 prefix ` [>] New Forward'
>>>>      0     0 DNAT       udp  --  *      *       0.0.0.0/0
>>>> 0.0.0.0/0           to:172.16.116.142:9996
>>>>
>>>> Totusi, nici un pachet nu atinge regula mea din Prerouting (cel putin asa
>>>> pare), desi nu am alte filtre (celalalte tabele sunt policy ACCEPT).
>>>> Desigur, in acest timp exista pachete care vin catre B, numai ca nu sunt
>>>> selectate.
>>>> 08:56:09.311323 IP 10.199.25.58.65522 > 172.20.44.36.1234: UDP, length
>>>> 1464
>>>> 08:56:09.365042 IP 10.199.25.58.65522 > 172.20.44.36.1234: UDP, length
>>>> 1464
>>>> 08:56:09.365075 IP 172.20.44.36 > 10.199.25.58: ICMP 172.20.44.36 udp
>>>> port
>>>> 1234 unreachable, length 556
>>>> Simt ca imi lipseste ceva, dar nu stiu ce. M-ar ajuta un hint care sa ma
>>>> scoata din blocaj.
>>>> Multumesc,
>>>> alex
>>>>  _______________________________________________
>>>> RLUG mailing list
>>>> [email protected]
>>>> http://lists.lug.ro/mailman/listinfo/rlug
>>>>
>>>
>>>
>>
>>
> _______________________________________________
> RLUG mailing list
> [email protected]
> http://lists.lug.ro/mailman/listinfo/rlug
>

--
Catalin(ux) M. BOIE
http://kernel.embedromix.ro/
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug

Raspunde prin e-mail lui