Маскарад или маршрутизация по политика: LAN трафик през VPN шлюз

Поставянето на цяла LAN зад VPN тунел е лесната част; решаването как отсрещната страна вижда тези клиенти не е. Маскарадът пренаписва всеки LAN източник към адреса на тунела на шлюза, така че отдалеченият край отговаря на един партньор. Маршрутизацията по политика запазва оригиналните адреси и изисква отдалеченият край да знае как да ги достигне. Нито едно от двете не е по подразбиране; изборът следва от това кой притежава отсрещната страна и дали идентичността на всяко устройство е важна.

Двата дизайна обещават различни неща

Маскарадът свежда LAN до един видим хост: шлюза. Отдалечената мрежа отговаря на този един адрес, а шлюзът превежда отговорите обратно към клиента, започнал потока. Отсрещната страна не се нуждае от маршрут към вашите частни префикси, затова този дизайн оцелява при доставчик, който отказва да ги носи. Шлюзът става и източник на всяка връзка, така че отсрещната страна не може да различи два клиента.

Маршрутизацията по политика запазва адреса на всеки клиент непокътнат. Отдалечената мрежа вижда действителния източник и може да го запише, да приложи правило за конкретен хост или да изпрати отговора директно на този адрес. Тази видимост е целият смисъл и идва със задължение: отсрещната страна трябва да има маршрут за LAN префикса, който сочи обратно през тунела. Планирайте този маршрут, преди да включите правилото, защото тунелът ще се вдигне така или иначе и ще липсват само отговорите.

Режимите на отказ се различават толкова, колкото и обещанията. Липсващо правило за маскарад дава пакети, които излизат с частни източници и никога не се връщат. Липсващ обратен маршрут дава същия симптом при маршрутизация по политика, но поправката е на отдалечения рутер, а не на шлюза.

Маскарад: един партньор от отсрещната страна

Пътят на маскарада има ред, който е важен. Препращането трябва да е включено, преди каквото и да е NAT правило да свърши полезна работа, таблицата за филтриране трябва да допуска транзита в двете посоки и едва тогава транслацията се прилага на интерфейса на тунела.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Клиентите все още се нуждаят от път до шлюза. Или шлюзът е рутерът им по подразбиране, или те носят специфичен маршрут за отдалечения префикс; ако отделен рутер остане по подразбиране, той се нуждае от статичен маршрут за дестинациите на тунела, иначе пакетът отива към грешен хоп, преди шлюзът да го види.

DNS е отделно решение. Резолвер от отсрещната страна отговаря само ако отговорът му може да се върне до клиента. При маскарад заявката изглежда идва от шлюза, така че обратният път на резолвера вече е осигурен; при маршрутизация по политика резолверът се нуждае от същия обратен маршрут като всяка друга отдалечена услуга.

Маршрутизация по политика: запазете източника, добавете обратен път

Маршрутизацията по политика започва с таблица и правило, което я избира. Трафикът, влизащ от LAN интерфейса, се изпраща в специална таблица, а тази таблица носи маршрут по подразбиране през тунела. Основната таблица остава недокосната, така че трафикът, породен от самия шлюз, може да следва друг път.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

След това отсрещната страна трябва да маршрутизира LAN префикса обратно през тунела. Това е конфигурация на отдалечения рутер, не на този шлюз. Шлюзът също трябва да приема отговори, пристигащи на различен интерфейс от този, който основната таблица предполага; разхлабената филтрация на обратния път (rp_filter със стойност 2) е обичайната корекция, когато строгият режим изхвърля тези пакети.

Когато два тунела са активни, маркирайте всеки поток при влизането и оставете маркера да избере таблицата. Правило, което гледа само входния интерфейс, изпраща трафика на двата тунела в една и съща таблица, затова вторият тунел краде потоци от първия. Тествайте маркера с връзка, която надживява повторно свързване, защото тогава се появява смесена политика.

Решете по собственост и по това какво записва отсрещната страна

Ако тунелът завършва при доставчик, използвайте маскарад. Този оператор няма да маршрутизира вашите частни LAN диапазони и няма причина да различава отделни клиенти зад вашия шлюз. Един видим партньор е единственият модел, който неговата политика поддържа, затова му дайте това и пазете транслацията на вашия край. Доставчикът вижда един партньор, което е точно това, което политиката му очаква, а вашите клиенти наследяват тази единна идентичност.

Ако и двата края са ваши и отдалечените услуги действат по адресите на източника, маршрутизацията по политика заслужава своя допълнителен маршрут. Тогава правилата на защитната стена, достъпът по потребители и одитните дневници могат да различават клиентите. Ако на отсрещната страна е нужна само достижимост, маскарадът е по-прост и премахва цял клас грешки с обратния маршрут.

Хибридните дизайни са нормални: маршрутизация по политика във вашата мрежа, маскарад на края при доставчика. Важно е да запишете кой хоп трансформира и кой хоп маршрутизира, защото случайно NAT правило, добавено за един клиент, скрива източника за всеки клиент в същата верига.

Проверете от клиент, после от втори клиент

Изпълнете теста там, където започва трафикът. Проверете маршрута, който хостът използва, наблюдавайте как пакетът се появява на интерфейса на тунела и прегледайте conntrack за транслацията. Тази последователност доказва, че пакетът е поел предвидения път, а не просто е пристигнал някъде.

Повторете теста след повторно свързване. Правило за маскарад, което назовава интерфейса, оцелява при нов адрес на тунела; правило, което назовава стария адрес, не оцелява. После тествайте втори LAN хост, защото дизайн, който работи на една машина, често зависи от собствения маршрут на тази машина, а не от политиката на шлюза.

Запишете избрания модел, трансформирания или запазен източник и собственика на обратния маршрут в бележките на шлюза. Иначе следващият човек, който добави клиент или тунел, ще гадае, а гадането е как една работеща LAN-към-VPN конфигурация става частична.