Klienci OpenVPN nie widzą się nawzajem: podsieć czy net30?
Klienci docierają do serwera, ale nie do siebie. Rozdziel usterkę jednym pingiem, a potem wybierz topologię podsieci, client-to-client lub segment TAP w trybie mostu.
Dwie niepowiązane usterki dają tę samą skargę. W pierwszej jeden klient nie dociera do drugiego nawet po adresie tunelu, bo adresy nie są w jednej podsieci albo serwer nie przekazuje ruchu między partnerami. W drugiej ping działa, a lista urządzeń w aplikacji pozostaje pusta, bo wykrywanie opiera się na transmisji rozgłoszeniowej, której tunel warstwy 3 nie przeniesie. Jeden ping je rozdziela, a naprawa każdej z nich zupełnie nie przypomina naprawy drugiej.
Jeden ping dzieli problem na dwoje
Z jednego klienta pinguj adres tunelu drugiego klienta, nie jego nazwę i nie jego adres LAN. Jeśli to się nie uda, problemem jest przekazywanie lub adresowanie, a wykrywanie nie ma znaczenia, dopóki tego nie naprawisz. Jeśli się uda, przekazywanie już działa, a brakującym elementem jest transmisja rozgłoszeniowa lub rozwiązywanie nazw.
ip addr show tun0Najpierw przeczytaj interfejs klienta, bo maska sieci nazywa topologię. /24 lub inna maska podsieci oznacza wspólną pulę; /30 z adresem partnera oznacza starszy układ punkt-punkt, w którym każdy klient ma dokładnie jednego sąsiada, serwer.
net30 kontra podsieć, czytane od strony klienta
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
W net30 serwer przydziela mały blok na klienta, więc trasa do adresu tunelu innego klienta nie istnieje, chyba że serwer ją przekazuje. W podsieci cała pula to jedna sieć, każdy klient może zaadresować każdego innego, a serwer przekazuje między nimi. Dlatego jedna konfiguracja serwera może wyglądać zdrowo, a pingi między partnerami zawodzą: nic nie jest zepsute, klienci po prostu nie są w jednej sieci. Klient widzi działające łącze i adres partnera, który nie odpowiada, co czyta się jak zapora, ale jest układem adresowania.
Zmiana dyrektywy to edycja po stronie serwera plus restart, i dotyczy następnego połączenia, a nie sesji już otwartych. Połącz klientów ponownie, zanim ocenisz zmianę. Jeśli urządzenie regeneruje konfigurację z interfejsu webowego, zapisz dyrektywę, plik i datę, a edycję wykonaj przez interfejs, gdy istnieje, bo ponowne zbudowanie nadpisze ręczną edycję przy następnym zapisie.
client-to-client to osobna brama
Nawet w jednej podsieci serwer odrzuca pakiety, które przychodzą od jednego klienta i są adresowane do innego, chyba że ustawiono client-to-client. To słowo kluczowe czyni serwer przekazującym ruch między partnerami, a nie punktem końcowym, który tylko go przyjmuje. To drugi warunek, który ludzie pomijają po naprawie topologii.
Nie obejmuje to transmisji rozgłoszeniowej. Ustawienie przekazuje unicast między klientami; nie czyni tunelu wspólnym segmentem i żadna jego ilość nie dostarczy zapytania wykrywania multicast do każdego partnera.
TUN kontra TAP, i co każde może przenieść
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
Mostkowanie urządzenia tap do LAN umieszcza zdalnych klientów w domenie rozgłoszeniowej biura, co całkowicie rozwiązuje wykrywanie. Ceną są platformy, które nie implementują TAP, most, który musi istnieć na serwerze, oraz domena awarii, w której burza rozgłoszeniowa na kablu biurowym dociera do każdego zdalnego laptopa.
Dla dwóch lub trzech stacji roboczych potrzebujących rozwiązywania nazw wpis w hosts lub adres unicast jest znacznie tańszy niż most. Po TAP sięgaj wtedy, gdy protokół, którego nie możesz zastąpić, zależy od wykrywania w warstwie 2, i nie wcześniej.
Klienci w tej samej podsieci bez mostu
Przydzielenie adresu z zakresu LAN nie stawia klienta na kablu. Serwer routuje między tunelem a Ethernetem, więc ARP dla tego adresu zatrzymuje się na interfejsie serwera, a reszta LAN nigdy nie dowie się, gdzie on mieszka.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP zamyka tę lukę, bo serwer odpowiada w imieniu klienta. Dla zakresu parpd zarządza wpisami, gdy klienci przychodzą i odchodzą, a sysctl net.ipv4.conf.eth0.proxy_arp=1 odpowiada za wszystko kierowane gdzie indziej, co jest dość szerokie, by na zajętym segmencie stworzyć własne niespodzianki.
Niezależnie od wybranej drogi usuń NAT między tunelem a kablem. Reguła MASQUERADE ukrywa dokładnie to pytanie o adresowanie, na które próbujesz odpowiedzieć. Zostawia też następnej osobie topologię, o której nie potrafi ona rozumować od strony klienta.
Zanim cokolwiek zmienisz, przechwyć jedną próbę na serwerze za pomocą tcpdump -ni tun0 i potwierdź, czy pakiet partnera w ogóle dociera. Dociera i jest odrzucany — to wskazuje na client-to-client; nigdy nie dociera — wskazuje na topologię lub routing. Podręcznik OpenVPN 2.6 dokumentuje oba słowa kluczowe i domyślną topologię, co warto porównać z własną wersją przed skopiowaniem wiersza z postu na forum.
- Interfejs tun pokazuje maskę puli, a nie parę partnerów /30.
- Bezpośredni ping do drugiego adresu tunelu udaje się, zanim sprawdzisz wykrywanie.
- Konfiguracja serwera zawiera
client-to-clientzawsze, gdy partnerzy muszą wymieniać pakiety. - Nazwij testowany protokół wykrywania, zamiast mówić, że aplikacja zawodzi.
- Używaj TAP tylko wtedy, gdy obsługuje go każda platforma klienta w grupie.
- Trzymaj NAT poza ścieżką między tunelem a LAN, gdy liczy się osiągalność w tej samej podsieci.