Pecyn IPv6 rhy fawr: pam mae trosglwyddiadau VPN mawr yn stondio

Mae ping yn gweithio, mae’r porwr yn llwytho tudalen fach, ac mae’r trosglwyddiad ffeil yn hongian, i gyd dros IPv6 drwy’r un twnnel. Mae’r patrwm hwnnw fel arfer yn golygu nad yw’r anfonwr erioed wedi dysgu gwir faint y llwybr, nid bod y twnnel yn araf. Mae IPv6 yn disgwyl i lwybregwyr adrodd y broblem gyda neges Packet Too Big, ac mae crynhoi yn ychwanegu gorbenion cyn i becyn gyrraedd y rhwydwaith allanol o gwbl. Os hidlir y neges honno, mae’r anfonwr yn dal i ailadrodd maint na all basio.

Ceisiadau bach, stondiadau mawr

Mae twnnel yn lapio pob pecyn mewn pennawd arall, felly mae’r maint defnyddiadwy y tu mewn yn llai na’r maint y tu allan. Mae pecyn a faintiwyd ar gyfer y cyswllt ffisegol cyn crynhoi yn mynd yn rhy fawr wedyn. Gall llwybregwyr IPv4 ddarnio ar y llwybr, tra nad yw llwybregwyr IPv6 yn gwneud hynny ar ran yr anfonwr, felly rhaid i’r anfonwr addasu ei hun yn lle hynny. Ac mae’r addasiad hwnnw’n dibynnu’n llwyr ar dderbyn yr adborth.

Mae un neges goll yn ddigon i greu’r symptom clasurol: mae ysgwyd llaw ac atebion bach yn llwyddo, ac mae rhestr cyfeiriadur neu lwythiad i fyny yn stondio ar yr un pwynt bob tro. Mae defnyddwyr yn disgrifio hyn fel bod y VPN yn araf, ac nid yw’r cofnodion yn dangos dim o’i le gyda dilysu. Mae’r ddau sylwad yn gywir, ac nid oes yr un ohonynt yn canfod y diffyg.

Adborth yw Packet Too Big, nid traffig

Mae neges ICMPv6 Packet Too Big yn cario’r maint y gall y naid nesaf ei dderbyn, ac mae’r anfonwr yn ei defnyddio i ostwng ei amcangyfrif. Mae ei hidlo yn gyfystyr â chael gwared ar arwydd ffordd ac yna beio’r gyrwyr. Mae rheol sy’n gollwng pob ICMPv6 yn edrych yn llym wrth dorri darganfod llwybr ar bob cyswllt sydd ei angen. Mae’r neges yn wybodaeth reoli am y llwybr, nid yn llwyth tâl cymhwysiad.

Mae hidlo dethol yn dal yn rhesymol. Mae ceisiadau atsain a darganfod cymdogion yn chwarae rolau gwahanol i negeseuon gwall, a gall polisi eu trin yn wahanol. Dilynwch ganllawiau hidlo dogfennedig y platfform yn lle derbyn neu ollwng y protocol cyfan, oherwydd RFC 8201 sy’n diffinio sut mae’r adborth hwnnw’n gyrru darganfod.

Profwch y ddau deulu cyfeiriad ar wahân

Profwch IPv6 ar ei ben ei hun, oherwydd nid yw trosglwyddiad IPv4 llwyddiannus yn profi dim am lwybr IPv6. Yna cofnodwch negeseuon rheoli tra bo’r trosglwyddiad mawr yn stondio. Mae’r ddau gofnod gyda’i gilydd naill ai’n dangos bod yr adborth yn gadael neu’n profi na chyrhaeddodd erioed.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Mae’r prawf yn anfon pecyn gyda’r did do-not-fragment wedi’i osod ac yn adrodd y maint lle mae’n methu, sef y rhif y mae’n rhaid i’r twnnel ei gynnal. Mae’r ymholiad llwybr yn enwi’r rhyngwyneb a fyddai’n cario’r cyrchfan, felly gŵyr y sawl sy’n profi pa MTU cyswllt sy’n berthnasol. Mae’r cipiad yn hidlo ICMPv6 math 2, y neges Packet Too Big, ac yn dangos a yw’n cyrraedd y gwesteiwr hwn o gwbl. Os yw’r neges yn ymddangos yn y cipiad ac mae’r trosglwyddiad yn dal i stondio, mae’r anfonwr yn ei hanwybyddu, sy’n symud yr ymchwiliad i’r pentwr yn hytrach na’r rhwydwaith.

Addaswch faint y twnnel dim ond ar ôl y dystiolaeth

Gall gostwng MTU’r twnnel guddio neges wedi’i hidlo a gwneud i’r symptom ddiflannu, ar gost mwy o orbenion ar bob pecyn. Gwaith osgoi yw hwn yn hytrach na diagnosis, a dylai ddod ar ôl y cipiad yn lle ei ddisodli. Nid yw gwerth isel mympwyol yn torri dim yn weladwy chwaith, a dyna pam mae’n goroesi mewn cyfluniadau am flynyddoedd. Newidiwch ef yn fwriadol, cofnodwch y gwerth, ac nodwch pa fesuriad a’i cyfiawnhaodd.

Pan reolwch y giât, archwiliwch y rheol sy’n gollwng y neges yn lle analluogi’r mur tân. Mae un rheol wedi’i chywiro yn gulach nag eithriad polisi ac yn llawer haws ei hamddiffyn yn ddiweddarach. Mae’r un rhesymeg yn gymwys i derfynau amser: nid yw pob stondiad yn broblem maint, a chipiad sy’n gwahanu’r ddau.