(open)vpn + bridging: arp megy, ping mar nem igazan...

Sziasztok!

Ezalapjan probalnek megvalositani egy openvpn + ethernet bridginget ket fizikailag messze levo (A es B) LAN kozott.

Konkretabban:
- Az A LAN A1 gepen van egy br0=eth0+tap0 bridge, egy globalis (br0=1.2.3.4) es egy privat cimmel (br0:2=192.168.0.2)
- A B LAN B1-es gepen (egyelore) nincs bridge, csak az ottani tap0-nak van egy privat cime (192.168.0.1)
- Az A LAN egy A2-es gepe kap egy privat aliast (eth0:2=192.168.0.3)

Ezen beallitas mellett papiron az A2-es geprol is el lehet akkor erni a B1-eset a privat tartomanyon keresztul. A gyakorlatban viszont az IP nem megy (ICMP, TCP, ...), az ARP viszont megy. Szoval ha A2-rol pingetem a B1-et (192.168.0.1), akkor valasz nem jon, de az A2 ARP tablajaban (/usr/sbin/arp -n) szepen latszik hogy megtalalja a B1-es gepen levo tap0 interface hw-cimet.

Az egyes (fizikai ill. virtualis) interface-k kozott nincs hw-cim utkozes.

Barmi otlet mi lehet itten a gond? Tuzfal, ilyenek persze rendben vannak (A2-rol A1 pingik, A1-rol B1 is, B1-rol A1 is, A1-rol A2 is).

A

Hozzászólások

Kicsit nehezen bogozom ki az elejet,valoszinuleg a mai maraton vasarlas az oka;)
Ennek ellenere nekem ugy tunik, mintha az openvpn tartomanya egybe esne a lannal (illetve a ket lan is egy tartomanyban van?)
A legegyszerubb lepes: mindharomnak kulon tartomanyt (lan1+lan2+openvpn), majd a ket tartomany oda<->vissza route-olasa

// Happy debugging, suckers
#define true (rand() > 10)

Ennek ellenere nekem ugy tunik, mintha az openvpn tartomanya egybe esne a lannal
Igen, az egy hatarozottan furcsa aspektusa a dolognak, hogy az A1-es gep tap0 VPN-interface-e az eth0 fizikai interface-n keresztul megy ki a nagybetus internetre (hogy aztan ~100km-rel arrebb eljusson a B1-es gepen levo" tap0 interface-ig). Mindezt ugy, hogy a ket interface egy bridge + egy bridge aliaskent latszik.

De mondom, ez a resze mukodik mert az A LAN-on levo" masik (azaz az A2-es) gep eljut ezen a br0=eth0+tap0 katyvaszon, kikavarodik a csomag a B1-es gepre, az ARP feloldas megtortenik (kulonben az A2-es gep honnan tudna hogy a B1-es tap0 VPN interface-nek mi a hw-cime?). Es mindez minket iranyban (azaz a B1-es gep ARP-tablajaban is latszik az A2-es gep hw-cime, ami ott az eth0 fizikai interface hw-cimevel egyezik meg).

Kozben elolvastam a cimet is, bridging;) Gyakorlatilag mennie kene a dolognak, bar nem tudom mit csinaltal pontosan:
Ezt talaltam igy hirtelen: https://openvpn.net/index.php/open-source/documentation/miscellaneous/7…

Egyebkent meg tcpdump -al ellenorizd, hogy merre tunnek el a csomagjaid, ez elso korben egy nagyon jo tampont lenne

// Happy debugging, suckers
#define true (rand() > 10)

Ehem, igen. A tcpdumpot neztem menetkozben. Ugy nez ki megvan az ok. Az iptables-ben kell engedelyezni a forwardot (-A FORWARD -j ACCEPT), viszont a /proc/sys/net/ipv4/ip_forward ertekenek nincs hatasa a mukodesre. Mostmarcsak az a kerdes hogy a layer2 es a layer3 miert keveredik. A bridge elvileg egy layer2-es valami kellene hogy legyen.

Az /proc/sys/net/ipv4/ip_forward tartalmának nincs köze a bridge funkcióhoz. Ez arról szól, hogy ha bejött egy csomag az egyik interface-n és nem ez a gép a cél, akkor az adott _IPv4_ csomagot tovább küldje-e a masina, vagy ne, azaz működjön-e routerként vagy ne. Egy bridge nem router, egy bridge ha egy csomag beesik az egyik bridge interface-n és a cél a másik bridge interface tartományában van, akkor az a csomag akkor is továbbítódik, ha egyébként a router funkció le van tiltva a gépen. Na most ez a dolog egyik fele - most jön viszont durvább rész: /proc/sys/net/bridge/bridge-nf-call-iptables
Ezt a nagyszerű újdonságot már nem is tudom, mikor vezették be, de a korábban működő, jól összelőtt bridge-m teljesen fejre állt tőle, ráadásul volt, ami ment, volt ami nem. Nos, ez a durva beállítás azt mondja meg, hogy ha a bridge egyik interface-én beesik egy _IPv4_ csomag és kimenne a bridge másik interface-én, akkor a továbbítás előtt feladásra kerüljön-e a csomag a kernel tűzfal szűrő részlegének, vagy ne? Default opció: 1, tehát igen. Amíg nincs tűzfal, addig persze ez nem gond - de onnan kezdve ha a tűzfal szabály felépítésekor nem foglalkozunk az bridge-n belüli forgalommal, akkor durván kiszűrheti annak a forgalmát.
echo 0 > /proc/sys/net/ipv4/ip_forward - és innen kezdve a tűzfal a bridge-n belüli forgalmat nem szűri.
Ha IPv6-ban is érintett vagy, akkor az külön opció.
Azt meg értem, hogy ez egy nagyon jó feature, hogy a tűzfal a bridge-member interface-k között is tudjon szűrni - na de hogy élből be van kapcsolva, az azért ... hát izé!

Zsenialis, koszonom! Igen, ez az

echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

szepen megoldotta ugyis hogy a default forward policy az a drop.

Marcsak akkor az az (elmeleti) kerdes hogy az A1 gep tcpdump-jaban miert latszik az atmeno forgalom. Mondanam, hogy egy -i eth0 vagy egy -i tap0 opcioval ha latszik az nem baj, de egy -i br0 (vagy br0:2) mellett...?

A tcpdump promisc. módba kapcsolja a vizsgált interface-t. A virtuálisat is. Innen kezdve lát minden olyan forgalmat, ami az adott interface-ig eljut - akkor is, ha egyébként nem nem az a cél. Ha a br0 kerül promisc. módba, akkor azon - ebből adódóan - minden olyan forgalom megjelenik, amely valamely bridge-member interface-n megjelenik.

lát minden olyan forgalmat, ami az adott interface-ig eljut
Igen, ez az amit nem teljesen ertek akkor: a br0-ig nem lenne szabad eljutnia a forgalomnak. Ez olyan mintha venne'k egy 3 portos switchet, az 1. es a 2. port kozott megy a forgalom, de a 3ik portjan logo eth kontroller nem latja azt (a sikeres ARP feloldas utan, persze). Nyilvan debug megy egyeb hasonlo okok miatt nem baj ha van mod erre, de megintcsak az a kerdes hogy miert kavarnak bele a retegekbe es miert ez az alapertelmezett mukodes (i.e. ugyanugy mint a fentebbi iptables-forward eseteben).

No mindegy, mindig tanul az ember valamit. Hogy hogysmint es mikor erdemes esznel lenni ;)

A régi koax alapú ethernet esetén egy időben csak egy kártya adhatott - viszont az összes, az adott koaxon lógó kártyáig eljutott az adat. Ekkor a kártya eldöntötte, hogy ő-e a címzett és ha nem, akkor eldobta a keretet. Normális esetben. Ha viszont a kártya promisc. módba lett állítva, akkor a keretet mindenképpen feladja az oprendszernek.
Jöttek a cat5 alapú kanócozások és megjelentek a switch-ek - amelyek a keretet már legalább annyiban értelmezték, hogy hova kell kitolni a keretet (a nagyon buta mindenhova kitolja), cserébe a sniffelés problémássá vált. Ekkor jött az, hogy lehessen debug port - a debug portra a switch az összes forgalmat kitolja.
Bridge esetén el lehet dönteni, hogy a br0 csak egy cat5 végpont vagy egy koax végpont? Az egyik esetben tényleg csak az oda címzett forgalom érkezik meg az interface-re, a másik esetben meg az összes. Amit érdemes végig gondolni, hogy nekünk melyik a jobb? Amíg a br0 nincs promisc. módban, addig egy eth0-->tap0 forgalom nem esik ki rajta és a tap0-->eth0 szitúgy nem. Amikor viszont debugolunk, akkor ez az info jól jöhet és ehhez a br0 egyébként promisc. módba kerül - tehát van jelzés, hogy akarom látni a br0-on az eth0-->tap0 forgalmat. Szóval szerintem ez jó így - de persze ízlések és pofonok... :-)