TAP без мосту: віртуальний сегмент із маршрутизованим зовнішнім каналом

TAP передає кадри Ethernet операційній системі, що є більшою можливістю, ніж потрібно більшості проєктів віддаленого доступу, і меншою, ніж міст. Ядро може адресувати його, маршрутизувати через нього та захищати міжмережевим екраном, не приєднуючи його до жодного фізичного сегмента. Цю схему варто зрозуміти насамперед: ізольований віртуальний сегмент Ethernet, сервер якого діє як маршрутизатор у бік справжньої локальної мережі. Він дає поведінку другого рівня всередині тунелю та звичайну IP-пересилку зовні, а це дві різні обіцянки. Решта — це збирання, маршрут, зворотний шлях і відкат.

Побудуйте ізольований сегмент

У Linux інтерфейс приймає три команди: створіть його, підніміть його, дайте йому адресу всередині задуманого сегмента. Виберіть префікс, який не збігається з офісною локальною мережею, і запишіть його, бо збіг непомітний, доки не відповість хост, якого не повинно існувати.

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

Ніщо тут не вимагає мосту, і ніщо не заважає додати його пізніше. Документація ядра щодо TUN/TAP описує сам інтерфейс; належність до мосту та політика пересилки — це окремі рішення, які ви ухвалюєте пізніше.

Маршрутизуйте через кордон

Увімкніть пересилку, дозвольте два префікси в ланцюжку пересилки та додайте маршрут до офісного префікса, вказавши маршрутизатор локальної мережі наступним переходом. Потім сторона VPN надсилає офісний трафік серверу як своєму шлюзу, а сервер пересилає ці пакети як він сам, а не як міст. Інтерфейс TAP з вимкненою пересилкою — це сегмент, який відповідає локально і нічого за собою не досягає, що є звичайним незавершеним станом. Потім перевірте лічильники інтерфейсу з обох боків, бо зростаючий лічильник приймання за незмінного лічильника надсилання на боці локальної мережі означає втрату в ланцюжку пересилки, а не поганий маршрут.

Запишіть маршрут і правило міжмережевого екрана як одну зміну, бо кожне окремо створює стан, який з боку клієнта виглядає як збій маршрутизації.

Визначте зворотний шлях

Або маршрутизатор локальної мережі вивчає зворотний маршрут до префікса VPN, або сервер транслює адреси джерела на виході. Трансляція робить зворотний шлях тривіальним і знищує ідентичність джерела, тому журнали призначення показуватимуть адресу сервера для кожного клієнта за ним. Маршрутизований префікс зберігає ідентичність і вимагає зміни на обладнанні, яким ви, можливо, не керуєте.

Виберіть усвідомлено, а не за тим, що швидше набрати. Один маршрутизований префікс зазвичай чистіший за трансляцію, а трансляція зазвичай краща, ніж навчати некерований маршрутизатор новому префіксу заради однієї лабораторії.

Тримайте область широкомовлення усвідомленою

Усередині віртуального сегмента DHCP, виявлення та оголошення сусідів поводяться як на комутаторі, бо це одна ланка. За маршрутизованим кордоном вони так не роблять, тому офісному DHCP і виявленню служб потрібен явний проєкт, а не припущення, що TAP їх передбачає. Тип інтерфейсу не є ретранслятором для служб, які живуть в іншому місці.

Ось чесна причина взагалі вибирати TAP: чомусь у віртуальному сегменті потрібна поведінка, локальна для ланки. Якщо нічому це не потрібно, пристрій TUN із маршрутизованим префіксом менший, і пояснювати при поломці менше.

Перевірте, а потім напишіть відкат

З клієнта VPN пропінгуйте маршрутизатор локальної мережі, пропінгуйте хост і відкрийте одну важливу службу через TCP. Потім перевірте лічильники та ланцюжок пересилки, бо втрата за політикою здалеку виглядає точно як відсутній маршрут. Відкат — це зворотне до збирання, і він має бути в записі змін до початку: видаліть маршрут, видаліть адресу, видаліть інтерфейс.

Якщо вимога справді полягає в одному сегменті Ethernet на два майданчики, міст — чесна відповідь і інший проєкт з іншим радіусом впливу. Якщо вимога — доступність, ізольований сегмент із маршрутизованим зовнішнім каналом виконує роботу з меншою кількістю пояснень пізніше.