Bakit humihinto sa pagsagot ang admin ng router pagkatapos ng pagbabago sa VPN

Nagbago ka ng ruta o tuntunin ng firewall para subukan ang tunel sa router, at ngayon hindi sumasagot ang pahina ng admin mula sa laptop na maayos na gumagana sampung minuto ang nakalipas. Ang reaksiyon ay sisihin ang VPN. Kadalasan malusog ang tunel at isa sa tatlong ibang bagay ang nasira: walang rutang pabalik sa sariling address ng router, itinatapon ng patakaran sa papasok ang kahilingan, o walang serbisyong web na nakikinig sa address na tinatawagan mo. Magkamukha ang tatlo sa browser, kaya paulit-ulit na ini-restart ng mga tao ang tunel nang isang oras at wala silang natututuhan.

Narito ang mitong dapat patayin muna: ang gumaganang tunel ay hindi daan pabalik sa loob. Ito ay bagong koneksyon sa network na may sariling mga tanong sa tiwala, at maaari nitong tahimik na alisin ang lumang daan ng pamamahala habang nagbubukas ng bago na walang sinumang nagsuri.

Hindi kailanman naging daan ng pamamahala ang tunel

Magkaibang trabaho ang pagpapasa at papasok. "Maaari bang maabot ng kliyente ang NAS sa pamamagitan ng tunel?" ay tanong sa pagpapasa tungkol sa mga packet na dumadaan sa router. "Maaari ko bang buksan ang SSH port ng router?" ay tanong sa papasok tungkol sa mga packet na naka-address sa router mismo. Ang tuntunin ng pagpayag na isinulat para sa ipinapasang trapiko ay walang ginagawa para sa pangalawang tanong, at iyon ang pinakakaraniwang dahilan kung bakit ang tunel na perpektong nagdadala ng trapiko ay tumatanggi pa rin sa iyong sesyon ng admin.

Ang kabaligtarang pagkakamali ay ang magtiwala sa pangalan ng interface. Ang tunel ay naka-encrypt patungo sa peer, hindi sa bawat serbisyong nasa likod nito, at ang salitang VPN sa label ng interface ay walang sinasabi tungkol sa kung aling mga pinagmulan ang dapat payagang mag-log in.

Unang antas: may ruta ba patungo sa sariling address ng router?

Magsimula sa kliyente at tanungin ang kernel kung saan pupunta ang packet. Sa Linux, ipinapakita ng ip route get 10.6.0.1 ang piniling ruta, ang palabas na interface at ang source address. Kung iniuulat nito ang default na ruta patungo sa iyong provider, hindi kailanman papasok ang packet sa tunel, at walang tuntunin sa router ang makakapagligtas nito.

May sariling bersyon ng tanong ang panig ng tunel. Itinuturing ng WireGuard ang AllowedIPs bilang talahanayan ng rutang susi ng crypto: sa bawat dulo ay ipinapahayag nito kung aling source address ang maaaring gamitin ng peer at kung aling destinasyon ang ipinapadala sa peer na iyon. Kung wala sa entry ng kliyente ang tunnel address ng router, walang ruta ang kliyente patungo roon. Kung hindi saklaw ng entry ng server para sa kliyenteng iyon ang tunnel address ng kliyente, itinatapon ng server ang packet bago pa tingnan ang anumang tuntunin ng firewall.

Kumpirmahin ang eksaktong address na inaasahan mong maabot bago i-debug ang patakaran. Ang lumang rekord ng DNS o naka-cache na entry ng kapitbahay mula bago ang pagbabago ay magdadala sa iyo sa address na hindi kailanman pag-aari ng router.

Ikalawang antas: ang patakaran sa papasok, hindi ang patakaran sa pagpapasa

Sinusuri ng firewall ang mga tuntunin sa interface kung saan dumarating ang packet. Sa pfSense at OPNsense, ang tab ng interface at ang pagkakasunod-sunod ng tuntunin ang nagpapasya kung pinapayagan ang trapiko patungo sa sariling mga serbisyo ng firewall; ang tuntuning nagpapalabas sa mga kliyenteng LAN sa internet ay hindi tuntuning nagpapahintulot sa peer ng tunel na buksan ang web GUI. Sa OpenWrt na may firewall4, bawat sona ay may patakaran sa papasok, option input 'ACCEPT' o 'REJECT', at ang interface ng tunel sa sonang REJECT ang papasok ay tatanggihan ang mga koneksyon sa pamamahala habang nagpapasa pa rin ng trapiko kung pinapayagan ang pagpapasa.

Huwag i-disable ang tuntunin laban sa lockout para gumana ang bagong daan. Pinipigilan ng tuntuning iyon ang masamang tuntunin na i-lock ang address ng pamamahala ng LAN; pinoprotektahan nito ang subnet ng LAN, hindi ang subnet ng tunel na kakagawa mo lang. Magdagdag ng isang makitid na tuntunin para sa pinagmulan ng administrator at hayaang manatili ang safety net. Ang dokumentasyon ng pfSense tungkol sa pag-access ng admin ay nagpapaliwanag kung nasaan ang mga kontrol na iyon.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Ikatlong antas: may nakikinig ba sa address na iyon?

Maaaring tumatakbo ang serbisyo at hindi pa rin maabot dahil nakatali ito sa isang address. Ang uhttpd ng OpenWrt ay may tahasang mga entry sa pakikinig sa /etc/config/uhttpd, halimbawa list listen_http '0.0.0.0:80'; ang build na nakatali lamang sa address ng LAN ay walang tinatanggap sa address ng tunel, at ganoon din ang ugali ng mga produktong naglalabas ng setting ng interface ng pakikinig. Ang mga utos sa pakikinig sa itaas ay direktang sumasagot dito.

Pagkatapos ay paghiwalayin ang pagtanggi sa katahimikan. Ang nc -vz 10.6.0.1 443 na nagbabalik ng tinanggihang koneksyon ay nangangahulugang naabot ng packet ang router at may tumanggi rito, maaaring saradong port o tahasang tuntunin ng pagtanggi. Ang pagkabitin hanggang mag-timeout ay nangangahulugang itinapon ang packet o hindi kailanman niruta. Sinasabi ng pagkakaibang iyon kung aling antas ang susuriin sa susunod, at tumatagal ito ng limang segundo.

Ang interface ng VPN ay hangganan, hindi daan ng pagbawi

Pinoprotektahan ng encryption ang kable; wala itong sinasabi tungkol sa kung sino ang maaaring magbukas ng pahina ng admin. Kapag gumana na ang tunel, labanan ang hangaring lutasin ang pag-abot sa pamamagitan ng pagpayag sa lahat sa interface ng tunel. Bigyan ang mga administrator ng tuntuning nakatali sa kanilang sariling tunnel address o hiwalay na tunel para sa administrator lamang, at ilayo ang mga ordinaryong user, ang NAS, ang mga camera at ang mga laptop ng pamilya sa port ng pamamahala. Ang peer na nangangailangan ng pagbabahagi ng file ay hindi dapat isang tuntunin lamang ang layo sa login ng router.

Binabago ng papel ng router ang sagot. Ang router na nagtatapos ng tunel ay maaaring lehitimong tumanggap ng mga administrator mula rito, samantalang ang router na gumagamit ng tunel bilang labasan lamang sa internet ay karaniwang hindi dapat. Sa dalawang kaso ang pahintulot sa subnet ay hindi ang login, kaya hayaang bukas ang pagpapatunay ng account at seguridad ng transportasyon.

Ang kompensasyong hakbang na ginagawa ng mga tao pagkatapos ma-lock out ay mas masama: pagpapagana ng pamamahala sa WAN o pagpapasa ng port sa web GUI. Ginagawa nitong permanenteng pagkakalantad ang maikling pagkawala, at ang pahina ng login ay maaabot na ng bawat scanner sa internet. Subukan din ang tinanggihang panig, hindi lamang ang pinayagan, upang ang peer na hindi dapat magkaroon ng access ng admin ay makatanggap ng timeout o pagtanggi sa halip na kahilingan sa pag-log in.

Subukan din gamit ang bagong koneksyon. Ang stateful firewall ay nagtatago ng mga kasalukuyang daloy sa talahanayan ng estado nito, kaya ang SSH session na bukas na sa iyo ay maaaring makaligtas sa pagbabagong humaharang sa bawat bagong koneksyon. Ganoon nananatiling hindi nakikita ang lockout hanggang sa susunod na reboot o susunod na pagtulog ng laptop.

Ihanda ang daan pabalik bago hawakan ang patakaran

Isulat ang apat na bagay bago ang unang pagbabago: paano mo maaabot ang aparato kung mamatay ang tunel, halimbawa console na serye, console ng provider o makina sa LAN; saan iniluluwas ang kasalukuyang konfigurasyon; aling nag-iisang tuntunin o ruta ang babaguhin mo; at paano mo eksaktong ibabalik ang item na iyon. Sa OpenWrt, hinuhuli ng sysupgrade -b /tmp/backup.tar.gz ang konfigurasyon, at nananatiling nakabinbin ang mga pagbabago hanggang uci commit, na nagbibigay sa iyo ng murang undo kung mapansin mo sa tamang oras. Nagtatala ang pfSense ng kasaysayan ng konfigurasyon, at ang AutoConfigBackup ay tumutulong lamang kung nakabukas na ito. Kung ang router ay nagpapatakbo ng set ng tuntuning fail-closed, tiyakin na ang planong daan ng maintenance ay wala sa loob ng trapikong hinaharang ng tuntuning iyon, at tandaan na ang reboot ay muling naglalapat ng mga permanenteng tuntunin sa halip na burahin ang mga ito.

Baguhin ang isang hangganan bawat pagtatangka, pagkatapos ay subukan mula sa bagong koneksyon sa halip na sa shell na iniwan mong bukas. Kung mabigo ang pagsubok, ibalik ang isang pagbabagong iyon bago hawakan ang susunod na antas. Maaaring manatiling up ang tunel sa lahat ng oras, ngunit ang berdeng icon ng estado nito ay hindi patunay na makakapasok ka pa.

Mabilis na pagsusuri bago umalis:

• Maaabot mo ba ang router mula sa pinagmulang hindi umaasa sa tuntuning kaka-edit mo lang?
• Pinapayagan ba ng patakaran sa papasok sa interface ng tunel ang pinagmulan ng administrator lamang?
• Nakatali ba ang serbisyo ng pamamahala sa address na umiiral sa tunel?
• Sinubukan mo ba ang isang tinanggihang peer at isang bagong sesyon?
• Bukas pa ba ang ibabaw ng pamamahala sa WAN?