TAP uten bro: et virtuelt segment med en rutet oppkobling

TAP overleverer Ethernet-rammer til operativsystemet, noe som er mer kapasitet enn de fleste fjernaksessdesign trenger og mindre enn en bro. Kjernen kan adressere det, rute gjennom det og brannmur-beskytte det uten å koble det til noe fysisk segment. Dette oppsettet er verdt å forstå først: et isolert virtuelt Ethernet-segment der serveren fungerer som ruter mot et ekte LAN. Det gir atferd på andre lag inne i tunnelen og vanlig IP-videreformidling utenfor, som er to forskjellige løfter. Resten er byggingen, ruten, returveien og tilbakerullingen.

Bygg det isolerte segmentet

På Linux tar grensesnittet tre kommandoer: opprett det, løft det, gi det en adresse innenfor segmentet du sikter til. Velg et prefiks som ikke kolliderer med kontorets LAN, og skriv det ned, fordi kollisjonen er usynlig til en vert som ikke burde finnes svarer.

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

Ingenting her krever en bro, og ingenting hindrer å legge til en senere. Kjernens TUN/TAP-dokumentasjon beskriver grensesnittet selv; bro-medlemskap og videreformidlingspolicy er separate beslutninger du tar etterpå.

Rut over grensen

Aktiver videreformidling, tillat de to prefiksene i videreformidlingskjeden, og legg til en rute mot kontorets prefiks med LAN-ruteren som neste hopp. VPN-siden sender da kontorrettet trafikk til serveren som sin gateway, og serveren videresender disse pakkene som seg selv, ikke som en bro. Et TAP-grensesnitt med videreformidling deaktivert er et segment som svarer lokalt og ikke når noe utover det, som er den vanlige halvferdige tilstanden. Kontroller grensesnitttellerne på begge sider etterpå, fordi en stigende mottaksteller med flat sendeteller på LAN-siden betyr et fall i videreformidlingskjeden, ikke en dårlig rute.

Skriv ruten og brannmurregelen som én endring, fordi hver for seg skaper en tilstand som fra klientens side ser ut som en rutingsfeil.

Bestem returveien

Enten lærer LAN-ruteren en rute tilbake til VPN-prefikset, eller serveren oversetter kildeadresser på vei ut. Oversettelse gjør returveien triviell og ødelegger kildeidentiteten, så destinasjonslogger vil vise serverens adresse for hver klient bak den. Et rutet prefiks bevarer identiteten og krever en endring på utstyr du kanskje ikke administrerer.

Velg bevisst i stedet for etter hva som er raskere å skrive. Ett rutet prefiks er vanligvis renere enn oversettelse, og oversettelse er vanligvis bedre enn å lære en uadministrert ruter et nytt prefiks for ett laboratorium.

Hold kringkastingsomfanget bevisst

Innenfor det virtuelle segmentet oppfører DHCP, oppdagelse og naboannonsering seg som på en svitsj, fordi det er én lenke. Over den rutede grensen gjør de ikke det, så kontorets DHCP og tjenesteoppdagelse trenger et eksplisitt design i stedet for en antagelse om at TAP innebærer dem. Grensesnitttypen er ikke et relé for tjenester som bor andre steder.

Det er den ærlige grunnen til å velge TAP i det hele tatt: noe på det virtuelle segmentet trenger lenkelokal atferd. Hvis ingenting trenger det, er en TUN-enhet med et rutet prefiks mindre, og det er mindre å forklare når den går i stykker.

Verifiser, og skriv så tilbakerullingen

Fra en VPN-klient, ping LAN-ruteren, ping en vert, og åpne én tjeneste som betyr noe over TCP. Kontroller deretter tellerne og videreformidlingskjeden, fordi et policyfall på avstand ser nøyaktig ut som en manglende rute. Tilbakerulling er det motsatte av byggingen og hører hjemme i endringsloggen før du begynner: fjern ruten, fjern adressen, slett grensesnittet.

Hvis kravet virkelig er ett Ethernet-segment over to steder, er en bro det ærlige svaret og et annerledes design med en annen skaderadius. Hvis kravet er tilgjengelighet, gjør det isolerte segmentet med en rutet oppkobling jobben med mindre å forklare senere.