OpenVPN-klientar ser ikkje kvarandre: subnet eller net30?

To uavhengige feil gjev den same klaga. I den fyrste når ein klient ikkje ein annan sjølv via tunneladressa, fordi adressene ikkje er i same subnet eller tenaren ikkje videresender trafikk mellom partar. I den andre verkar ping, men eininglista i appen blir ståande tom, fordi oppdaginga byggjer på broadcast som ein tunnel på lag 3 ikkje kan bera. Éin ping skil dei, og rettinga for kvar av dei liknar slett ikkje rettinga for den andre.

Éin ping deler problemet i to

Frå éin klient, ping tunneladressa til den andre klienten, ikkje namnet og ikkje LAN-adressa. Viss det feilar, er problemet videresending eller adressering, og oppdaging er irrelevant til det er retta. Viss det lykkast, verkar videresendinga allereie, og det som manglar er broadcast eller namneoppslag.

ip addr show tun0

Les grensesnittet til klienten fyrst av alt, fordi nettverksmaska namngjev topologien. Ei /24 eller ei anna subnetmaske tyder ein delt pool; ei /30 med ei partadresse tyder det eldre punkt-til-punkt-oppsettet, der kvar klient har nøyaktig éin nabo, tenaren.

net30 kontra subnet, lese frå klientsida

Med net30 deler tenaren ut ein liten blokk per klient, så det finst ingen rute til tunneladressa til ein annan klient med mindre tenaren videresender henne. Med subnet er heile poolen eitt nett, kvar klient kan adressere kvarandre, og tenaren videresender mellom dei. Difor kan éin tenarkonfigurasjon sjå sunn ut medan ping mellom partar feilar: ingenting er øydelagt, klientane er rett og slett ikkje i eitt nett. Klienten ser ei fungerande lenkje og ei partadresse som ikkje svarar, noko som lesest som ein brannmur, men er eit adresseringsopplegg.

Å byta direktivet er ei redigering på tenarsida pluss ein omstart, og det gjeld for neste tilkopling, ikkje for økter som allereie er oppe. Kople klientane til på nytt før du vurderer endringa. Viss eit apparat genererer konfigurasjonen på nytt frå eit webgrensesnitt, noter direktivet, fila og datoen, og gjer endringa gjennom grensesnittet når det finst, fordi ein gjenoppbygging vil overskrive ei handredigering ved neste lagring.

client-to-client er ein eigen port

Sjølv innanfor eitt subnet kastar tenaren pakkar som kjem frå éin klient og er adresserte til ein annan, med mindre client-to-client er sett. Det nøkkelordet gjer tenaren til ein videresendar for partstrafikk i staden for eit endepunkt som berre tek imot han. Det er den andre føresetnaden folk går glipp av etter å ha retta topologien.

Det strekkjer seg ikkje til broadcast. Innstillinga videresender unicast mellom klientar; ho gjer ikkje tunnelen til eit delt segment, og inga mengd av ho vil levere ein multicast-oppdagingsførespurnad til kvar part.

TUN kontra TAP, og kva kvar kan bera

Å brukople ei tap-eining inn i LAN-et set fjernklientar i broadcast-domenet til kontoret, noko som løyser oppdaginga fullstendig. Prisen er plattformene som ikkje implementerer TAP, ei bru som må finnast på tenaren, og eit feildomene der ein broadcast-storm på kontorkabelen når kvar fjernberbar PC.

For to eller tre arbeidsstasjonar som treng namneoppslag, er ei hosts-oppføring eller ei unicast-adresse langt billegare enn ei bru. Grip til TAP når ein protokoll du ikkje kan erstatta avheng av oppdaging på lag 2, og ikkje før.

Klientar i same subnet utan bru

Å tildela ei adresse frå LAN-området set ikkje klienten på leidninga. Tenaren ruter mellom tunnel og Ethernet, så ARP for den adressa stoppar ved grensesnittet til tenaren, og resten av LAN-et får aldri vita kvar ho bur.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP lukkar dette gapet ved å la tenaren svara på vegner av klienten. For eit område administrerer parpd oppføringane medan klientar kjem og går, medan sysctl net.ipv4.conf.eth0.proxy_arp=1 svarar for alt som blir ruta andre stader, noko som er breitt nok til å skapa sine eigne overraskingar på eit travelt segment.

Uansett kva veg du vel, fjern NAT mellom tunnelen og leidninga. Ei MASQUERADE-regel skjuler nettopp adresseringsspørsmålet du prøver å svara på. Ho etterlèt òg neste person med ein topologi dei ikkje kan resonnere om frå klientsida.

Før du endrar noko, fang eitt forsøk på tenaren med tcpdump -ni tun0 og stadfest om partpakken i det heile kjem inn. At han kjem inn og blir forkasta peikar på client-to-client; at han aldri kjem inn peikar på topologi eller ruting. OpenVPN 2.6-handboka dokumenterer begge nøkkelorda og standardtopologien, noko som er verdt å sjekke mot versjonen din før du kopierer ei linje frå eit foruminnlegg.

• tun-grensesnittet viser ei poolmaske i staden for eit /30-partpar.
• Ein direkte ping til den andre tunneladressa lykkast før du testar oppdaging.
• Tenarkonfigurasjonen inneheld client-to-client når partar må utveksle pakkar.
• Namngje oppdagingsprotokollen du testar i staden for å seia at appen feilar.
• Bruk TAP berre viss kvar klientplattform i gruppa støttar det.
• Hald NAT utanfor vegen mellom tunnel og LAN når tilgjenge innan same subnet betyr noko.