Стартиране на VPN и сайт на един хост без конфликти

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

Решете какво слуша на кой адрес и транспорт

Напишете таблица с три колони — адрес, транспорт и порт — и един ред за всяка услуга, включително административния интерфейс. TCP 443 за сайта и UDP 443 за VPN не са конфликт, дори когато числата съвпадат, защото транспортът е различен. Две услуги на един и същ адрес, транспорт и порт се нуждаят от уговорка, която реализацията документира, а не от такава, която измисляте по време на авария. Тази таблица е и артефактът, който прави следващата промяна прегледима.

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

Решете коя идентичност принадлежи на коя услуга

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

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

Решете къде живее администрирането

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

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

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

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

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

Изолацията може да е контейнер, лимит на cgroup, отделна опашка или втори хост, а правилният избор зависи от това кой ресурс се оспорва. Промяната на порт тук не поправя нищо, а по-голям инстанс не поправя нищо, ако лимитът е една наситена опашка. Решете с измерване: назовете ресурса, натоварете го, после изберете най-малката изолация, която премахва състезанието.

Проверете отвън, после отново след рестарт

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

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