TAP overleverer Ethernet-rammer til operativsystemet, noko som er meir kapasitet enn dei fleste fjernåtkomstdesign treng og mindre enn ei bru. Kjernen kan adressere det, rute gjennom det og brannmur-verne det utan å kople det til noko fysisk segment. Dette oppsettet er verdt å forstå først: eit isolert virtuelt Ethernet-segment der tenaren fungerer som ruter mot eit ekte LAN. Det gir åtferd på andre lag inne i tunnelen og vanleg IP-vidareformidling utanfor, som er to ulike lovnader. Resten er bygginga, ruta, returvegen og tilbakerullinga.

Bygg det isolerte segmentet

På Linux tek grensesnittet tre kommandoar: opprett det, løft det, gi det ei adresse innanfor segmentet du siktar til. Vel eit prefiks som ikkje kolliderer med kontor-LANet, og skriv det ned, fordi kollisjonen er usynleg til ein vert som ikkje burde finnast svarar.

ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr add 10.77.0.1/24 dev tap0

Ingenting her krev ei bru, og ingenting hindrar å leggje til ei seinare. TUN/TAP-dokumentasjonen til kjernen skildrar grensesnittet sjølv; brumedlemskap og vidareformidlingspolitikk er separate avgjerder du tek etterpå.

Rut over grensa

Slå på vidareformidling, tillat dei to prefiksa i vidareformidlingskjeda, og legg til ei rute mot kontorprefikset med LAN-ruteren som neste hopp. VPN-sida sender då kontorretta trafikk til tenaren som gatewayen sin, og tenaren videresender desse pakkane som seg sjølv, ikkje som ei bru. Eit TAP-grensesnitt med vidareformidling slått av er eit segment som svarar lokalt og ikkje når noko utover det, som er den vanlege halvferdige tilstanden. Kontroller grensesnittteljarane på begge sider etterpå, fordi ein stigande mottaksteljar med flat sendeteljar på LAN-sida tyder eit fall i vidareformidlingskjeda, ikkje ei dårleg rute.

Skriv ruta og brannmurregelen som éi endring, fordi kvar for seg skapar ein tilstand som frå klientsida ser ut som ein rutefeil.

Avgjer returvegen

Anten lærer LAN-ruteren ei rute tilbake til VPN-prefikset, eller tenaren omset kjeldeadresser på veg ut. Omsetjing gjer returvegen triviell og øydelegg kjeldeidentiteten, så destinasjonsloggar vil vise adressa til tenaren for kvar klient bak han. Eit ruta prefiks bevarar identiteten og krev ei endring på utstyr du kanskje ikkje administrerer.

Vel medvite i staden for etter kva som er raskare å skrive. Eitt ruta prefiks er vanlegvis reinare enn omsetjing, og omsetjing er vanlegvis betre enn å lære ein uadministrert ruter eit nytt prefiks for eitt laboratorium.

Hald kringkastingsomfanget medvite

Innanfor det virtuelle segmentet oppfører DHCP, oppdaging og naboannonsering seg som på ein svitsj, fordi det er éi lenkje. Over den ruta grensa gjer dei ikkje det, så kontor-DHCP og tenesteoppdaging treng eit eksplisitt design i staden for ei føresetnad om at TAP inneber dei. Grensesnitttypen er ikkje eit relé for tenester som bur andre stader.

Det er den ærlege grunnen til å velje TAP i det heile: noko på det virtuelle segmentet treng lenkjelokal åtferd. Viss ingenting treng det, er ei TUN-eining med eit ruta prefiks mindre, og det er mindre å forklare når ho går i stykker.

Verifiser, og skriv så tilbakerullinga

Frå ein VPN-klient, ping LAN-ruteren, ping ein vert, og opne éin teneste som betyr noko over TCP. Kontroller så teljarane og vidareformidlingskjeda, fordi eit policyfall på avstand ser nøyaktig ut som ei manglande rute. Tilbakerulling er det motsette av bygginga og høyrer heime i endringsloggen før du byrjar: fjern ruta, fjern adressa, slett grensesnittet.

Viss kravet verkeleg er eitt Ethernet-segment over to stader, er ei bru det ærlege svaret og eit annleis design med ein annan skaderadius. Viss kravet er tilgjenge, gjer det isolerte segmentet med ei ruta oppkopling jobben med mindre å forklare seinare.

Relaterte artiklar