pfSense като VPN сървър и клиент: два пътя, един рутер

Едно устройство може да гледа в две посоки едновременно: странстващи потребители се свързват навътре, а същата кутия се свързва навън към доставчик на изход, така че избраният трафик да излиза през друга мрежа. Включването на двете услуги отнема минути; съвместното им съществуване изисква проект, защото втората роля пренаписва таблицата за маршрутизация, на която разчита първата. Три условия решават дали схемата работи, а именно дали входящата услуга запазва собствения си обратен път, дали изходящият тунел все още достига до своя партньор и дали трафикът, който сте искали да препратите, се избира за изхода. Сбъркайте едно и получавате два тунела, които и двата съобщават за връзка, докато между тях не преминава нищо полезно. Проверките по-долу установяват всяко условие в реда, в който отказите обикновено се появяват.

Назовавайте двете роли, преди да пипате каквато и да е настройка

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

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

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

Дръжте отговорите на сървъра по пътя WAN

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

Не позволявайте на изходящия тунел да изяде собствената си крайна точка

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Изберете кои потребители получават изхода

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

Решете какво се случва, когато изходът се провали

Запишете поведението при отказ, преди да се случи: когато изходящият тунел падне, връщат ли се потребителите към обичайния WAN или са блокирани, докато изходът се върне? И двата отговора са защитими и устройството няма да избере вместо вас. Премахнат маршрут или политика, сочеща към мъртъв шлюз, не дават автоматично резултат на пълно блокиране. Ако искате блокиране, политиката трябва да го каже изрично и трябва да се тества чрез отнемане на изхода, а не чрез разсъждения за него. Ако искате връщане, обявете го на потребителите, защото трафикът, който тихо поема обичайния път, е точно трафикът, който някой е смятал за покрит.

Изключете клиентския екземпляр, наблюдавайте до какво свързан потребител все още достига, след което го стартирайте отново. Заявка, която изтече по таймаут, е резултатът на пълно блокиране, който поискахте; тази, която отговаря с адреса WAN, е връщането, което не сте документирали. Повторете проверката за IPv6 и за DNS, защото политика, написана за IPv4, не казва нищо за трафик AAAA и resolver, изтласкан от който и да е тунел, отговаря откъдето заявката действително излиза.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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