Два клетъчни обекта без входящи портове: изградете хъб, който работи

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

Нито един обект не може да бъде избиран, затова и двата трябва да се свързват навън

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

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

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

ip -4 addr show scope global
ip -6 addr show scope global

Кой запознава възлите и кой носи пакетите

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

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

Един маршрут на обект, притежаван от възел

Хъбът се нуждае от един тунел на обект, отделен LAN префикс зад всеки и маршрут за всеки префикс, който посочва собственика му. В примера хъбът е 10.61.0.1, обект A е 10.61.0.11 с LAN 10.60.10.0/24, а обект B е 10.61.0.12 с LAN 10.60.20.0/24. Всеки маршрут по-долу сочи към възела, който притежава префикса, а не към интерфейса на тунела:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

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

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

Поддържайте всяко съответствие живо през оператора

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

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

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

Докажете двете посоки, после докажете възстановяване

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

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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