Hello,
két Debian Sarge, openvpn2.0 csomagbol, interneten "összekötve". Nagyjábol így néz ki a topológia:
192.168.75.0/24 - eth0: 192.168.75.1 - tun1: 10.4.0.1 ---
internet ---
tun1: 10.4.0.2 - eth0: 192.168.76.1 - 192.168.76.0/24A routing tablak:
192.168.75.1:
10.4.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
192.168.76.0 0.0.0.0 255.255.255.0 U 0 0 0 tun1
192.168.75.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
1.2.3.0 0.0.0.0 255.255.252.0 U 0 0 0 eth1
0.0.0.0 1.2.3.4 0.0.0.0 UG 0 0 0 eth1192.168.76.1:
10.4.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
5.6.7.0 0.0.0.0 255.255.255.224 U 0 0 0 eth2
192.168.76.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.75.0 10.4.0.1 255.255.255.0 UG 0 0 0 tun1
0.0.0.0 5.6.7.8 0.0.0.0 UG 0 0 0 eth2a két szerver látja egymást, a két szervert a túloldali hálóból el lehet érni, de csak a tun1 interface-eken keresztül. A két háló egyáltalán nem látja "egymást" a másik hálózat címén.
A beállítások műkodtek tegnapig, mikoris volt egy restart, és azóta produkálja ezt. Előtte elérték a gépek egymást. Konfig nem változott semmit. Iptables van, de ha leállítom, akkor is ugyanez az eredmény (default ACCEPT)
Adalék: ha a 192.168.75.29-es kliensről elindítok egy pinget, mondjuk a 192.168.76.200-ra, akkor a 192.168.76.1-es szerveren a tcpdump a tun1-es interface-en _csak_ a bejövő csomagokat mutatja, az eth0-as interface-en viszont a válaszok is megjelennek - de ezek merre mennek? Végigprobaltam az összes interface-t, de a tcpdump sehol nem mutatja a válasz csomagokat.
A fenti routing táblákban feltünt a különbség, de még nem jöttem rá, hogy a 75.1-es gépen a 76.0/24-es hálóhoz miért nincs beállítva a "use gateway" flag. Próbáltam törölni a route-ot, és kézzel felvenni:
route add -net 192.168.76.0 netmask 255.255.255.0 gw 10.4.0.2 dev tun1de semmi hatása nem volt.
Mi lehet a gond?
Remélem érthetően tudtam fogalmazni igy hajnali kettő körül :)
Köszönöm:
a
- 2092 megtekintés
Hozzászólások
/proc/sys/net/ipv4/ip_forward mit tartalmaz?
- A hozzászóláshoz be kell jelentkezni
1-et.
a két szerver látja egymást, a két szervert a túloldali hálóból el lehet érni, de csak a tun1 interface-eken keresztül. A két háló egyáltalán nem látja "egymást" a másik hálózat címén.
Vagyis ha pl. a 75.0-ból a 10.4.0.2-t pingetem a 75.1-en keresztül, vagy visszafelé, akkor az még működik.
és ehhez is kell az ip_forward.
De "sajnos" az ilyeneken már túl vagyok (ill. azt a tényt nem írtam, de szvsz nem változtat a lényegen, hogy a net megosztás amúgy működik)
Köszönöm:
a.
- A hozzászóláshoz be kell jelentkezni
Ha jól tudom, az OpenVPN egy belső routing táblát is karbantart,
és ebben nem szerepel valószínűleg a 76.0-s oldalon a 75.0-hoz
tartozó route (esetleg vice versa). Bár a visszajövő csomagoknak
a tun1-en is meg kellene jelenniük ezesetben, utána "kellene"
eltünniük.
Sokat segítene, ha a konfigok releváns részét is közzétennéd.
- A hozzászóláshoz be kell jelentkezni
de igen, szerepel, a konfigban is, amit lent megtalálsz, de az induló hozzászolásban is ott van a routing tábla. És egyébként a szerver->hálózat irány megy, de akkor a tun1 IF IP címével.
Íme az openvpn.conf:
remote 1.2.3.4
ifconfig 10.4.0.1 10.4.0.2
dev tun1
verb 2
mode p2p
cipher AES-256-CBC
secret /etc/openvpn/secret.txt
daemon
log-append /var/log/openvpn.log
route-up "/sbin/route add -net 192.168.76.0 netmask 255.255.255.0 gw 10.4.0.2 dev tun1"
keepalive 30 120
A két konfig ugyanaz, értelemszerűen a címek fordítva vannak felvéve.
üdv:
a.
- A hozzászóláshoz be kell jelentkezni
ebbol nem tudom megmondani melyik a szerver (192.168.75.1-t alapul veve), gondolom ez be van allitva a szerver konfigjaban:
push "route 192.168.75.0 255.255.255.0"
route 192.168.76.0 255.255.255.0
- A hozzászóláshoz be kell jelentkezni
mármint miből nem tudod megmondani? Az indító hozzászólásban van egy ascii rajz, abban elég egyértelmű: mindkét oldalon a .1 a szerver/gw.
Igen, az openvpn.conf-ban van ezzel analóg sor - ha egyre gondolunk, lásd az előző hozzászolónak adott választ.
Üdv:
a.
- A hozzászóláshoz be kell jelentkezni
"mármint miből nem tudod megmondani? Az indító hozzászólásban van egy ascii rajz, abban elég egyértelmű: mindkét oldalon a .1 a szerver/gw."
openvpn-nel van egy szerver oda csatlakoznak be a kliensek. a fenti rajzbol nem derul ki hogy melyik az openvpn szerver es melyik az openvpn kliens, barmelyik lehet.
ha az openvpn szerver tartalmazza az elobbi 2 sort akkor szerintem jol kell mukodnie.
gondolom azota volt mar ujrainditas is.
szerk.: na elolvastam a konfigodat, latom p2p modot hasznalsz. felejtsd el amit fent irtam.
viszont ha szerinted is mukodni kellene az openvpn-nek, akkor en mashol keresnem a hibat.
masik hogy feltetlenul sarge-nak kell rajta lennie? az etch-ben ujabb openvpn van talan segithet most nem olvastam changelogot.
- A hozzászóláshoz be kell jelentkezni
nos, ha láttad a konfigot (és egyebet nem írtál), akkor valszeg' szerinted is jó :)
Viszont ez így - a tulaj elmondása szerint - ment (én csináltam, kb egy éve), valszeg' tényleg ment, másképp nem adtam volna át, de a restart után nem akar elindulni.
Etch nem nagyon lehet, tulképp' egy akármilyen upgrade elég veszélyes, mivel az egyik gép (.76.1) egy vidéki kisváros kertesházának a padlásán van, és ha bármi probléma van, létrát kell vinni, amin a helyi technikus felviszi a monitort és a klaviatúrát :)
Egyéb ötlet?
köszönöm:
a.
- A hozzászóláshoz be kell jelentkezni
Hella,
okulásként, hátha valami még belefut hasonlóba.
Az openvpn előtt probálkoztam az OpenSwan-el is, de valamiért nem tesztett, és maradtam az OpenVpn-nél. Azonban az initscript linkje bent maradt az rcS.d-ben az egyik oldalon, és ez elég volt ahhoz, hogy a routing-ot megvezesse.
Kösz mindenkinek a segítő szándékot,
a.
- A hozzászóláshoz be kell jelentkezni