# Dwie bramki VoIP za NAT

## manwe_

Witam. Mam problem z drugą bramką VoIP [najpopularniejsza, Linksys PAP2T]. Jest router na Gentoo, który korzysta z dwóch ISP - jeden do ruchu NAT, a drugi jako backup i dla daemonów. Pierwszy ISP jest rozdzielany na dwie podsieci [eth1 192.168.0.0/24, eth2 192.168.1.0/24]. Do tej pory bramka VoIP była tylko w eth1, wszystko działało bez problemu, w ogniomurku nie musiałem wpisywać żadnych specjalnych rzeczy, obyło się nawet bez forwardu portów. Parę dni temu zaszła potrzeba wpięcia bramki również w podsieć eth2. I tutaj zaczęły się jaja - nie łączy się, w statusie podaje tylko komunikat "can't connect to login server". A wystarczy ją przenieść fizycznie do sieci eth1 i działa od kopa. Próbowałem chyba wszystkiego, nawet wypięcie pierwszej bramki nie pomogło [sądziłem, że iptables SIP conntrack głupieje przy dwóch lokalnych]. Zabawa z portami, czy próba innego dostawcy VoIP również nic nie dała. A aplikacja VoIP pod Windowsa, odpalona na komputerze wewnątrz eth2 działa jak trzeba; jak i wszystko inne, to pierwszy mój taki problem z NATem.

Potrzebuję jakiegoś pomysłu, naprowadzenia. Czego szukać? NAT dla obydwu sieci jest taki sam, ma różne reguły filtrowania i sfq, ale ostatecznie sprowadza się do:

```

IP10=... #zew. IP ISP

GW10=... #brama ISP

ip route add default via $GW10 dev eth10 src $IP10 proto static table 10

ip rule add iif eth1 table 10

ip rule add iif eth2 table 10

ip rule add from $IP10 lookup 10

ip rule add to $IP10 lookup 10

iptables -A FORWARD -s 192.168.0.0/24 -j ACCEPT

iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j SNAT --to ${IP10}

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to ${IP10}

```

----------

## gexcite

Błędnie skonfigurowane adresy IP w bramkach? Błąd w konfiguracji DHCP? To pierwsze co przychodzi na myśl.

----------

## manwe_

Nie, wszystkie podstawowe rzeczy można odrzucić, sprawdzałem je kilkukrotnie. Bramki mają tę samą konfigurację nie licząc danych konta u operatora VoIP i ewentualnie zmiany portu 5060 na 5061, -70 i -80 do testów tego rozwiązania. Windows, który został podpięty z programem VoIP wszedł na MAC bramki, więc dostał z DHCP jej ustawienia.

----------

## gexcite

A co się dzieje jak zamienisz miejscami obie bramki? Tą działającą i tą co nie działa? Pisałeś, że ta druga "ożywa", a co z pierwszą? Czy przeniesiona do drugiej podsieci "umiera"? Co pokazuje np iptraf odpalony na routerze? Obie odpowiadają na pingi, pomimo, że jedna z nich nie łączy się z operatorem?

----------

## manwe_

Pierwszej nie przenosiłem do drugiej sieci [i nie bardzo mam jak, jest używana]. Jasne, myślałem o tym że druga może być wadliwa, ale zarówno wpięta do pierwszej podsieci jak i do jeszcze innego łącza [bez NAT] zaskoczyła natychmiast. W samej sieci obydwie działają normalnie, konfiguruje je przez http, dostęp do jest zawsze. 

Mały log z tcpdump po zrestartowaniu bramki: http://pastebin.com/7jrFdcf0 [.52 to oczywiście druga bramka].

----------

## gexcite

Posłuchaj jeszcze na interfejsie zewnętrznym, bo z logów wynika że bramka wysyła, ale nie dostaje odpowiedzi. Coś po drodze się gubi.

----------

## manwe_

Zwrot był rzeczywiście pusty, zacząłem szukać i myśleć jeszcze raz, co może blokować ruch. Przecież pecet podpięty pod ten MAC latał jak trzeba. I wtedy sobie przypomniałem o jednym krótkim filtrze w całym ogniomurku, który zapobiega najprostszemu NATowaniu przez kolejne komputery:

```
iptables -A FORWARD -i eth2 -j CHECKTTL

iptables -A CHECKTTL -m ttl --ttl 31 -j RETURN

iptables -A CHECKTTL -m ttl --ttl 63 -j RETURN

iptables -A CHECKTTL -m ttl --ttl 127 -j RETURN

iptables -A CHECKTTL -j DROP
```

Pieprzona, jak się okazało, śle pakiety ttl=250 i cały czas nie mogła wyjść na zewnątrz. Alarm odwołany, prosty fix wystarczył:

```
iptables -A CHECKTTL -s 192.168.1.52 -m ttl --ttl 249 -j RETURN
```

Dzięki za próbę pomocy i sorry za zamieszanie  :Smile: 

----------

