Adaptorul VPN afișează /32: asta nu înseamnă o singură destinație
O mască 255.255.255.255 pe un adaptor VPN este adresa clientului însuși, nu o limită a gazdelor accesibile. Citiți separat rutele, aria gateway-ului și calea de întoarcere.
Adaptoarele afișează 255.255.255.255, iar concluzia este adesea că VPN-ul ajunge exact la o singură adresă. Această citire confundă adresa clientului însuși cu mulțimea destinațiilor rutate prin tunel. Pe o interfață punct-la-punct sau rutată, cele două sunt obiecte diferite, și doar una dintre ele limitează accesibilitatea. Mitul supraviețuiește pentru că masca seamănă cu masca de subrețea învățată pe Ethernet.
Mitul: o mască de gazdă înseamnă o singură gazdă accesibilă
O atribuire /32 spune interfeței care adresă aparține acestui capăt al legăturii, iar pe o legătură punct-la-punct asta este tot ce înseamnă. Adresa partenerului este un câmp separat, iar rutele care spun ce se află dincolo de partener sunt din nou separate. Nimic din mască nu descrie rețeaua îndepărtată, pentru că masca nu este locul unde se descriu rețelele îndepărtate. Să o citești ca limită de accesibilitate este ca și cum ai citi numărul propriei case ca o listă cu toate adresele pe care ai voie să le vizitezi.
Confuzia are o rădăcină reală: pe Ethernet, o mască de gazdă ar însemna într-adevăr o singură adresă în acel segment. Un tunel nu este un segment Ethernet, iar ce trece prin el decide tabela de rutare a clientului, nu masca. De aceea același /32 poate sta în fața unui întreg centru de date.
Citiți adresa și rutele ca obiecte separate
Tipăriți interfața și tabelul împreună, apoi citiți-le ca două răspunsuri la două întrebări. Adresa răspunde cine este acest capăt; rutele răspund încotro poate merge traficul. O a treia întrebare, ce destinații permite gateway-ul, nu se vede deloc pe client. Referința de adrese a iproute2 descrie separat câmpurile de adresă locală, partener și rută de prefix exact din acest motiv.
ip addr show tun0
ip route show
ip route get 10.60.5.10
În Windows există aceeași separare între lista de adrese și tabela de rutare, iar comanda de căutare este cea mai rapidă cale de a vedea care câștigă pentru o destinație anume. Dacă căutarea returnează interfața tunelului, clientul va trimite pachetul acolo. Dacă returnează adaptorul fizic, clientul nu întreabă niciodată VPN-ul, iar nicio permisiune din partea serverului nu schimbă asta. Verificați destinația de care aveți într-adevăr nevoie, nu o adresă publică generică.
Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10
Opriți-vă dacă căutarea indică interfața greșită. Aceasta este o problemă de rutare a clientului și se rezolvă pe client.
De ce lărgirea măștii înrăutățește de obicei situația
Schimbarea atribuirii într-un /24 ca să arate ca LAN-ul biroului poate crea un prefix pe legătură: nucleul crede acum că tot /24 este conectat direct la interfața tunelului. Traficul către adrese care ar trebui rutate prin gateway este trimis atunci ca și cum un vecin ar fi pe legătură. Rezultatul este o gaură neagră care seamănă cu o cădere a serverului.
Ascunde și problema reală, adică o rută lipsă sau o permisiune lipsă pe gateway. Niciuna dintre ele nu este creată de o mască mai largă, iar ambele supraviețuiesc schimbării. Dacă proiectul are nevoie de un prefix mai mare pe interfață, aceea este o decizie pentru modelul de interfață folosit, luată cu documentația în mână. Copierea unei măști din capturi de ecran ale altui produs nu este acea decizie.
Dacă lipsește ruta prefixului îndepărtat, corectați aprovizionarea ei. Dacă este prezentă și conexiunea este totuși refuzată, masca nu a fost niciodată diagnosticul.
Când ruta este corectă și fluxul tot eșuează
O rută corectă dovedește doar că clientul va trimite pachetul. Gateway-ul trebuie încă să accepte destinația, calea de întoarcere trebuie să existe pentru adresa atribuită, iar serviciul trebuie să permită fluxul. Testați aceste trei separat: căutarea pe client, aria permisă a gateway-ului și o cerere către un server necesar. Faptul că autentificarea reușește înainte ca toate trei să fie la locul lor este normal, și de aceea un client conectat poate totuși să nu ajungă nicăieri.
ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null
Țineți obiectele de rețea și permisiunile de grup la proprietarul lor pe un serviciu administrat de un aparat. Ce i se spune clientului să atingă și ce i se permite să folosească sunt setări diferite, adesea pe ecrane diferite. Schimbarea uneia și testarea celeilalte este felul în care un tichet sare între două echipe.
Mitul care trebuie pensionat este că masca este o limită de accesibilitate. Citiți adresa, rutele și politica gateway-ului ca trei fapte separate, iar un /32 încetează să mai pară o restricție și începe să pară o atribuire normală de tunel.