Два VPN клиента, два публични адреса: накарайте SNAT да съвпадне

Два VPN клиента могат да излизат през два различни публични IPv4 адреса и правилото, което го прави, е по-кратко, отколкото повечето хора очакват. Работи не заради синтаксиса на iptables, а заради състоянието на пакета, когато достигне веригата за изход: адресът на източника там все още трябва да разграничава клиентите. Ако по-ранен masquerade вече е слял двата върху един адрес, никакво правило за отделен клиент не може да възстанови разликата. Решете първо този въпрос, после пишете превода.

Коя идентичност оцелява до шлюза

Правилото съпоставя адреса на източника на пакета, а не потребителско име на VPN и не името, което показва клиентското приложение. Всичко, което преобразува пакета по-рано по пътя, определя какво още може да види вашето правило. Изпълнете таблицата nat по ред и намерете точката, в която източникът все още е отделен за всеки клиент.

iptables -t nat -S POSTROUTING

Прочетете този списък отгоре. Правило за masquerade близо до върха пренаписва източника за всеки съответстващ поток, а записите за отделен клиент, поставени след него, съвпадат с адрес, който вече не съществува. Когато две устройства в LAN споделят един тунел и пристигат като един вътрешен адрес, дизайнът трябва да се промени преди защитната стена: дръжте диапазоните им на източника отделни или дайте на всяко свой вътрешен адрес.

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

Преобразуването не може да измисли адрес

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

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

Вмъкнете преди общия masquerade

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

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

Първата команда посочва интерфейса, през който пакет към интернет действително излиза. Втората отпечатва веригата с номера на редове. Общият запис masquerade е редът, над който трябва да останете.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

Двете правила по-горе съпоставят по един вътрешен адрес, ограничават съпоставянето до изходния интерфейс и задават източника изрично. Вмъкнете, а не добавете: на позиция 1 те се оценяват преди реда masquerade. Редът между двете няма значение, защото източниците им се различават. Заменете ens3 с това, което съобщи командата за маршрут, и дръжте другите мениджъри на защитната стена далеч от същите куки, защото два инструмента, пишещи една таблица, е обичайната причина правилно правило да няма ефект.

Докажете източника с нов поток

NAT със състояние свързва преобразуване, когато потокът започне, и го използва повторно за следващите пакети, така че сесия, отворена преди промяната, запазва стария си източник след промяната. Само ново инициирано свързване доказва правилото.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

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

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