OpenVPN-klienter ser ikke hverandre: subnet eller net30?

To uavhengige feil gir samme klage. I den første når én klient ikke en annen selv via tunneladressen, fordi adressene ikke er i samme subnet eller serveren ikke videresender trafikk mellom parter. I den andre virker ping, men appens enhetsliste blir stående tom, fordi oppdagelsen bygger på broadcast som en tunnel på lag 3 ikke kan bære. Én ping skiller dem, og rettelsen for hver av dem ligner slett ikke rettelsen for den andre.

Én ping deler problemet i to

Fra én klient, ping den andre klientens tunneladresse, ikke navnet og ikke LAN-adressen. Hvis det feiler, er problemet videresending eller adressering, og oppdagelse er irrelevant til det er rettet. Hvis det lykkes, virker videresendingen allerede, og det som mangler er broadcast eller navneoppslag.

ip addr show tun0

Les klientens grensesnitt først av alt, fordi nettverksmasken navngir topologien. En /24 eller en annen subnetmaske betyr en delt pool; en /30 med en partadresse betyr det eldre punkt-til-punkt-oppsettet, der hver klient har nøyaktig én nabo, serveren.

net30 kontra subnet, lest fra klientsiden

Med net30 deler serveren ut en liten blokk per klient, så det finnes ingen rute til en annen klients tunneladresse med mindre serveren videresender den. Med subnet er hele poolen ett nett, hver klient kan adressere hver andre, og serveren videresender mellom dem. Derfor kan én serverkonfigurasjon se sunn ut mens ping mellom parter feiler: ingenting er ødelagt, klientene er rett og slett ikke i ett nett. Klienten ser en fungerende lenke og en partadresse som ikke svarer, noe som leses som en brannmur, men er et adresseringsopplegg.

Å bytte direktivet er en redigering på serversiden pluss en omstart, og det gjelder for neste tilkobling, ikke for økter som allerede er oppe. Koble klientene til på nytt før du vurderer endringen. Hvis et apparat genererer konfigurasjonen på nytt fra et webgrensesnitt, noter direktivet, filen og datoen, og gjør endringen gjennom grensesnittet når det finnes, fordi en gjenoppbygging vil overskrive en håndredigering ved neste lagring.

client-to-client er en egen port

Selv innenfor ett subnet kaster serveren pakker som kommer fra én klient og er adressert til en annen, med mindre client-to-client er satt. Det nøkkelordet gjør serveren til en videresender for partstrafikk i stedet for et endepunkt som bare tar imot den. Det er den andre betingelsen folk går glipp av etter å ha rettet topologien.

Det strekker seg ikke til broadcast. Innstillingen videresender unicast mellom klienter; den gjør ikke tunnelen til et delt segment, og ingen mengde av den vil levere en multicast-oppdagelsesforespørsel til hver part.

TUN kontra TAP, og hva hver kan bære

Å brokoble en tap-enhet inn i LAN-et setter fjernklienter i kontorets broadcast-domene, noe som løser oppdagelsen fullstendig. Prisen er plattformene som ikke implementerer TAP, en bro som må finnes på serveren, og et feildomene der en broadcast-storm på kontorkabelen når hver fjernbærbar PC.

For to eller tre arbeidsstasjoner som trenger navneoppslag, er en hosts-oppføring eller en unicast-adresse langt billigere enn en bro. Grip til TAP når en protokoll du ikke kan erstatte avhenger av oppdagelse på lag 2, og ikke før.

Klienter i samme subnet uten bro

Å tildele en adresse fra LAN-området setter ikke klienten på ledningen. Serveren ruter mellom tunnel og Ethernet, så ARP for den adressen stopper ved serverens grensesnitt, og resten av LAN-et får aldri vite hvor den bor.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP lukker dette gapet ved å la serveren svare på klientens vegne. For et område administrerer parpd oppføringene mens klienter kommer og går, mens sysctl net.ipv4.conf.eth0.proxy_arp=1 svarer for alt som rutes andre steder, noe som er bredt nok til å skape sine egne overraskelser på et travelt segment.

Uansett hvilken vei du velger, fjern NAT mellom tunnelen og ledningen. En MASQUERADE-regel skjuler nettopp adresseringsspørsmålet du prøver å svare på. Den etterlater også neste person med en topologi de ikke kan resonnere om fra klientsiden.

Før du endrer noe, fang ett forsøk på serveren med tcpdump -ni tun0 og bekreft om partpakken i det hele tatt ankommer. At den ankommer og forkastes peker på client-to-client; at den aldri ankommer peker på topologi eller ruting. OpenVPN 2.6-håndboken dokumenterer begge nøkkelordene og standardtopologien, noe som er verdt å sjekke mot din versjon før du kopierer en linje fra et foruminnlegg.

• tun-grensesnittet viser en poolmaske i stedet for et /30-partpar.
• En direkte ping til den andre tunneladressen lykkes før du tester oppdagelse.
• Serverkonfigurasjonen inneholder client-to-client når parter må utveksle pakker.
• Navngi oppdagelsesprotokollen du tester i stedet for å si at appen feiler.
• Bruk TAP bare hvis hver klientplattform i gruppen støtter det.
• Hold NAT utenfor veien mellom tunnel og LAN når tilgjengelighet innen samme subnet betyr noe.