TAP uden en bro: et virtuelt segment med en rutet uplink

TAP overlader Ethernet-rammer til styresystemet, hvilket er mere kapacitet, end de fleste fjernadgangsdesign har brug for, og mindre end en bro. Kernen kan adressere det, route gennem det og sætte firewall omkring det uden at koble det til et fysisk segment. Det arrangement er værd at forstå først: et isoleret virtuelt Ethernet-segment, hvis server fungerer som router mod et rigtigt LAN. Det giver lag-to-adfærd inde i tunnelen og almindelig IP-videresendelse udenfor, hvilket er to forskellige løfter. Resten her er opbygningen, ruten, returvejen og tilbagerulningen.

Byg det isolerede segment

På Linux tager grænsefladen tre kommandoer: opret den, løft den op, giv den en adresse inde i det segment, du sigter efter. Vælg et præfiks, der ikke kolliderer med kontorets LAN, og skriv det ned, fordi kollisionen er usynlig, indtil en vært svarer, som ikke burde eksistere.

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

Intet her kræver en bro, og intet forhindrer at tilføje en senere. Kernens TUN/TAP-dokumentation beskriver selve grænsefladen; bro-medlemskab og videresendelsespolitik er separate beslutninger, du træffer bagefter.

Rut over grænsen

Aktivér videresendelse, tillad de to præfikser i videresendelseskæden, og tilføj en rute mod kontorets præfiks med LAN-routeren som næste hop. VPN-siden sender derefter kontorvendt trafik til serveren som sin gateway, og serveren videresender disse pakker som sig selv, ikke som en bro. En TAP-grænseflade med videresendelse deaktiveret er et segment, der svarer lokalt og ikke når noget ud over det, hvilket er den sædvanlige halvfærdige tilstand. Kontrollér grænsefladetællerne på begge sider bagefter, fordi en stigende modtagelsestæller med en flad sendetæller på LAN-siden betyder et drop i videresendelseskæden, ikke en dårlig rute.

Skriv ruten og firewallreglen som én ændring, fordi hver for sig skaber en tilstand, der fra klientens side ligner en routingfejl.

Beslut returvejen

Enten lærer LAN-routeren en rute tilbage til VPN-præfikset, eller serveren oversætter kildeadresser på vej ud. Oversættelse gør returvejen triviel og ødelægger kildeidentiteten, så destinationslogfiler vil vise serverens adresse for hver klient bag den. Et rutet præfiks bevarer identiteten og kræver en ændring på udstyr, du måske ikke administrerer.

Vælg bevidst i stedet for efter, hvad der er hurtigere at skrive. Et enkelt rutet præfiks er normalt renere end oversættelse, og oversættelse er normalt bedre end at lære en uadministreret router et nyt præfiks for ét laboratorium.

Hold broadcast-området bevidst

Inden for det virtuelle segment opfører DHCP, opdagelse og naboannoncering sig som på en switch, fordi det er ét link. Over den rutede grænse gør de det ikke, så kontorets DHCP og tjenesteopdagelse har brug for et eksplicit design i stedet for en antagelse om, at TAP indebærer dem. Grænsefladetypen er ikke et relæ for tjenester, der bor andre steder.

Det er den ærlige grund til at vælge TAP overhovedet: noget på det virtuelle segment har brug for link-lokal adfærd. Hvis intet har det, er en TUN-enhed med et rutet præfiks mindre, og der er mindre at forklare, når den går i stykker.

Verificér, og skriv så tilbagerulningen

Fra en VPN-klient, ping LAN-routeren, ping en vært, og åbn én tjeneste, der betyder noget, over TCP. Kontrollér derefter tællerne og videresendelseskæden, fordi et politikdrop på afstand ser præcis ud som en manglende rute. Tilbagerulning er det omvendte af opbygningen og hører i ændringsloggen, før du begynder: fjern ruten, fjern adressen, slet grænsefladen.

Hvis kravet virkelig er ét Ethernet-segment, der spænder over to lokaliteter, er en bro det ærlige svar og et anderledes design med en anden skadesradius. Hvis kravet er tilgængelighed, klarer det isolerede segment med en rutet uplink opgaven med mindre at forklare senere.