par dotazu na VPN

[Dan Lukes]

Miroslav Lachman wrote:
> tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
>          inet 10.8.0.226 --> 10.8.0.225 netmask 0xffffffff
>          Opened by PID 827

> Klienti v LAN maji adresy v rozsahu 10.1.1.0/24 a meli by byt schopni se 
> dostat napriklad na 10.8.0.1

	Takze si pustis tcpdump na interface tun0, zkusis komunikaci, ktera 
nejde a zanalyzujes co ti ukazuje tcpdump. Predpokladam, ze uvidis 
pakety odchazejici, ale neuvidis vracet se odpovedi. Takze primo z 
routeru to jde, ale z druhe strany neprichazeji odpovedi - pak to musi 
resit spravce routeru na opacne strane, ale nejspis je to problem s 
routovaci tabulkou nebo firewallem tam.

	Pokud odpovedi z druhe strany prichazet budou, budou videt na routeru 
ale na klienta nedorazi, pak je problem na tve strane.

	A dal bych to resil az kouknes na ten tcpdump a budeme vedet, ktera z 
moznosti to je.

> pptp VPN 
...
> ktery jsem dostal k dispozici od protejsi strany, je login, heslo a 
> verejna IP toho routeru, ktery zajistuje VPN.

> [L1] LCP: state change Ack-Sent --> Opened
> [L1] LCP: auth: peer wants CHAP, I want nothing
> [L1] LCP: LayerUp
> [L1] CHAP: rec'd CHALLENGE #1 len: 29
> [L1]   Name: "MikroTik"
> [L1] CHAP: Using authname "MyLogin"
> [L1] CHAP: sending RESPONSE #1 len: 60
> [L1] CHAP: rec'd FAILURE #1 len: 79
> [L1]   MESG: E=691 R=0 C=8005258D6F3521B9817FF1FEF230D334 V=3 M=bad 
> username or password

	Tohle je, bohuzel, pomerne jednoznacne - obe strany se jasne dohodly na 
metode autentizace (CHAP), handshaking radne probehl (<-challenge; 
->response; <-result) a vysledek rika, ze protistrana neni spokojena s 
heslem. To nema jine rozumne pravdepodobne vysvetleni nez to, ze 
autentizacni par neni platny.

	Spatne opsane heslo na tve nebo jejich(!) strane je s ohromnou prevahou 
nejpravdepodobnejsi vysvetleni.

							Dan