Две клеточни локации без влезни порти: изградете центар што работи

Две локации на клеточни врски се соочуваат со истиот проблем во двете насоки: ниту една не може да прифати небарана 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 алтернативата кога постои и однесувањето кога центарот е недостапен. Центарот сега е дел од вашиот модел на достапност, затоа запишете го тоа наместо да го откриете за време на прекин.