TAP utan brygga: ett virtuellt segment med en routad upplänk

TAP lämnar Ethernet-ramar till operativsystemet, vilket är mer kapacitet än de flesta fjärråtkomstdesigner behöver och mindre än en brygga. Kärnan kan adressera det, routa genom det och brandväggsskydda det utan att koppla det till något fysiskt segment. Det upplägget är värt att förstå först: ett isolerat virtuellt Ethernet-segment vars server fungerar som router mot ett riktigt LAN. Det ger beteende på andra lagret inne i tunneln och vanlig IP-vidarebefordran utanför, vilket är två olika löften. Resten är bygget, rutten, returvägen och återställningen.

Bygg det isolerade segmentet

På Linux tar gränssnittet tre kommandon: skapa det, lyft det, ge det en adress inom segmentet du avser. Välj ett prefix som inte krockar med kontorets LAN och skriv ned det, eftersom krocken är osynlig tills en värd som inte borde finnas svarar.

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

Ingenting här kräver en brygga, och ingenting hindrar att lägga till en senare. Kärnans TUN/TAP-dokumentation beskriver gränssnittet självt; bryggmedlemskap och vidarebefordringspolicy är separata beslut som du fattar efteråt.

Routa över gränsen

Aktivera vidarebefordran, tillåt de två prefixen i vidarebefordringskedjan, och lägg till en rutt mot kontorets prefix med LAN-routern som nästa hopp. VPN-sidan skickar då kontorsriktad trafik till servern som sin gateway, och servern vidarebefordrar dessa paket som sig själv, inte som en brygga. Ett TAP-gränssnitt med vidarebefordran avstängd är ett segment som svarar lokalt och inte når något bortom det, vilket är det vanliga halvfärdiga tillståndet. Kontrollera gränssnittsräknarna på båda sidorna efteråt, eftersom en stigande mottagningsräknare med en platt sändningsräknare på LAN-sidan betyder ett fall i vidarebefordringskedjan, inte en dålig rutt.

Skriv rutten och brandväggsregeln som en enda ändring, eftersom var och en för sig skapar ett tillstånd som från klientsidan ser ut som ett routingfel.

Bestäm returvägen

Antingen lär sig LAN-routern en rutt tillbaka till VPN-prefixet, eller så översätter servern källadresser på väg ut. Översättning gör returvägen trivial och förstör källans identitet, så destinationsloggar kommer att visa serverns adress för varje klient bakom den. Ett routat prefix behåller identiteten och kräver en ändring på utrustning som du kanske inte administrerar.

Välj medvetet i stället för efter vad som är snabbare att skriva. Ett enda routat prefix är vanligtvis renare än översättning, och översättning är vanligtvis bättre än att lära en ohanterad router ett nytt prefix för ett enda labb.

Håll sändningsomfånget medvetet

Inom det virtuella segmentet beter sig DHCP, upptäckt och grannannonsering som på en switch, eftersom det är en enda länk. Över den routade gränsen gör de inte det, så kontorets DHCP och tjänsteupptäckt behöver en uttrycklig design i stället för ett antagande att TAP innefattar dem. Gränssnittstypen är inte ett relä för tjänster som bor någon annanstans.

Det är det ärliga skälet att välja TAP överhuvudtaget: något på det virtuella segmentet behöver länklokalt beteende. Om ingenting behöver det är en TUN-enhet med ett routat prefix mindre, och det finns mindre att förklara när den går sönder.

Verifiera och skriv sedan återställningen

Från en VPN-klient, pinga LAN-routern, pinga en värd, och öppna en tjänst som spelar roll över TCP. Kontrollera sedan räknarna och vidarebefordringskedjan, eftersom ett policyfall på avstånd ser exakt ut som en saknad rutt. Återställning är motsatsen till bygget och hör hemma i ändringsloggen innan du börjar: ta bort rutten, ta bort adressen, radera gränssnittet.

Om kravet verkligen är ett Ethernet-segment över två platser, är en brygga det ärliga svaret och en annan design med en annan påverkansradie. Om kravet är nåbarhet gör det isolerade segmentet med en routad upplänk jobbet med mindre att förklara senare.