Стартирате VPN клиент през SSH? Първо заковайте собствения си маршрут
Клиент с пълен тунел пренаписва таблицата, която носи вашия SSH отговор. Заковайте един маршрут до хоста през стария шлюз или стартирайте клиента в собственото му пространство от имена.
Влизате по SSH в хост за компилация, стартирате на него VPN клиента и сесията спира да отговаря. Нищо не се е срутило и нищо не изглежда погрешно конфигурирано по очевиден начин. Клиентът е инсталирал маршрут по подразбиране, така че отговорите към вашата работна станция сега излизат през тунела, където адресът на работната ви станция не е маршрутизируем. Интересното е, че този изход е бил предвидим, а поправката е един маршрут, записан преди клиентът да стартира. Да приемем сървър с една мрежова карта, шлюз 192.0.2.254 и администратор, който се свързва от 203.0.113.9.
Запишете пътя, преди да започнете
ip route show default показва текущия шлюз и интерфейс, докато ip route get 203.0.113.9 показва кой интерфейс и адрес на източника ядрото би използвало за вашата сесия. Запазете и двата изхода. След като тунелът се вдигне, тези две команди трябва все още да описват физическия път, а ако описват тунела вместо това, сесията вече живее на заем.
Установената връзка е това, което има значение, затова не проверявайте само с нов вход. Нова сесия може да успее за кратко чрез състояние, което старата вече не притежава.
Заковайте адреса в собствената конфигурация на клиента
Маршрут, добавен на ръка, изчезва при рестарт и се състезава с актуализациите на таблицата на самия клиент, затова сложете изключението там, където таблицата се управлява. При OpenVPN ключовата дума net_gateway се разрешава до шлюза, който е съществувал преди тунела, така че route 203.0.113.9 255.255.255.255 net_gateway оставя точно един адрес извън него. WireGuard изисква различен подход, защото wg-quick управлява маршрутите сам: задайте Table = off и добавете изключението в PostUp, със съответстващ PostDown, който го премахва. Двете форми изразяват същото намерение и двете ограничават изключението до един адрес, вместо да отслабят тунела за всичко.
За IPv6 същата идея взема префикс за един хост, а случаят с обвит транспорт си заслужава да се запомни: ако външната връзка на самия тунел живее на фиксиран адрес, този адрес трябва да остане извън тунела, който носи, иначе клиентът насочва собствения си транспорт вътре в себе си.
Или извадете главната таблица от уравнението
Когато няколко услуги на хоста трябва да запазят нормалния си път, спрете да редактирате главната таблица и дайте на клиента собствена. Мрежово пространство от имена с двойка veth прави това чисто: маршрутът по подразбиране на клиента живее в друг стек и само процесите, стартирани вътре в него, използват тунела. Политическото маршрутизиране стига до подобно място за една дестинация, като изпраща съвпадащия трафик към отделна таблица, чийто маршрут по подразбиране все още сочи към физическия шлюз. И двата подхода оставят главната таблица на хоста без нов маршрут по подразбиране и именно това свойство държи SSH отговарящ.
И двете са повече механика от един маршрут до хост и двете си заслужават, когато повече от едно нещо на машината трябва да преживее тунела.
Приемете, че заковаването може да се провали
Маршрут, обвързан с текущия ви публичен адрес, се чупи в момента, в който доставчикът ви го преназначи. Отдалечен сървър тогава се нуждае от път, който не зависи от този адрес: конзола, втори интерфейс за управление или междинен хост, който остава извън тунела.
Две предпазни мерки струват десет минути. Пазител, който спира клиента, ако потвърждаващ вход не се появи в рамките на няколко минути, превръща блокирането в забавяне, а втора SSH сесия, задържана отворена по време на промяната, доказва, че изключението работи, докато тунелът е вдигнат. Само keepalive съобщения не помагат тук, защото пътят е изчезнал, а не е бездействащ; те само правят смъртта по-лесна за забелязване.
Проверете в реда, който има значение
Свържете тунела, потвърдете, че маршрутът до вашия адрес все още излиза през физическия шлюз, след което отворете нова сесия. Ако новата сесия работи, а старата все пак умира, причината е проследяване на връзки или firewall със състояние, а не маршрутизация, което е различна поправка.
Запишете закования адрес и командата, която го доказа, в записа за промени. Следващият човек, който стартира клиент на този хост, ще се нуждае от двете, а адресът може вече да се е променил.