CGNAT портторду бөгөттөгөндө VPS аркылуу үй серверин жарыялоо

Мен сырттан баштадым, колдонуучу кылгандай: атты мобилдик дайындардагы телефон браузерине жазып, байланыш убакыт бүткөнгө чейин илмекте турганын көрдүм. Ат чечилчү, демек DNS тартипте эле. Үй маршрутизаторунун портту багыттоо бети да туйык жол болду, анткени анын WAN дареги 100.64.31.42 көрсөттү, ал эми бул провайдер мени интернеттен багыттай турган дарек эмес. Бул сан бүткүл бузулууну түшүндүрөт: линия carrier-grade NAT артында, ошондуктан туннелдин менин жагымдагы ачык дареги провайдерге таандык. Андан ары ошол илмектегир баракчадан жооп берген кызматка чейин баскан жолум келет.

Кардардан баштап, ичке карай жыл

Каалаган эрежени өзгөртүүдөн мурун чынжырдын кайда токтогонун далилде. Ноутбукта dig +short files.example.net командасын аткарып, VPS дарегин кайра алдым, бул машинамдагы эскирген DNS-ти жокко чыгарды. Андан кийин curl -v --connect-timeout 5 files.example.net:5022 четке кагылбастан убакыт бүтүмүнө учурады. Бул айырма маанилүү: убакыт бүтүмү адатта пакеттер жолдо ыргытылып жатканын билдирет, ал эми четке кагуу бир нерсе жооп берип жок дегенин билдирет.

Ичке карай кийинки кадам VPS өзү болду. ss -ltnp 5022-де угуп турган эч нерсе көрсөткөн жок, бул DNAT эрежеси пайда болгонго чейин күтүлгөн жагдай эле. Ошол эле машинада wg show (же OpenVPN үчүн ip -br a show tun0) үй peer-инин иштеп жатканын жана жаңы handshake бар экенин ырастады. Peer иштебесе, эч бир NAT эрежеси жардам бербейт, ал эми үй маршрутизаторунун VPN бетинин жашыл жарыгы эч нерсени билдирбейт.

Үй линиясынын чын эле CGNAT артында экенин ыраста

Маршрутизатор WAN интерфейсинде билдирген даректи сырткы кызмат көргөн дарек менен салыштыр. 100.64.0.0/10 ичиндегинин баары, башкача айтканда 100.64.x.x-тен 100.127.x.x-ке чейин, RFC 6598 документиндеги жалпы дарек диапазону жана интернеттен жеткиликсиз. Маршрутизатор жөнөкөй жеке дарек бар деп ырастап, ачык суроо байланышы жок нерсе кайтарганда да ошол эле жыйынтыкка келесиң. CGNAT линиясы кийинки lease-ке чейин гана жарактуу ачык дарек менен да келиши мүмкүн, ошондуктан портту багыттоо бир саат иштеп жаткандай көрүнүп, анан үнсүз өлөт.

Кээ бир провайдерлер чын эле ачык дарек беришет, бирок турак жай эсептеринде кирүүчү 80 жана 443 портторун бөгөттөшөт. Кызматың тек гана веб болсо жана WAN дареги чын эле ачык болсо, relay куруудан мурун колдоо кызматынан сура. Андай болбосо, төмөнкү долбоор ар бир портко бирдей колдонулат жана экспериментти маршрутизатор жагында токтоткон жөн: провайдердин тармагындагы которуучу байланышты сенин WAN интерфейсиңе жетпей туруп бүтүрөт.

Атты VPS дарегине багытта

DNS трафикти өткөрбөйт, ошондуктан кызматтын A жазуусунда VPS-тин ачык дареги болушу керек. 192.168.1.20-га багытталган A жазуусу VPN ичиндеги кардарлар үчүн гана пайдалуу чечилет; интернеттен эч ким багыттай албаган дарекке чечилет. VPS-тин өзүнүн административдик кирүүсү үчүн өзүнчө ат кармайм, жазуунун кайсы хостко тиешелүү экенин эч качан чаташтырбаш үчүн.

Эгер VPS да, үй машинасы да HTTP кызматын көрсөтсө, ар бирине өз атын бер жана ким жооп берерин VPS чечсин. Аларды бир атка бириктирип, прокси туура backend тандайт деп үмүт кылуу — так ушундайча туура эмес хостто түштөн кийин ката издеп отурасың.

Бир порт DNAT аркылуу, SSH 22-де калсын

Түз вариант — VPS-теги багыттоо NAT. Иштеп жаткан ядрого forwarding күйгүз жана эрежеде үй серверинин туннель дарегин карма, LAN дарегин эмес:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

VPS-тин өзүнө SSH-ты 22-де калтыр жана башка портту, мисалы 5022-ни, үй машинасына багытта. 22-ни өчүк машинага багыттасаң, аны оңдой алган жалгыз жолду жоготосуң. Ушул эле логика проксиге да тиешелүү: VPS-тин башкаруу портун relay эрежелеринен тышкары карма.

Эрежелер иштей баштаганда аларды туруктуу кыл. Debian же Ubuntu-да apt install iptables-persistent жана андан кийин netfilter-persistent save аларды /etc/iptables/rules.v4 файлына жазышат. firewalld бар хостто барабардыгы — зонадагы туруктуу портту багыттоо, ал колдонулуудан мурун firewall-cmd --reload талап кылат. Тек эсте гана жашаган эрежелер провайдердин биринчи тейлөө кайра жүктөлүшүндө жоголот, адатта жаман саатта.

Кайтуу жолун түзө же ага муктаждыктан кач

DNAT тек багытты кайра жазат. Үй сервери байланышты баштапкы кардар дарегинен көрөт, ал эми анын демейки маршруту үй маршрутизаторуна барса, жооп үй WAN-ынан чыгат, ал жерде провайдердин которуучусу аны ыргытат. Бул асимметрия DNAT эрежеси толук туура көрүнгөндөн кийин кезиккен экинчи бузулуу болду.

Эки оңдоо иштейт. Үй машинасына саясат маршрутун бер, туннелден келген трафик туннел аркылуу кайтат:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

Же VPS булакты кайра жазсын, жооптун жете алган дареги болсун, ал эми conntrack аны чыгууда тескери айландырсын:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

SNAT версиясы чыныгы кардар дарегин үй серверинен жашырат, ошондуктан колдонмо журналдары peer катары 10.8.0.1 көрсөтөт. Баштапкы даректи колдонмо деңгээлинде өткөр же кардар боюнча журнал жоголушун кабыл ал, бирок муну окуя учурунда аныктоонун ордуна атайын чеч.

Бүт жолду сырттан текшер

VPS да, үй да болуп саналбаган тармактан текшер: мобилдик дайындардагы телефон же башка жердеги арзан shell. nc -vz files.example.net 5022 ийгиликтүү байланыш тууралуу билдириши керек, openssl s_client -connect files.example.net:443 -servername files.example.net ачык ат үчүн сертификатты көрсөтүшү керек. Андан кийин провайдердин коопсуздук тобун же булут firewall-ын текшер. Эч качан пакет көрбөгөн DNAT эрежеси адатта хосттон бир катмар жогорураак блоктолот.

Акыры, туннел кулаганда эмне болорун чеч. DNAT эрежеси байланыштарды кабыл алууну улантат жана аларды үнсүз өлүк туннелге жиберет, бул так бузулган кызматка окшош. VPS-те peer иштебегенде портту четке каккан ден соолук текшерүүсү бир нече сапка турат жана бир саат божомолду үнөмдөйт. Андан кийин эрежелерди оңдоону токтот жана ага ишенүүдөн мурун бир күн байка.