openvpn a preroutovanie viacerych subnetov
narazil som na zaujimavy problem pri openvpn. na klientovi som pushol siet 10.100.0.0/16 pretoze na servri mam viacero subnetov z tohoto rozsahu. cely system sa vsak sprava haluzne. napr rozsah na eth1 10.100.0.0/25 pingem cely. rozsahy na eth0,2,3,4,5 vsak pingnem len sietovky a sietovku na druhej strane cize dalsi router. nepingnem ziadne pc za dalsimi routrami ale ani ziadne radio medzi nimi.
priklad eth4 10.100.251.1/24...pingnem 1 a 2 ale uz nie 13,14 (co su ip radioveho spoja). na eth2 pingnem 10.100.0.129 co je ip eth2 ale uznie 10.100.0.190 co je kablom pripojene ap. nepingnem samozrejme ani radiovych klientov pripojenych na toto ap z toho isteho ip rozsahu.
pouzivam tun s tap som sa zatial hral len zbezne.
p.s. problem robi server lebo:
traceroute to 10.100.0.129 (10.100.0.129), 30 hops max, 38 byte packets
1 10.100.0.129 (10.100.0.129) 22.783 ms 21.647 ms 17.454 ms
ale
traceroute to 10.100.0.190 (10.100.0.190), 30 hops max, 38 byte packets
1 192.168.1.1 (192.168.1.1) 24.704 ms 21.116 ms 21.575 ms
2 *
klasická poučka praví, že 90% problémů se sítí je problém routingu a dalších 7% je skrytý problém routingu
můžeš načrtnout topologii a pastnout routovací tabulky z routeru, VPN klienta a nějakého stroje z funkční podsítě a nefunkční podsítě?
pastnut sem celu routovaciu tabulku zaberiem pol stranky;o). uvediem priklady.
10.100.0.0/25 dev eth1 proto kernel scope link src 10.100.0.1
10.100.0.128/26 dev eth2 proto kernel scope link src 10.100.0.129
10.100.250.0/24 via 10.100.0.142 dev eth2
10.100.248.0/24 via 10.100.0.144 dev eth2
10.100.249.0/24 via 10.100.0.143 dev eth2
takze toto je napr eth1 a eth2. eth1 ide vsetko. od 10.100.0.1 cez pc na tejto lanke...ktorekolvek.
problem nastane u eth2. pingnem este 10.100.0.129 co je eth2 samotna ale uz nic co je za nou...priamo za nou je kablom jedno ap na ktore sa pripaja cca 10 klientov a dalsie 3 subnety ako vidiet z vypisu. nepingnem ani to ap
dalsi priklad je eth3 kde je na druhej strane linux router
10.100.0.192/26 dev eth3 proto kernel scope link src 10.100.0.193
10.100.2.0/24 via 10.100.0.196 dev eth3
pingnem 10.100.0.193 co je eth3194 ani 195 uz nie (to su radia) ale 196 co je linux na opacnej strane uz hej...dalej za tym linuxom uz zase nic nepingnem (ani jeho ine eth rozhrania).
matie ma hlavne ta eth1...preco ta ide cela a preco linuxy pingam ale radia medzi nimi zu nie
1) mas v tom hrozny bordel
2) problem bude v tom, ze mas do routru zapojene prekryvajici se subnety. Ono kdyz se pohybujes v ramci segmentu, tak to podle masky vyhodnocuje, ktere IP jsou do segmentu a se kterymi pozadavky se obracet na gateway... AAAALe jakmile dojde do serveru pozadavek na spojeni z pocitace napriklad 10.100.0.20/24 na pocitac z jineho segmentu, napriklad rekneme 10.100.1.130 tak ten router uz nebere v potaz masku a najednou stoji pred problemem, kam to odroutovat. Jestli do 10.100.0.0/16 nebo 10.100.1.128/25 nebo 10.100.1.0/24.. zadana IP adresa totiz zjevne patri do vsech z nich. To je konflikt site.
toto ma samozrejme napadlo ze musim vlastne kazdy subnet rozpisat do konfigu vpn servera ale...ked som skusil a rozpisal 10.100.0.0/25 a 10.100.0.128/26 tak druhy subnet mi robil to iste ako teraz...cize samotnt eth2 som pingol ale dalej uz nic. pre upresnenie vo vpn servri som mal pushnute len tieto 2 routy nic viac cize nemalo sa tam co bit.
a este v principe routovania odovzda packet router najblizsiemu routru a ten ho posuva dalej predsa cize ak pride packet z klienta na server tak dalej je to uz zalezitost servera a ten sa predsa riadi podla svojej routovacej tabulky kde su vsetky subnety jasne definovane...aj preto si myslim ze nemusim definovat tieto subnety znovu v konfigu vpn servra.
takhle můžeš pushovat routing table na VPN klienty (s tím, že default router bude iface VPN koncentrátoru), ale pokud nepingáš ani ze samotného routeru (pokud jsem to dobře pochopil), tak chyba je opravdu v routovací tabulce na samotném hostiteli.
a ještě se zeptám: obráceně (Z klientů do VPN hostů) to jde? A ještě poddotaz: jsi si jistý, že klienti např. za eth2 mají dobře nastavenou masku? Dále, že tvůj router má opravdu route záznam pro VPN subnet?
obratene to nejde. cize zhrnme si to. klient v ba sa napoji na server v inom meste...dokaze popingat jeho eth rozhrania a dokonca aj spojene eth rozhrania pripojenych routerov. nevie pingat vsak napr radia medzi nimi z toho isteho subnetu. na rozhrani eth1 sa dokonca dostane aj za sietovku eth1 aj ked na eth1 uz dalsi linux router nie...je tam lan z pc. tieto pc klient vsetky vidi a pinga. tieto pc vsak klienta nevidia a a pri pokus pingnut ho ide ich packet mimo tun rozhrania cez klasicku route (toto vidim na problem routovacej tabulky v oknach...skusim pridat patricnu routu a myslim ze to pojde aj spatne).
otazka vsak znie preco moze klient mimo siete pingat lan pc na eth1 a nemoze pingat uz radia na eth2? v principe su to take iste rozhrania a nemal by medzi nim robit nejake rozdiely.
server ma okrem ineho takuto routu:
192.168.1.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 192.168.1.2 255.255.255.0 UG 0 0 0 tun0
klient ma takto nieco
192.168.1.109 * 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 192.168.1.109 255.255.255.0 UG 0 0 0 tun0
10.100.0.0 192.168.1.109 255.255.0.0 UG 0 0 0 tun0
Myslim, ze bez postnuti cele routovaci tabuly a konfigurece sitovych rozhrani to nepujde zanalyzovat. Jestli mas zajem, muzes mi je posalat na jr <tecka> ewing <zavinac > seznam <tecka> cz. Ja se na ne podivam.