znaczacy > comp.os.* > comp.os.linux.sieci

Sebastian Biały (27.10.2010, 21:26)
Witam.

Mam problem naglacy. Nie dziala mi VPN na Win. Konkretnie mam dwie sieci
VPN z ktrymi moge sie polaczyc. Jedna nie dziala, druga dziala. Obie
generuja polaczenia na port 1723.

Jesli polacze sie z siecia dzialajaca a nastepnie polacze sie przez nia
z druga - zadziala. Jesli wprost z druga - nie.

Po drodze mam Linuxowy router robiacy w zasadzie tylko SNAT. Czytajac
fora *wydaje* mi sie, ze samo SNAT moze nie zadzialac poprawnie.
Znalazlem informacje ze nalezy dorzucic modul nf_conntrack_pptp.
Dorzucilem, ale efekty dalej takie same.

Zanim zaczne sniffowac ruch i szukac przyczyny na powaznie:

Czy uruchmienie tunelu VPN@1723 (GRE?) wymaga jakiejs ingerencji w
router oparty o iptables SNAT ? Jakis dodatkowy helper? Jakis dodatkowy
modul do jadra? klient jest windowsowy, router to ubuntu 2.6.28-11-server.
MaRc (28.10.2010, 08:45)
> Czy uruchmienie tunelu VPN@1723 (GRE?) wymaga jakiejs ingerencji w
> router oparty o iptables SNAT ? Jakis dodatkowy helper? Jakis dodatkowy


czy pozwalasz na FORWARD GRE? iptables .... -p gre ...

pokaz
iptables -nL
iptables -t nat -nL
Sebastian Bialy (29.10.2010, 13:23)
On 2010-10-28 08:45, MaRc wrote:
> iptables -nL


Chain INPUT (policy ACCEPT)
target prot opt source destination
RESTRICT_INPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain RESTRICT_INPUT (1 references)
target prot opt source destination
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:3306
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:445
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:139
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:53
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53

-----------------------------

> iptables -t nat -nL


Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 172.16.0.0/12 0.0.0.0/0 to:xx.xx.xx.xx

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

-----------------------------

-p gre nie uzywam bo do tej pory z innym VPNem dzialalo. Powinienem?
Wydawalo mi sie ze SNAT jest wystarczajaco przezroczysty.

Teraz ciekawostka:

Odpalam na routerze ettercap. Otwieram pierwsze (dzialajace polaczenie).
Pojawia sie laczonosc ja->server1 i zwrotna server1->ja. ettercap pisze
"tunnel established ...".

Odpalam drugie polaczenie. Pojawia sie tak samo ja->server2,
server2->ja. *ALE* ettercap nie pisze nic o tunnel established.

Obydwa polaczenia na oko sa identyczne - bardzo podobne rozmiary, bardzo
podobna zwartosc, stringu tu i tu w tych samych miejscach. Tylko w
drugim wypadku brak wykrycia tunelu przez ettercap.

Zanim zaczne zrzucac pakiety i recznie analizowac wolalbym znalezc
rozwiazanie w iptables o ile tam lezy problem.
MaRc (29.10.2010, 13:37)
> Odpalam drugie polaczenie. Pojawia sie tak samo ja->server2,
> server2->ja. *ALE* ettercap nie pisze nic o tunnel established.


jaka to ciekawostka? tunel zestawia sie "w dwie strony". oba servery vpn
pukaja do ciebie na ten sam port a skoro juz jedno masz ustanowione to
rzecz jasna, ze drugiego polaczenia jako klient na tym samym porcie nie
zestawisz.

> Obydwa polaczenia na oko sa identyczne


no nie dziwne

> W drugim wypadku brak wykrycia tunelu przez ettercap.


bo juz jedno masz zestawione.

oglnie FORWARD masz na ACCEPT dlatego gre ci sie zestawia.
Sebastian Bialy (29.10.2010, 13:45)
On 2010-10-29 13:37, MaRc wrote:
> jaka to ciekawostka? tunel zestawia sie "w dwie strony". oba servery vpn
> pukaja do ciebie na ten sam port a skoro juz jedno masz ustanowione to
> rzecz jasna, ze drugiego polaczenia jako klient na tym samym porcie nie
> zestawisz.


Operacje byly przeprowadzane *osobno* zeby wykluczyc ta ewentualnosc.

> bo juz jedno masz zestawione.


Nie mam.

> oglnie FORWARD masz na ACCEPT dlatego gre ci sie zestawia.


Ale tylko jeden. Drugi nie chce choc ettercap pokazuje praktycznie
indetyczne mechanizmy.

Zeby nie bylo: reszcie swiata VPN2 dziala.
MaRc (29.10.2010, 13:56)
>> bo juz jedno masz zestawione.
> Nie mam.


na pewno.
sprawdz polaczenia na routerze
netstat -nta | grep ESTABLISHED
czy czasem ci jeszcze nie wisi??

> Zeby nie bylo: reszcie swiata VPN2 dziala.


do dobrze :)
Sebastian Bialy (29.10.2010, 14:11)
On 2010-10-29 13:56, MaRc wrote:
>>> bo juz jedno masz zestawione.

>> Nie mam.

> na pewno.


Na pewno. Zeby miec 100% pewnosci wykonalem restart serwera, odczekalem
godzine gdyby-jak-by-co cos u dostawcy zostalo. Nastepnego dnia
ponowilem probe tylko z VPN2. IMHO to wszystko bez sensu, ale lapalem
sie wszystkich ewentualnosci.

>> Zeby nie bylo: reszcie swiata VPN2 dziala.

> do dobrze :)


Wiec cos mam zle.

*Byc* moze ze nie dziala mi np. dlatego ze ten drugi gre jest nowszy i
moje jajko nie widzi go jako tunelu czy cos. W weekend mam w planie
upgrade calosci routera wiec ta mozliwosc potwierdze, choc nie licze...

Czy GRE wykonuje zwrotne polaczenie osobnym kanalem tcp na adres
klienta? Z obserwacji ettercap wynika ze po moim zapukaniu do serwera
serwer prbuje polaczyc sie zwrotnie ze mna tworzac drugie rwnolegle
polaczenie. To wymaga wsparcia NAT i zastanawiam sie czy w jajku nie
brakuje jakiegos helpera do SNAT. Z drugiej strony to rwnolegle
polaczenie dalo rade przepompowac do mnie jakies dane wiec *chyba* ten
helper dziala jakos, moze czegos nie podmienil w protokole VPN2 w locie.
MaRc (29.10.2010, 14:24)
sprbuj zrobic DNAT na hosta z ktrego prbujesz nawiazac polaczenie z VPN2.
Sebastian Bialy (29.10.2010, 15:38)
On 2010-10-29 14:24, MaRc wrote:
> sprbuj zrobic DNAT na hosta z ktrego prbujesz nawiazac polaczenie z
> VPN2.


To ostatecznosc, zostanie przetestowana dzisiaj wieczorem :)

Gdzie moge znalesc opis protokolu GRE (bajt po bajcie) ? Na wiki jest
troche, ale oglnie interesowala by mnie np. analiza w wiresharku co
jest co.
Podobne wtki